continued_at_new_forum The Wingnut Chronicles

[Wingnut]

Hi again, Chronies!   If anyone is bored, I have been chronicling my adventures with...

   - Learning to 'git push' to my Github repo --- from my home computer power/bash shell. 

Here is the never-ending story.  It's been one hell of a journey, so far.  I've lost a lot of blood, but the self-satisfaction levels are quite good.  Yay!

[jerome]

Welcome a git hell !

The only reward you can expect is to not break things !

[Wingnut]

Ya know... I released all those MIDI songs... because I KNEW I was about to begin... "GIT Your Butt In-Gear" (the self-abuse)... and I thought I might die from it. 

I "willed" those songs to the public.  heh

[Wingnut]

Speaking of "coming clean"... I once wrote an all-JS Infocom-like adventure game "system".  It sort of sucks and I'm not a great coder... but... if you're bored, have a look.  Feel free to torture it as you would an Infocom game, and beyond (it senses dirty words, even).  And feel free to try old favorites like plugh, xyzzy, and hello sailor.  It is also ready to do pictures for each room, but why not a BJS scene for each room, instead?  Cooool. 

Later, when we build Babylon Bay VR WorldServer, THIS is what I hope the interface looks like... except add a chat window and a BJS scene canvas, too.  Perhaps there is enough screen space for a small still-pic and some clickables, too.  Currently, nothing clicks, here.  Look, L, look cigar, look east, look red door, say 'open sesame', take, drop, (i)nventory, etc.  Lots and lots of verbs are honored (throw, kick, fart, etc)... but that doesn't mean they all have programmed responses, yet.  But maybe.  Try them all. 

This also uses a "hidden/revealed" system.  For example, you will not be able to see the screwdriver in the small hole in the brass lock on the red door... until you 'look red door', and then 'look brass lock', and then 'look keyhole', etc.  You need to reveal/discover the screwdriver...  before you can 'turn screwdriver'.    Also, it takes 5 'digs' to remove the pile of manure.

type help (enter) to see some help... but not much.  Always type L (enter) to see the room you are in (used often after you do things like look rope).  Typing info (enter) might be cool, and there are built-in object inspectors ... @or and @oi <anyobj> and report <anyexit>.

