solved Drag and drop assistance

[Mark Bufton]

Hi guys,

I'm having a spot of trouble with my latest practice project - my class 150 DMU simulator. I've got the throttle and brake levers working perfectly, but the horn lever refuses to work at all, despite the code being almost completely identical. Tried everything from resizing to complete code rewriting, even adjusting the order of the code but caught no joy. I also find that when moving the throttle (right) lever, it will often move the horn's "imposter" (hornImp mesh), which is also weird as to my knowledge there should be absolutely no connection between them.

I've set up a playground sample which functions the same as it does on my tablet (save for sounds, local textures etc) so if anyone has any ideas on what's going on. The horn lever should remain upright but have two tones when pushed or pulled (currently simulated with the console log). I apologise if the code seems "messy". I'm in the process of changing a lot of the code to simplify it all.....especially making use of the (awesome!!!!!) new Polygon Mesh (whichever legend is responsible for this, I owe you a pint!!!).

Darn beginner blues strike again.

https://playground.babylonjs.com/#YN94DW

Cheers chaps.

[Mark Bufton]

Oh, and if anyone knows how I can blend the wiper animations (currently you have to click the black wiper control by the horn lever to toggle off, half speed and full speed) so the wiper doesn't teleport back to the off position at the start of each sequence - they'll deserve brownie points.

[Wingnut]

Hi Mark.

line 1988

        var pickInfo = scene.pick(scene.pointerX, scene.pointerY, function (mesh) { return ((mesh !== ground) && ((mesh == throttleImp) || (mesh == brakeImp))); });

Should hornImp be included in that predicate?  Any other imps?  Perhaps red button?  *shrug*.  Just quick thoughts.     Excellent project, btw, love it.

 

[Mark Bufton]

I'll check that out now and let you know. Thank you :-)

[Mark Bufton]

Well, that certainly solved the problem of not being able to select it. It is working to some degree, I just need to tweak the code a little and add another reset for the horn.

Flaming knew it was something obvious haha. Guess I probably owe you at least a barrel of beer at this rate.

[Wingnut]

I got lucky.  The darned thing just refused to drag, so me and mister "pick" needed to meet at the console.log.    I actually added hornImp to the list of allowed pickables (that predicate at the end of that line)... and I saw hornImp drag a little bit, then freeze-up and refuse to drag any further.  But hey, it dragged!  Yay!

It was not really obvious, though.  Predicates are not what you would call "old school" or automatically intuitive.  When I was growing up, coding on vacuum tube computers, we didn't have predicates... just switch/case (case hornImp {blah}, case brakeImp {blah}, etc).  Predicates are VERY handy, but I didn't see/understand them... until about 2 years ago, and it happened right here in the forum.

Maybe it's not even called a "predicate".  Maybe that is called a "conditional".  Not sure, still learning.

I really like your scene.  It's turning out real nice.  Auran, eat your heart out!  (Does Auran still make train sims?  *shrug*)

No, I never coded on vacuum tube computers.    But I visited a transistor or two.

[Mark Bufton]

