• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Wingnut

  1. Yeah, Jack, what the hell is wrong with you? heh. Get your butt over to the new forum, we're only about 1/4 done with the house-warming party. And, we need a fresh announcement for Boxigon, at the new forum, too. C'mon!
  2. This thread has been moved to I am marking this as 'moved'... see ya at the new forum.
  3. Hi maksmaks... welcome to the old forum. Could you please re-post in the Questions category of the new forum? In 3-4 days, we cannot post here anymore (but we can still read old posts). Thanks! Perhaps you can use particle emitters on each agent... to leave "trails", but I'm not sure if that would be useful/wise. Cya at the new forum, where we have more helpers.
  4. Hi there. Just a (badly-acting) testing playground, if needed. Can I ask WHY you want to block enter/out/down/up events... on any GUI controls? Are you trying to make picks/clicks...sometimes "get through" to mesh/nodes behind the GUI? Just curious. I assume you mean.. adding enter/out events to GUI rectangles that you wish to use as custom buttons. (creating rectangles that ACT like buttons) *nod* Generally speaking, there is likely a way to do what you wish, without needing to make custom buttons, OR block standard events on simpleButtons. Tell us some more details, if you please. Build us a better playground... teach us what you wish to do. We might be able to solve your issue with some .isForeground, .isBlocking, and/or .isPickable flags.
  5. Hi T! I was SO hoping that @RaananW would have visited and saved the day (Oimo-wise). hmm. A sliderJoint might simply have a different name... in Cannon... like perhaps distanceJoint. Most of the properties are differently named... for each engine, unfortunately. Conversion to CannonJS == big step. Destined for troubles. You have visited R's tutorial page, yes? Are you a member of the new BJS forum? I hope so. Really, some physics superstar needs to build (us) NEW, FRESH versions of "basic car"... for all three of our plugin-honored physics engines. (Oimo, Cannon, Ammo) Who? I don't know. I'm really not very good-at physics coding, but only a few people... ARE. I think the corporate world is sucking-up the pro's, so they don't have time to hang-around with us, here. *sigh* I DO have time to work-on fixing the Oimo car or helping with a Cannon car, but, to be frank, doing that isn't much fun. I'm sort-of retired... so I screw-off a lot and don't like getting stressed. Hmm. I will give it some thought. You... have been very brave... attempting to convert the Oimo car... to Cannon. Bravo! You might get a brain tumor, though. Maybe there are others nearby that can give quicker/better answers than I. Join the other forum, and in a few days, perhaps visit "The Wingnut Chronicles" and say something like... "Theo here... let's talk about physics cars". I will probably *sigh* again... knowing the amount of "work" it could entail. Me, I want to try to determine WHY Oimo joint setMotor is failing, or, more precisely, why the impostor attached to one end of that joint... is frozen in-place. Remember we saw the "micro-moving" in a previous playground. That micro-moving of the setMotor... is evidence that the motor is TRYING to work, but POSSIBLY... the impostor's shape (the mesh) is refusing to allow it. More precisely, I believe it is the shape's "transformNode" that is causing setMotor to fail. Mesh transformNodes are a fairly new feature, and are still under consistent development. I think... something was modified in transformNode... and the Oimo plugin was not updated to compensate for that change. Raanan could probably find it in less than a day. Wingnut... around 2 months. So, you see why I *sigh*. But still, getting good-working basic physics cars... is important, and worthwhile. I will TRY to keep pursuing that goal. Cya at the new forum. Our previous posts are safe, here, for at least 90 more days. But after the new year, we cannot post here any longer. We can still read, though. Take care, thanks for the comments, cya soon.
  6. Wingnut

    New forum

    Thanks for your work, here, guys. Personally, I have lots of text in the old forum... perhaps more than any other user. My primary concern is to have that text remain searchable, forever, somehow. AND, I'm still reading all the text/posts made by others, and depend upon those, heavily (to look smarter than I really am). Anything that can be done... thank you, thank you, thank you! (hug) Also, thanks to those who are spending $$$ on temporarily keeping things alive. Very nice of ya!
  7. Hello, mixoxo, welcome to the (old) forum. Sorry for the slow replies... we've been moving and working hard. Have you read this: (Plenty of info about .obj, but not much about .fbx, though.) I could not find any playgrounds that import .fbx, but here is a forum search for "fbx file". A Google search for BabylonJS + fbx... returned some good results. Maybe good reading, there. Forum super-hero @RaananW once said: If you find an application that can deserialize an fbx file, you can create a babylon file using the information. [link] Let's watch for more replies.
  8. Lots of meshWriter talk happening over in the new forum, @The Leftover. Some here, and a little bit in the new Wingnut Chronicles. Are ya logged-in over there, yet? It's an open-air forum... almost like being outside, in the woods. Pretty nice. Perhaps we need a "new introduction" post... about MeshWriter... over there. In fact, I know we do. Everyone... get your new user accounts and start earning... err... I don't like earn'n'deserve systems... never mind that feature (I prefer everyone treated the same, no matter if they have earned or deserved it, or not. That's another story.) All in all, the new forum is a cool place/thing, and all our friends are over there, learning all the new things that it can do. C'mon over!
  9. I am marking this as solved. See ya at the new forum, Eisha! Post again (there) if you have problems or want to share fun discoveries.
  10. Hi Hugo, welcome to the (old) forum. Feel free to join us at the new forum: Post about your issue... over there, if you would. You don't need to paste your code again. Here's a testing playground with your code included... Apparently, no faceID values are available with tiledGround actionManager events. (like you stated) I believe you MIGHT need to "calculate" which face/cell was clicked... using some math. Anyway, c'mon over to the new forum... re-post your issue in the QUESTIONS sub-forum, if you like. (and include that playground URL listed earlier) PERHAPS others will comment, here. Not sure. There's a party happening at the new forum and I think almost everyone is over there, having fun with the new forum software. Come on-over to the party... we'll work-on your issue over there. Thx!
  11. hahaha... damn, I am SO blind. (hug) Hey DylanD.. are you on the new forum, yet? Perhaps start a new Q&A thread over there... "Testing GUI Health Meters" (anything you choose)... and we'll keep doing experiments and talks. Meantime, I'm marking this thread as solved. Message me if you want it re-opened for some reason. See ya soon at the new forum.
  12. Hi DD. I can't imagine a situation where a power/health meter or status bar... would want/use a moving container. That causes the entire health meter "control".... to move-around upon/within the advancedDynamicTexture (adt) (or upon/within other types of containers such as a grid cells). Few people would animate-move a control... after it is placed upon/within the adt container. But if YOU are happy, DD, then I am happy WITH you. Pretend white-border "outer" container... is where you want the health meter on the screen... in your game/project. You need it to stay there, yes? Try to get your health meter... operating within that white box. Kenya? (can you?) One more wrapping container (outer) shouldn't affect your new control at all, right? Does it? I put a thin red line around original container... so we could watch it moving. SideNote: Hey @Deltakosh/others... line 17 - outer.left = "50px"; ... not working? seems to work, but not outer.left. Likely Wingnut mistake.
  13. Also, that looks like a question for a JQuery forum. On the way to the jQuery help pages and forums, you might wish to change 'target connected' to 'target_connected'. Cya later, somewhere else.
  14. Wingnut

    New forum

    Yeah! A robot... reads post after post after post, gathering the html, page after page... all day sucker. We keep squirting it with WD-40 until... after 90 days of 24/7 "gleaning"... it finishes, and promptly falls to pieces from robot fatigue. heh. "Mister Glean, Mister Glean... sucks your databases clean... by Mennon". errr... no, I got my brands confused. Wingnut checks Naz's "hunter-gatherer" license and it is valid and up-to-date, with proper certifications. hmm. Ok, that's an option. Throw a ton of money and hugging at Naz, and ask him to build his post-reading robot, if he (ever) has time. We really don't need any permissions, right? We just need to act like a user... who reads every post... one after another... for 3 months. Sort of like a "denial of service" attack engine. Thanks for the offer-idea, @NasimiAsl. Interesting and nice-of-ya! I say... name it... The P. I. G. G. G. ... programmable intelligent grunting gulping gatherer. Pigs "forage", and "nudge" and "root", and will eat anything.
  15. Well, remember... that the velocity of the mouse pointer... at the time of intersect... matters. With a fast drag, each diff value is large. Slow drags, the diff values are small. Sooo... it is difficult to determine how many diffs to back-out. Smarter to do some quick boundingInfo measurements, and force some positions... based upon those. De-overlap the two bounding boxes... but just barely de-overlapped. Just MAYBE... a function could be added to BJS Tools... deOverLap(mesh1, mesh2). mesh 1 doesn't move. mesh2 re-positions itself... using the shortest distance... to de-over-lapped state (from mesh1). Interesting. (Might need an option to lock the Y axis during re-position. ie. don't let mesh2 exit intersect state... via moving above or below mesh1.) Or, perhaps some other prediction tools could be thought-up... now that we know more info. @timetocode - What a fine explanation! THANK YOU! Fantastic.
  16. @JCPalmer Yuh, yuh, yuh... you are correct. Why do you think I'd try to "munch" a lens flare? See my eyes? Roadmaps, baby. heh. The lemon wasn't bad, but... I think I like "Master K" better. We really love skunks 'round these parts. Indica-tive, ya know? But transporting skunks is was risky. I have SO many new things to learn/try, but the stores won't be opening until 2020, I hear. hmph. But yeah, a new feeling of freedom has come-upon our state. I hope it comes to other states, too. Off-topic? Does it matter anymore?
  17. Hi gang! Well, here ends The Wingnut Chronicles, and this forum. 1,459 replies 96,174 views Not quite 100,000 views, but close. This forum is going READ-ONLY soon, so maybe the views will still increase into 2019. Come check out our new forum at... I'm still on the road to the new forum. I snapped some pics... By the way, good whiskey helps... for getting a lens flare un-stuck from your tongue. Cya at the new forum! It ROCKS!
  18. Wingnut

    New forum

    This is the part I don't believe/trust. Words come easy, but follow-through is subject to folks "changing their minds". We don't need access to the current DB. We just need someone near the DB... to get us a backup. Not necessarily one of "our people". Ask the folks near the DB to make a copy for us. What's so difficult about that? Are we asking for the moon and stars? No. Just a backup. Would it be a binary mess that we couldn't decipher anyway? Can we fire-up an Invision forum later, and re-activate it all? (in case of emergency) Please, let's not be flippant/negligent about the value of this archive. These changes are happening much too fast and (possibly) without proper ass-covering. How about we take another month or two to completely investigate our back-up options? Just one wrong move during this hack'n'slash transition, and our knowledge base could be killed. Are there animosities involved... in these decisions? Is someone pissed at someone else? And while we're at it, what are the backup options for the new forum? Are we destined to go thru this "nail-biter" thing... AGAIN? So stressful. Don't we NEED to be ready... to revert, in case the new forum or its authors/support... suck beyond belief? This whole operation feels somewhat haphazard to me... done "on a wing and a prayer", perhaps. Maybe it's my inexperience in these things... that causes these worries. About 10 million future BJS users... have not read ANY of our posts, yet. People tend to quickly label as "everything is fine" when in-fact, everything is NOT fine. This premature "it's fine" labeling is often caused by laziness and rush. No matter the rush to fly to the new destination, take some time to pack some luggage and make sure your "home" is safe... before departing. This will be my last comments on this subject, I think. Sorry for all the worrying, but I'm worried. I love and cherish the posts in this forum. Aside: Hey DK, they make laptops that are ALMOST as small as tablets/pads, and almost as easy to take to lunch with you. With a laptop, you can get a REAL keyboard, and you can avoid thumb-typing. Then, you could even type sentences longer than "pinging RaananW". hahaha. Ahh, it's so much fun to pummel tablet thumb-typers. They yell "Hey Wingnut... more white space in your posts, please"... and I yell "Hey pad user... less white space in your posts, please". fun. The new forum looks kind of white-spacey... like a tablet user was involved in its CSS/design. The desktops vs. mobiles "styling wars"... continue.
  19. Great conversation, guys - thx for your work/tests/fixes! Is THAT border acting correctly? Just curious. It sort-of looks like border and background are on different z-layers. Cool. More on that... far below. (oh no!) Wingnut mentally wanders-off... I'm still thinkin' that... "border" (and thickness) needs to be a control of its own. When GUI borderControl is invented, we get a PILE of versatility, and the world of currentMeasure (for other controls) becomes much less stressful to the GUI author - mainly DeltaFlyer. The borderControl would be very "extensible", whatever that means. Once it becomes a separate control, the world of fancy borders and marquis and a bunch of other animated and fancy crap... comes into view. When you need a borderControl added to ANY other control-type, you push that borderControl into the targetControl's .adornments array. 'Adornments' becomes a whole new area... to add "features" to any control. Add-ons. Layers. Even a borderControl... used mostly as an "adornment control"... has an .adornments array. Or maybe... 'adornments' are not really a control AT ALL. They are adornments. Similar to behaviors. BorderAdornments might have a property to set whether the border... SURROUNDS the target control area (blocking no targetControl surface area)... or OVERLAYS it (blocks edges of the targetControl surface). I dunno. Adornments would be add-ons. Things like... "graying-out" an inactive GUI button, could be done with an overlay adornment. A big red "X" across a button, easy, by attaching an adornment. One adornment can be used on MANY controls... just put a ref to the adornment... in the control's .adornments array. Controls could be told to ignore the adornment if the .build call to the adornmentObject... fails or times-out (possibly because the adornmentObj/Func 404'd when retrieving a web texture/svg it needed). Adornment controls could be designed... ready to animate... and can be told to start animating as soon as they are put into a targetControl's .adornments array. Rounded border corners could be troubles, though. Round-corner borders need to remove/re-paint background textures/colors... of the targetControl. In that case, the adornmentControl is SERIOUSLY imposing itself (forcing things) upon the targetControl. But, I guess an overlayed (non-surrounding) square-corner border... would also re-paint the edges on the targetControl. *shrug* I really don't know enough about the layering possibilities of a GUI control (and isBlocking hassles thereof). Perhaps... two types of adornments? Those that need to modify the targetControl paint-job, and those that don't? intrusive/non-intrusive? hmm. Just crazy talk, huh? I get that way when I watch Saturday morning cartoons and drink too much over-powered coffee. Hey NRA... sorry that the recent GUI upgrades caused stress... about client deadlines/criteria. We don't like to see that happen. We hope you are still on-timeline.
  20. Wingnut

    New forum

    Hiya V (and others). I second that question. I would LOVE to have the old forum contents... become webpages that we can EACH archive. I have written a crap-load of in-forum tutorial-like posts. I would HATE to see them destroyed... ever. I wonder how big a "dump to html" would be. If we could dump all old posts... to html... and I get a copy... that would be best. That way, my huge pile of yapping... is safe... and it's in OUR hands, not dependent upon anyone else. Also, I wish the new forum was a little less "preachy" about trying to control my niceness, and a little more preachy about how they are going to quickly fix/adjust all the broken and crappy things we find in their forum software. ie. Concern themselves with THEIR "nice", and let us run our own lives. Let's see if THEY act nice, and have ANY credentials to try to tell US how to act. We have 5 years of success under our belts. THEY are the ones on-trial, not us. We should be severely scrutinizing their issue resolution channels/techniques, and they should bending over backwards to ensure to us... that they have a good one and that we will be loved. When doing Us-Them wars (capitalism)... NEVER trust a them. Them's often have a big cock'n'bull "front" or "facade" erected, and zero integrity or intestinal fortitude to back it. This also applies to words such as... "old forum will remain read-only available". Don't believe it. Get a safer copy of our stuff... PLEASE, if possible. Don't trust ANYTHING. Once we get our old "stuff" into web pages form... we'll publish them at Then, we'll go thru our docs... and find/fix all the links to forum posts... re-targeting them to pages/anchors. Safer. Wingnut won't cry because someone pissed-away 31 trillion pounds of Wingnut noob-teaching. PLUS... everyone else's posts that I still need to learn stuff-from. The forum is a HUGE teaching/learning center. Let's fig a way to save it and re-presentation it, somehow. Worst case, somebody, just dump the entire forum DB to DVD, and I'll pay for a copy... allowing future rescue if necessary. SOMEBODY, get us some more-safe backups and archives... please. Don't trust the words of ANY "them"... really. Sorry if I topic-wandered outside-of the scope of this thread. Perhaps a "backing it up" thread is apropos.
  21. Ahh, Collada. errr. BJS in XML. errr. Can you repro that in a playground, please? I want to see that. We can create a node... without first creating a scene? I bet we need to be Wizard-grade or higher. Might need a magic potion or some faerie dust. I've been staring at for 45 mins, now, thinking about bigopon building his own nodeConstructor, or maybe adding a setEnabled(false) default behavior on all nodes. Wingnut == lost. I'm really not qualified to comment on this stuff, though. But I HAVE been interested in building a BJS scene completely with XML or similar. Then we can use xPath and XSL transforms against the DOM-ish scene graph... for filtering and other transform fun. errr. A different kind of 'transform' than the 3D type, of course. <scene clearColor="black" > <mesh class="bigopon" type="box" size="5" enabled="false" color="red" /> <light class="bigopon" type="hemispheric" direction="0,1,0" enabled="true" intensity="0.7" specular="blue" /> <camera class="bigopon" type="arcRotate" alpha="-Math.PI/2" beta="1.2" radius="40" attached="true" wheelPrecision="200" /> </scene> Coooool. BSML 1.0 (Babylon Scene Markup Language). We even write a DTD (document type declaration) so we can test if a given BSML file... is valid BSML. Wingnut wander-off: Packet-serving becomes scene-serving becomes node-serving... Ted Nelson - Transclusion. Bigopon logs-into our new 3D forum, and gets an XML <avatar> node from all visible forum-users... to be included in his "forum scene". All the mesh (avatars) in his scene... were "transcluded" from many places. Historically (back in the olden days), transclusion was also part of trans-copyright and micro-pay... it presumed that all links be 2-directional. Instead, Timmy Berrners-Lee screwed up the web forever. One-way links go stale. 2-way links can't. But transcluded webpages/XML (pieces retrieved from many places) can be slow-building (yawn). Still, though, there's not many formats that have the hand-around-ability and ease... of a packet of XML (a node).
  22. Ahh, you want to "predict" if the "upcoming" position change... will cause intersect. Yep, been there... wanted that. After mouse has done a pointer-drag... Preferred method: IF upcoming mesh move WILL cause intersect, don't move the mesh, and perhaps return pointer to pre-drag position. Kludgy method: IF mesh move HAS caused intersect, move mesh to PREVIOUS non-intersect position, and allow continued dragging without interruption. (disallow mesh overlap) Did I re-state issue correctly? I hope so. Intersection prediction. "Look-ahead". Ok, anyway, I modified a playground... Notice I disabled lines 154-156, and tried using some fancy line 153. Notice it has a "scale" on it, which is the same as an amplifier or "power soak". Line 153 eliminates diff2, and instead "negates" diff... but then amplifies that amount... * 1.5 (50% more counter-diff). SO, I modded line 158 to use diff instead of diff2. AND, I added or adjusted line 161... so that line 166 operated correctly when we "fell thru" to it. Nothing really changed except... it doesn't get "stuck" anymore. Perhaps it is easier to see what is happening... when it quits getting stuck-upon-intersect. In line 153, change the 1.5 to be 1.0, and we get stuck-on-intersect again. Go fig. Perhaps we can learn why. Nothing in there indicates a reason to get stuck. hmm. COULD IT BE... that WHEN an intersect happens... 3-5 diffs continued to happen. In other words... it took time for intersect to be triggered... and 3-5 mouse drags happened SINCE the REAL position of intersection. SO, you and I try to "back-up" the mesh position ONE diff-level. BUT... that's not enough of a "back" to make it leave intersection state. We actually need to back-up the mesh 3-5 diffs. We need to set currentMesh.position to the current position minus 3-5 diff-moves. THIS is why backing-out 1.5 diff-distance (150%)... takes us out-of intersect state. Perhaps, this value needs adjusting or changes, depending upon how fast the pointer was traveling at the time of intersect. Drag "velocity" will likely affect the size/magnitude of each diff-change value. hmm. Heavy theory, eh? I could be right. Ya just never know. Probably not. heh ------- getGroundPosition() is an interesting func. It returns a "wobbly" diff.y... because of camera angle vs. ground angle, so I do a little currentMesh.y position forcing... in line 147. ------ SO, I have no real solutions, and I haven't designed a "prediction system"... but maybe SOMETHING is helpful, here. Let's do more experiments and listen for more/wiser comments.
  23. One more. No images, all rectangles. outerrect.myvalue 0-175 sets the amount of green fill added from the left. I have a random value setter... turned on. Probably off topic, and certainly not a single control. 2 controls, as a matter of fact. StretchX (which is also compressX?) is likely wiser, if the image can be stretched/compressed on one side only. I dunno. Do we need GUI healthBarControl v1.0? Maybe, eh?
  24. Hi again. Hey, good info-gathering/reporting, thx! You should probably try canvas.onMouseOut or whatever. There has been other forum threads about mouse remaining in "drag mode" after it exits the canvas area. But I can't remember the fix. Be sure to search the forum for 'iframe' and maybe even 'pointerLock' (because a mouse that gets stuck in drag-mode... after it accidentally is dragged off-canvas... is SIMILAR TO pointerLock). It's NOT a pointerLock-based problem, though. iFrames are strange. They are "isolated"... in a rather tight security sandbox. There are 17 returns when doing playground search for 'iframe'. Might be something to learn, there. Perhaps... don't use iframes? *shrug* Anyway, take a look, at our docs... See the little "eyeballs"? Click on those, and a BJS scene "pops-open", and they don't suffer-from "accidentally drag-camera-pointer off-canvas" problems. BUT, they DO allow camera dragging even when the pointer exits the canvas area. SO, maybe not the correct solve, yet. Issue review: DOM-event for canvas onPointerOut/onMouseOut... NOT seen triggering (so far - needs further tests?)... if pointer leaves canvas while dragging. buttonUP while pointer is off-canvas... not seen by DOM, either. Ok, stay tuned for better comments from wiser people than I.