There is another "small" game called Shellyville which is based upon 'The Big Bang Theory' TV show.  Also, you will notice that a (n)orth movement from the wotas hub room, takes you to Shellyville, and a south from Shellyville... brings you back to wotas land.  Pretty cool, eh?  You actually "walk" from one game, to another, and back.  (Maybe no big deal for the pros, but for me, it's a miracle!  It makes the game "modular".  Cool!)

Robot, on (enter) wasn't working when I last checked.  Use +robot (enter) and it should turn-on.  I think it talks, follows, wanders.  The west wing from the hub room... is 10 rooms long or so.  It is a great way to test the robot's following speeds.  And no, robot, hush (enter) doesn't work on Wingy.

I could rattle-on for hours about wotas... because... it is VERY moo-like for being a damned web page.  I love moos. 

WOTAS stands for "Waste Of Time And Space"   

Don't report bugs.  Steal the code, give yourself credit for coding it, and then fix the bugs yourself.    Browse the folder, grab the zip, party on!

Long live the artists and storytellers!  FPS devvers don't stand a chance.  Puzzle games rule!  Girls love us more!

[Wingnut]

Hmm... a chap git-named gleborgne is doing something big.  What a beast!  My dog has been under the bed, scared, since I first hit the page.    

Looks like "borgie" might be some Vorlonite buddy of DK's, but not sure.  52 files changed!  That's... phew.  Did you "feel" the merge?  USGS Seismology saw it on the sounders...  2.4 on the Richter scale!  Beefy!

My lights dimmed a little... and the dog farted. 

[GameMonetize]

He is a friend of mine and definitely did a tremendous work. Now cameras support things like camera.addGamepad().addTouch() for instance!

[Wingnut]

Thanks DK, and thanks Gleborgne!

DK (and everyone)... do you "sense" that mesh also needs a system like this?  Or, let's think the OTHER direction...

In a way, isn't gleborgne designing actionManagers for cameras?  OnSwipeHere, onJoystickThere, OnMouseThis, onDragThat, onOrientHow, onGamePadThis, onTouchThat... you know.  Does anyone besides me... feel that gleborgne's system needs one more refactor... the one that converts it to be a camera actionManager?  *shrug* 

(I speak in generalizations, here.  I have not thought-out the far-reaching issues with a future camera-based actionManager)

Maybe BABYLON.joystick/gamepad/mouse/touchpad/orientcontroller/whatever "input objects"... need to allow ActionManagers to attach to THEM.  Then we can use those... to target cameras, mesh, lights, post-processes, ANYTHING.  It is the input-device "patch panel" that I have always dreamed-of.    Wire anything to anything. 

Addenda:  I think "keyboard" and "keypad" are "input devices" and should live next-to gamepad, joystick, touchpad, and orienter.  The Babylon Keyboard and Keypad objects... will become our new place to SUPER-EASILY hook keypresses to anything... including actionManagers.  Keyboard actionManagers would allow you to add events... like onControl_z and onShift_t... maybe.    Perhaps that is a bad idea. 

All in all, SOME Babylon JS genius will be able to design the super-dooper keypress router system.  Two easy commands, and control-f is hooked to your scene, somehow.  No eventListener adding (none exposed to users), no ondispose problems, just... easyKeys. 

[Wingnut]

Hi again.  I was recently looking at DK's early sneak-peek at the new system.  

First, I think it should be:

camera.inputs.add(VRDeviceOrientation);

and not...

camera.inputs.addVRDeviceOrientation();

I think if the 2nd way is used, it does not scale-up properly.  In the future, when there are 20-40 different input devices/methods, the 2nd way will make the system get heavy... with .addBlah(), .addBlahBlah(), .addFoo(), .addFooFoo(), etc.  It all could be done with .add(anything)... one method, no matter how many input devices are invented.   But the .add() would be code-heavy... needing to do analysis of the type of input behavior being added. 

Long ago, here on this very forum, I was shown/told that it is better to do many separate low-powered methods instead of one universal high-powered method.  I still don't have a "feel" as-to when/where this is good policy, and when/where it is not good policy. 

I'm not sure why someone would code a single universal .remove() method, yet NOT code a single universal .add() method.  I see inconsistency there. (But I hallucinate quite often, so I could "see" nearly anything.)  heh

----------------------

Now, in a different area... SOMETIMES an input device will control camera steering, and sometimes it will control mesh steering (and SOMETIMES control light steering).  Let's pretend we use an orienting device to control a downhill (Alpine) skier.  There are two activities needed.  1.  Steer the skier character.  2.  Look around-with the camera (steer the camera). 

Perhaps the programmer would use a button to switch between "steer camera" and "steer skier"?

This is why I thought about mesh also using this new "add_control_behavior" system.  Is the new system prepared for this type of functionality? 

Let's pretend the orienter steers the camera, by default. When user wants to steer the skier, a button press might do:  
    - camera.inputs.remove(camera.inputs.attached.DeviceOrientation)
    - skier.inputs.add(DeviceOrientation)  <= the way I like   ...or skier.inputs.addDeviceOrientation()   <= the way I dislike

Done steering skier?  Release the button and do:
    - skier.inputs.remove(skier.inputs.attached.DeviceOrientation) 
    - camera.inputs.add(DeviceOrientation)  /  camera.inputs.addDeviceOrientation()

* I removed "VR" references, because I am pretending that our orienting device is a rocker-board that the user will stand-upon, for skier simulations.

I question/ponder whether/not this new "input behaviors" system is prepared for these things, and is this what is desired? 

Is there some good reason why 'attached' is within these removal commands?  Is there such a thing as camera.inputs.detached.DeviceOrientation?  Is there a .detach() method on something?  If so, then we can use detach() / attach() and then no need for remove() on temporary detachments.  In other words, when it's time to steer the skier, we just call camera.inputs[2].detach(), and when done steering the skier, do camera.inputs[2].attach().

Sometimes I think that cameras and lights should ALWAYS have a "gizmo mesh" (ghost mesh) attached, and from then-forward... input devices can ONLY control actionManagers... ALWAYS... forever.    You can put these "input device actionManagers" on these ghost mesh... to control lights, cameras, other mesh, anything.  These actionManagers can do .executeCodeAction() too, of course, so the sky is the limit (total freedom).

Is it possible to "vote-out" systems that people try to contribute... that we don't want/like?  Gleborgne's system is a BIG BIG change... and I'm not entirely sure that it is headed in a good direction.  But, I hardly KNOW the new system AT ALL, so maybe I am being unfair to it and its programmer.

*shrug*  Thoughts, anyone?

[adam]

1 hour ago, Wingnut said:

camera.inputs.add(VRDeviceOrientation);

and not...

camera.inputs.addVRDeviceOrientation();

It appears you can do it both ways, but it is easier to do it the second way because you don't have to remember the type of camera and the type of VR device orientation.

[adam]

1 hour ago, Wingnut said:

In the future, when there are 20-40 different input devices/methods, the 2nd way will make the system get heavy

I don't think this is true in this case.

[GameMonetize]

The problem is that it is not  camera.inputs.add(VRDeviceOrientation);  but  camera.inputs.add("VRDeviceOrientation");

 

[Wingnut]

hahah.  uhn, well I am perfectly fine with that.   Any thoughts on the "bigger stuff"?

[GameMonetize]

On the bigger stuff, I really like the way it works today (obviously, as I validated it :)). I do not see any issue with future releases as I do not plan  to add thousands of new inputs