Yeah, this one will prove.....interesting. The 3 "imps" are limited by the limit() function I wrote and added into the drag and drop onPointerMove event listener (hark at me speaking like I know what I'm talking about haha). Mostly so they don't end up flying off somewhere never to be seen again.

Just got to get my function working to reset the hornImp to the horn off position on pointer up without having it immovable the 2nd (+) time, like I did the last time I tried it! At least it is moving now, and the horn is 'sort of' reacting.

[Wingnut]

I think it's all good.  You're doing "virtual dashboard" things with webGL/BJS... that have probably never been done before.  You are the first.  The "virtual joystick" thing, controlling a submarine... that I helped-with...  same thing.  We moved the pivot point of the "lever", and then monitored with a "limit" just like yours.  If .rotation > maxLimit || .rotation < minLimit... return.  You're probably the #1 pro at pointer drag-limiting, currently.  Who would do it better than you?  You are elbows-deep in it, right now. 

PointerOver / pointerEnter is rather important on these DnD VR dashboards/controlpanels.  If you can change a color or turn-on an edgesRender or highlightLayer... when pointerOver that particular controller... that tells user what they will hit... IF they pick/click.  Another cool "pointerOver" effect... is a little popup GUI label.  You know about all this stuff.

You're blazing trails, innovating, and there is no "right way" to blaze trails.  You'll try things, abandon them, return to them, it is sure to seem chaotic... but it's all cool, right? 

For future playgrounds and tests, try to separate the dashboard... from the loco, programmatically, structurally.  Someday, each "control" on the dashboard... might be a subClass of a baseController class.  There might be subClass types... switch(2 position snap-slider), positioner (notched slider), slider/dial (smooth variable)... and then these controller-class objects are "carried" in dashboard.controllers array.  Each type of controller, will require its own type of limiter, right?  They each operate slightly different and have different ranges.  A throttle controller, for example, (usually 9 notched positions including idle?) has special limit needs... different from a brake controller.  But whether its a brake controller, horn controller, throttle controller, they all start with new BuftonUniversalController()

Same with the train itself...  train.dashboards array holds all dashboard-class objects.  MyTrain is a new BuftonTrainClass object.  Dashboard1 is a BuftonDashboardClass object.  Fun!  Hierarchies!  OOP-stuff.  It starts looking just like BJS framework... Node -> AbstractMesh -> Mesh -> myMesh

And, once you "feel" that "modularity", you will be able to easily make playgrounds with JUST a dashboard.  Remember me mentioning those pointerOver popup labels?  Well, while moving a controller, controller.label could be continuously updated with controller.currentValue... so you don't even need to watch the console anymore.  Your controllerClass objects have a controller.label and controller.labelText... and perhaps a controller.imp and controller.meshShape. 

Slowly but surely, you gather all the "common" features that apply to all BuftonDashboardControllers... and you put them on your base class controller ("superClass" of all your in-game controllers).  You're getting modular and re-usable.  Yum!

Ok, one last fun thing.  A user named @altreality is "into" trains, too.  He is building a website called "Age of Steam"... and he was/is doing work on REAL OLD steam engines.  During his adventures, I stole a package of "stuff" from him.  I have not investigated it at all, but it makes a Cannon physics train car (a box with 4 torus wheels) go around on a fairly large circular track.  Inside the package... are 3 rather complex physics files ... loco.js, railVehicle.js, and wheelInfo.js.  I don't know if any of their code is being used in AltReality's demo, here.  You'll want to investigate.. if wanted.

http://webpages.charter.net/wingthing/misc/altRealityTrain.zip

I thought you should have that package.  It's carrying an OLD BJS and likely an OLD CannonJS... who knows?  Still, the "stuff" in those 3 physics files... looks... way good. 

Well, it looks WAY complicated... and in properly simulating locomotive physics... I think complicated HAS TO BE good.

Author of those files... unknown.  Likely, it is the same person who coded the Cannon rayCast rigidBody car.  It might be worth determining WHO, and get perms... if releasing something commercial.  Thanks to @altreality for loaning us this package!  Party on.

Hell, let's ping @schteppe for a visit... see if he'll stay for cookies and cider, and perhaps tell us what he knows about these train files.    He's good company, and the heroic author of CannonJS.  (Wingy hugs Schteppe for CannonJS and for the hell of it.)

[Mark Bufton]

Never thought of myself as a bit of a pro haha [he goes red]. Heck yes, I shall have a good read of those files. Will be challenging but I do enjoy a bit of a challenge :-D Cookies are in the oven!!!!

[Mark Bufton]

Can't believe that I have finally got it working. It didn't help that in my limit function call for the hornImp, I'd accidentally passed the minZ and maxZ arguments in the wrong order. The result was that the imp would move backwards, but not forwards. So, learned a valuable lesson in the process ;-)

[Wingnut]

Programming does exactly what you tell it to do, eh?   

Ok, we still got a windshield wipers issue?  Is that why this thread is not marked solved? 

If I wuz yoo, I would just make one basic wiper animation.  If you can, change the animation speed for the different wiper-speed settings.  Don't re-start the animation with each speed change.

Between each full wipe-cycle, check if the switch changed.  It will either be a speed change, or a stop command.

If you do it this way, no need for any animation blending, right?  You CAN do animation speed-changes mid-wipe, too, I think.  But for animation stop, that would be checked after completion of a cycle.  If switch @stop, don't re-start the animation.  Wiper is already "home", yes? 

Thoughts?

PS:  I picked-up Train Sim World the other day, the 2-pack with the CSX Heavy Haul and the Great Western high-speed transit route.  Its pretty stripped yet, but I got it with Steam, so I hope to see some free updates come down the line... or at least some fixes.  The tunnels are quite terrible yet, from external cam view.  Could be my MPU pukin' on a shader or something, I suppose.  Other things are annoying, too.  But... nice graphics/realism.  After I played, I swear my computer room smelled like locomotive grease and diesel smoke. 

[Mark Bufton]

Should work. Can't see why not. I'll try it now