[Wingnut]

"We" (you) see no problems with rexx-like this.that.here.there.hit.fish.with.hammer = "You successfully knock-out the fish with the hammer."  ?

@Deltakosh  "the path to reach the value is too long."

You must admit... to-date, we have not exposed young coders to very much this.that.and.the.other formats.  We have kept a this.that... and this.that() format... almost exclusively.  Now we venture into the multiple periods... on a hot-for-new-users thing like cameras... OMG!  I think you are going to see the forum EXPLODE with camera questions.

But, you're the boss.    Please think-through thoroughly.  Thanks.   Everyone will love the new power... but we don't want the children to electrocute themselves when they turn it on.  heh

 

 

[GameMonetize]

This is wrong. all the math library is filled with fluent methods (I even wrote an article on it: https://blogs.msdn.microsoft.com/eternalcoding/2014/09/08/javascript-returning-this-or-not-returning-this-this-is-the-question/)

[Wingnut]

Young coders don't visit the math library.  Youngsters are concerned with scene.something, mesh.something, camera.something, and light.something (and similar) (imho).

But I'll cope, and reserve final judging... until I see the docs for this new system.  I can't hardly wait to see how this system will be introduced to the newbies.  I think they're going to flop like fawns on glare ice. 

Am I being a hag?    Sorry.  Lost one of my favorite clubs to play music-at... this weekend (I was booked for next weekend).  Lost a great gal bartender, sister of the owner, my friend, too.  Sucks!

And this git-stuff... damn... clones, forks, branches, commits, push, pull, stash, merge, heads, hunks, I think I'm going insane!  Trying out another GUI assistant lately... called GitKraken... seems ok... helps me visualize the "WTF" of git.    Learning upstream, origin, and remote, today... and some other stuff, too... staging and index and trees.  Ow, my head hurts!

[GameMonetize]

I see no problem as both solutions work.

Here is the doc: http://doc.babylonjs.com/tutorials/19._Customizing_Camera_Inputs

[Wingnut]

Hi gang!

   Wow, I have been GITtin' along with the little dockies... quite well, lately. 
(ar ar ar.  Git'-along, li'l doggies, ya know?  It's a cowboy thing.) 

In other words, I made a few contributions to docs... and it FELT GOOD!  I might be able to cope'n'deal!  YAY!  Recent reading about git... helped tons, too.  I have some suggestions for improving the web interface @ github, though.  I'll wait and learn more, then perhaps drop a note to the fine folks at Git Industries. 

Ok, let's talk about this 'debris' that is sitting at the bottom of http://doc.babylonjs.com/tutorials/19._Customizing_Camera_Inputs

What the heck is THAT?  A robot wrote that code, I bet.  I've seen prettier things stuck to the front grills of semi trucks.

So, essentially, if I wanted to build a custom-composed input object/interface for my old Saitek Cyborg 3D Gold joystick (or anything else that can find its way through plug'n'play-land and be recognized at the browser)... perhaps I would start with a copy of the BJS Gamepad input object? 

Then modify like crazy (but probably not much)?

I wonder if Vorlon Gleborgne will visit our campfire, talk about his new "super-connector", and enjoy terrible campfire coffee with us.

I wonder if forever-running threads like The Wingnut Chronicles and Tutorial Talk... could ever earn their "pins".  Would it be wrong for "non-official" threads... to be pinned?  Would folks say "Hey, who the hell does this Wingnut guy think he is... having a pair of pinned topics?  Of all the unmitigated audacity!" 

[Wingnut]

Hi again.

   Ok, I was touring various docs, trying to fix broken links and improve clarity, and I wandered-into our new materials library (click Materials Library button).  The two links (@Understanding Shaders) ...needed fixing, and I was hoping to re-target them to simple material or normal material.  I didn't know the difference.  So, I went investigating the normal material.

It's pretty cool.  http://www.babylonjs-playground.com/#22VQKB#2  (line 19).  Wow, this thing auto-colors mesh... nice!  Tooty Frooty!

There is nothing 'normal' about it, except that it probably uses vertex 'normals' to derive its colors.  I was also testing the "mixing" of diffuseColor and diffuseTexture... in this PG.  It is something I have never really tested before.  It works just fine. 

One interesting note:  Line 20 - I set a material ambientColor of mid-gray.  Line 5 - I set a scene.ambientColor of red.  But a normalMaterial has no ambientColor, and it has no _globalAmbientColor, and so... those two values never get multiplied (like they DO in StandardMaterial).

I have SO much to learn.  Party on!     

[Wingnut]

Hey Jerome... re: http://www.html5gamedevs.com/topic/21206-compound-polyhedron-of-icosahedron/#comment-121212

scene.actionManager.registerAction(new BABYLON.ExecuteCodeAction(BABYLON.ActionManager.OnMeshExploded, scene.sweepOrVacuum(mess)));

(Wingy quickly checks this thread's gun emplacements, making sure they are ready for invading Topic Police)  (TP's)    <- the smiley face doesn't help much when the words are THAT toxic, eh DK?  *sigh*  C'mon, slap me with a forum warning... let's see ya REALLY flex that muscle.  (yikes!)

Are we ready to continue the "forum policies" discussion that went dead in this thread a while ago?  DK, your last input was a LIKE on JC's "RTFM" comment.  Does anyone have any new thoughts, or is this part of the community frozen solid and inflexible?  No more back-room meetings.  Let's take it public.

My initial question:  Is there a shortage of forum question-answering custodians?  (which might be causing other issues)

#2.  Can we derive a quick-view diagram that easily shows non-English readers... which sub-forums is the proper place to post?

#3.  Discussion proposal:    I believe... we have a need for a "let's talk" sub-forum.  The user doesn't have a question, they have a PILE of questions and want to have a discussion with others... on a given BJS topic.  Collaboration.  This sub-forum will quickly be disliked by folks who struggle reading English.  But, I do not believe this is proper warrant to drop this idea from consideration.  I believe we do not have a "let's talk and experiment together" area.  I am not proposing any names, nor how often custodians should sweep/patrol it.  kbye

[chirping crickets.snd] 

[Wingnut]

That worked great.  Lots of responses.  *sigh*

Ok, let's try ONE MORE STORY before I completely abandon the idea of forming a League of Extraordinary Forum Custodians:

MikeX is a 19-year-old who lives on a rural farm in Kansas USA.  The farm is very remote and has no internet access.  MikeX is attending part-time tech school in Salinas, KS, 43 miles away.  On Tuesday and Thursday nights, MikeX has access to the school's computer lab... for two hours each night.

On Thursday night, MikeX tries to complete one of his class assignments... Learn how to load/view FBX models with Babylon.js ... by driving the 86 mile round-trip to that 2-hour computer lab slot.  He finally finds our forum, and nicely asks for assistance in loading/displaying FBX files.  But, he accidentally posts in the wrong place on his very first post to our forum, and somebody replies with "You're in the wrong sub-forum" and gives no on-topic help whatsoever.

Five days later (Tuesday night)... MikeX once again travels the 86 mile round trip to that computer lab to see what responses he received... and what does he get?  A kick in the head. 

He now knows that the assignment will be late, his dad (who loaned him the truck, gas, tuition) will be angry with the wasted trip, and MikeX is quite sad and discouraged with BJS.  How did this happen to MikeX?  It seems that MikeX had to follow some imposed rules of forum etiquette, but, because there is no League of Extraordinary Forum Helpers, no etiquette policies pertain to THAT mythical group.  86 miles, nearly 2 hours of driving, to get a kick in the head.  Nice!

Is that what this forum wants to be?  Is THIS the image it wants to portray?

I hereby end this apparently wasted effort to form The League of Extraordinary Custodians.

[JohnK]

Dear Mr Wingnut

It is of some concern that you write as if Mr K. N. Owmore the teacher of our course in BabyonJS relies on this forum to provide all the support for his students. Ken is a very dedicated teacher and not only has thoroughly covered loading and viewing FBX models and provided extensive notes before setting the assignment. He was also surprised to find that MikeX was accessing this forum and note relying on the notes provided. This is the reason he posted that he was on the wrong sub forum and gave no help. In his own use of the forum now that the new format has settled down he finds he his the only participant to reply in such a way and now regrets it. He hopes that he and all users will in the future will not be so sharp.

By the way the college computer system is also available to MikeX all day up to 5:30 PM on Wednesdays when he attends the course.

You Sincerely

Ms C H Ief

Principal

Salinas School of Technology, Music and Arts

[Wingnut]

hmm, one would have thought that SSTMA would condone and promote students seeking and gathering knowledge... from every source that they can find.  What a backwards school! 

Oh wait.  Kansas.  Yeah, they got electricity just last year.  Expect lag.  heh

[Wingnut]

Hi guys.  I stumbled across a strange playground, recently.  http://www.babylonjs-playground.com/#2KHPSP#14

I figure it belongs-to Pryme8 or Raanan or one of those other physics scientists.  Quite a fun machine, using our new physics interface.  It looks powerful, and the author of this playground molds it like clay.  Quite nice.

That PG might also hold the record for the most "little green square" playground errors, too.  It's all good fun! 

[Wingnut]

Hi again!  Lately I have been playing with a new way to use keypresses to control scene items.  Have a look...

http://playground.babylonjs.com/#2DYPYK

The keymaster object.  yay!  Currently, there are 6 keys that are "bound" to 6 mesh-rotate functions.  The active keys are:

control-shift-w  [ keymaster.csw ]
control-shift-a  [ keymaster.csa ]
control-shift-s  [ keymaster.css ]
control-shift-d  [ keymaster.csd ]
alt-shift-z  [ keymaster.asz ]
alt-shift-c  [ keymaster.asc ]

This uses jQuery, as we can see.  But it doesn't need-to.  It just needs great event handling (which it still lacks). 

When a "legal" event is processed by keymaster, the event is stopped completely. No defaults, no propagation.  I have not tested with things like alt-control-cursorUp.  I doubt it works for that.  Testing only alpha-numerics, currently.

What a strange way to process keypresses, huh?  Keymaster acts as a patch panel... an easy way to wire-up almost any keypress... to ANY function.  Or, perhaps, the whole idea is just idiotic.  heh.   Opinions, suggestions, and improvements... quite welcomed and appreciated.  Party on!