continued_at_new_forum The Wingnut Chronicles

[Wingnut]

Hi kids!

   I've been doing a bit more work on my wotas (waste of time and space) Infocom-like all-js text adventure game.

http://urbanproductions.com/wingy/babylon/wotas/wotas20/wotas.htm  (get the zip, too). 

Today, it became a text adventure game with a BJS scene on each game object.  So far, it is the SAME BJS scene for each object, but that can change later.  Thanks for the cool BJS scene, Jerome.

There's about 15-20 rooms in this adventure, so far.  The coolest thing is to go north from the hub room (type 'n' and enter).  See that?  It goes to a different file/game!  I LOVE THAT!  South from Shellyville, and you're back at the wotas hub room.  Seamless integration between game modules! 

Okay, okay, sort-of seamless.  Notice that you are not carrying anything when you get to Shellyville.  When you left wotas, you had a ton of junk in inventory.  It's not easy to drag adventure game objects through a game-change exit/entrance. 

SOME info available by entering help and info.  Control-mousewheel for some screen/font sizing power.

Grab the zip, steal all the code, call it yours, make your own games from it.  Everything is on-board, including the latest version of BJS.  What's that you ask?  Game-authoring docs?  Get real.     Look carefully at buildgame.js and shellybuild.js, you'll have authoring mastered in 3 hours. 

There's still lots of work happening on the project... mostly with containment and "integration messages".  Adventure game objects have some 'states' that need to be dealt-with.  Containers can be opened/closed, devices can be off/on, and if you want a proper "magical" environment, objects can also be glowing/not, vibrating/not, humming/not, etc.  When a glowing device is inside an open container, you should see it glowing when you look at the container.  When the container is closed, the inside device is not "revealed", so you won't know it's glowing (with a look at the container).

In a room, an orb might be in the room's contents, so it is seen, of course.  But if the orb is glowing/humming/vibrating, it gets more attention.  A string called integration_msg  is 'assembled' by object state managers.  IF the object is glowing, for example, then a message such as "The orb is glowing." is added to the end of the room's description.  The object's glow-state is integrated. 

This will also happen with opened containers that hold glowing things.  The glowing thing's integration_msg is added to the container's description, and you will see that "state" message when you look at the container IF it is open.  And naturally, containers themselves have an integration message too... telling whether they are opened or closed.  But opened/closed integration messages are lower priority than glows, humming, etc.  We do not need the open/closed status of every container in a room... integrated onto the room's description.  Only if something is humming, glowing, or vibrating (or a million other "unusual" states that objects can be in)... do we need to know, via description-appended integration messages.  Yikes, eh?

Integration messages are "assembled"... after a state manager checks is_glowing, is_humming, is_vibrating, is_on, is_off, is_opened, is_closed, etc.  And if you are REALLY good, you can code state polling funcs that build strings that handle multi-states.  "The orb is ON, glowing, and vibrating." 

"Blockers" and "attachments" also have integration messages.  In the hub room's description, you'll see 3 integration messages... covering 3 blockers and an attachment.  Blocker #1 - "A giant pile of Gwackoo poop is blocking the northeast exit.".  Blockers 2 & 3 - "There is a red door to the east, and a blue door to the south.".   Attachment #1 - "Attached to one of the walls in this room... is a spigot, also sometimes called a faucet." 

Lots of work, eh?  *nod*.  Integration messages SUCK to code, but make all the difference between a good adventure game, and a great one.  +robot (enter) to activate robot.  robot, on (enter) is still broken.  help robot works.  robot, talk is fun.  I think he/she has about 15 lines that it randomly says. 

Ahh, the world of text adventure games.  It's a world of brain tumors.  heh.  Sort of off-topic, though, sorry.   Party on!

[Wingnut]

http://www.babylonjs-playground.com/#1CMD3G#12

Just ridiculous, eh?  *nod* 

No mousewheel radius change on the arcRotateCam in Firefox.  hmm.  I miss that.

[GameMonetize]

I'm gonna check the firefox issue

[GameMonetize]

Ok found

Update in progress

[Wingnut]

What was that?  About 17 secs?  Phew.  You're the best, dk! 

deltakosh.brain.clone(Wingnut)...  (enter)  (enter)  (ENTER)  (darnit!)

Error:  Mad Scientist level 50+ required for that action. 

Mousewheel works perfect, Delta Flyer!  Tested  A++  100%  yay!

(previous links to wotas and its zip... now updated to match)  (exciting!)

Ok, so, um... Spacecraft Assembler v1.0, now, eh?  Automatically builds spacecraft out of BJS basic elements.  Ready, everyone?
   (Wingy feels a tumor forming, and the dog is missing, again) 

[Wingnut]

Hi gang!  Well, I forgot how to program playgrounds, apparently.

http://playground.babylonjs.com/#1BTGPV

Should I be able to do console.log("test") inside a scene.onDispose function?  Seems I should. 

It seems I am having problems getting scene.onDispose to trigger.  But I have been learning many new things, lately, and some of the old things got pushed out of my brain.   

I am trying to use scene.onDispose... to remove a red-border div that I added to the canvasZone earlier.  Fail, fail, fail.

The primary objective of this playground... is for Wingnut to begin doing playground-based visualizations (diagrams).  I want to retrieve a repo from github... and have BJS create a bunch of boxes... one for each file name in the repo, and also label each box WITH the file name.

More specifically, I want https://github.com/BabylonJS/Babylon.js/tree/master/src/Cameras/Inputs

Let's look at the first file name... babylon.arcrotatecamera.input.gamepad.js.  I would like to have THAT name printed on the box, AND the class name itself... ArcRotateCameraGamepadInput ... also printed on the box.

So, not only do I want to query the repo to get all the file names, but then I want to use those file names to read each file, and "glean" that class name from each file.

What a gruesome endeavor for Wingy's first BJS data-viz project!  Apparently, I love pain.    In theory, it should be possible.  https://developer.github.com/v3/repos/contents/#get-contents

ANY and ALL help with this... is GREATLY welcomed and appreciated.

[GameMonetize]

Oups...I fixed the bug regarding onDispose

 

Sorry about that!

[Wingnut]

Thanks for the fix, dk. No need to apologize.

I think this github-glean project is dead, anyway.  Security blockades at every turn.  So close, yet so far.

(Wingy beats XHR with a sledgehammer... in his mind.)  heh

I can clone our source repo and use nodeJS to drill data from it.  That's the way to work-around XHR issues, maybe.  But, you know, living diagrams that are derived from our latest source versions... would auto-update.  (built on-the-fly)

There is another angle.  What if... "diagram generators" resided AT our source repo on github?  Essentially, another playground at github.  Perhaps its playgrounds would have more security access to the files in our repo.  (eliminate some XHR blockades).

PG demos that run THERE... might have better access to our source repo (queries, data-gleaning). 

I would love to "see" our source repo... dynamically live-derived... in 3D tree view (BJS scene).  *sigh*  Auto-diagraming is hard work.

[Wingnut]

Hi again, Chronies!  Over in Tutorial Talk, I mentioned creating this playground... from this website demo. 

(Different skybox, no big deal, I hope.)  As we can see, the trees are much brighter in the playground version.

I have tried adjusting light.intensity for the pg, but it does not completely "fix" the issue (cam gravity off, here).

http://playground.babylonjs.com/#25Z6LR#1

The trees in the pg... look different.  Frosty.  It's as if their normals are bent, or their UV's slid sideways, or something. 

Both use same .babylon file (with Tree.tga alongside). I just moved them to my github site. 

Anyone want to help me fig WHY the trees look different/brighter in the PG?  Thanks.

[eboo]

something with light position

tested with   

var light = new BABYLON.DirectionalLight("dir01", new BABYLON.Vector3(0, 1, 3), scene);

http://playground.babylonjs.com/#25Z6LR#2

[Wingnut]

Yep, that has an affect, thanks for testing, eboo.  Problem is...  view-source... http://www.babylonjs.com/Demos/INSTANCES/instances.js

That is the code from the website demo.  It uses (0, -1, -0.3).

Me thinks something changed in the framework... between the version that the website uses... and the version that the playground uses.

But that is speculation.  More likely, Wingnut is screwing-up something.  The two demos DO use different skybox images... and... just possibly... we are seeing a reflection of the skybox... on the tree limbs.  But, that's quite unlikely.  No significant change seen when changing from skybox/skybox1/skybox2/skybox3/skybox4.  hmm.

[GameMonetize]

PG and demos on babylon.js site use the same babylon.js file

[Wingnut]

hmm.  Ok, thx.  I'll abandon that project, momentarily.

New project:  http://playground.babylonjs.com/#BIVOB#2

I combined a Jerome-made SPS demo... with an Eboo mad-scientist demo, and I am trying to get the spotlights to colorize/light the SPS particle material... as the particles pass beneath the lights.  Essentially, I'm trying a "glitter cannon", here.    Or... if you've ever seen a chromium artificial xmas tree with a color-wheel light on it, you know the effect.  heh

If anyone wants to "run with it", please do.  As you can tell, I have not had great success, so far.  But I think I see SOME particles getting colored.  I am hoping for a bigger effect.

Experiment at will.  Report successes and fun failures, if you please.  SPS particles have REAL GENUINE BJS standardMaterial on them, so... they should react to lights.  Possibly a problem with backFace lighting and/or sideOrientation on the planes.  Texture currently not in use... just solid color. 

I failed Glitter 101 in kindergarten.  :/  Party on!

Update:  http://playground.babylonjs.com/#BIVOB#3  turned off hemi-light, widened light cones/frustums.  *shrug*  Still lots of black planes.  hmm. 

[GameMonetize]

THat's a great stress test for the engine

[Wingnut]

uhn, yeah, it IS a little "heavy", eh?    Ok, ya know what, guys?  I forgot to set mat.maxSimultaneousLights = lightsCount; in line 104 area.  The particle material was still at 4 lights max.  Fixed it.

But then, I dropped to 15 fps... so... I reduced light count to 64.

http://playground.babylonjs.com/#BIVOB#4

Still not really "sparkling" with color like I hoped.  hmm.  Light color-saturation seems limp, even though I am using a *2 multiplier in the light diffuse (line 120), and a *2 intensity (line 124).  Hmmm, any "hotter" and I'll see more color wash-out (all white) on the particles.  Need a different approach... maybe a dome-o-spotlights.    Still playing.  FUN!

[Wingnut]

Hi kids!  Off topic, but, a few of you have asked for some short videos of Wingy being foolish with his bass guitar, so here ya go.  No stream... bout 2 min DL each.  This is the first gig with this band, but we each have over 35 years of exp.  (yawn)  (you'd think we'd be less high-school-ish after all that time). 

So, what else is shakin'?  Dal is looking for collaborators with an Octree LOD terrain, which sounds pretty cool.  I have no idea what that's all about, but help him iron-out wrinkles if you can.  Contact Dal if interested.

Brochington has a new room-scale VR camera... cool!   Sebavan... PBR rocks, and ascii art post process?  Neat!   Nockawa... still kicking butt on Canvas2D and doing excellent documenting and announcing along the way.  JohnK... building an alternative docs interface... nice.  NasimiAsl... still doing wonderful things with ShaderBuilder and GeometryBuilder extensions... while Wingy, who promised to help document and write some more tutorials about it... has been pathetically lazy.  I want to learn more about shaders, first, and then I can promote-up SB and GB... cuz it's a niiiiiiice system.

And Deltakosh and his core buddies... kickin' butt and takin' names, as always.  Do those core guys EVER sleep?

Heck, LOTS of people are working-on excellent projects, and hopefully... having some good summer fun.  Our forum is becoming quite a knowledge base and just plain interesting reading.  I learn TONS... by reading the forum and by monitoring people's projects.  Keep up the great work, everyone... you are making history.

I've been screwing-off... not getting much programming done at all, but I sure am enjoying the BJS show you all are putting-on.  I love hanging around this forum... it's where "the movers and shakers" (webGL trailblazers) seem to gather, and that's what makes it wonderful.  I'm proud and honored to be here, and with ya'll.  It's not every day that a person can find THIS MUCH COOL... at these low prices.    Party on, gang!

[gryff]

Well I looked at all the videos Wingy - no Tom Russell** yet ?

And video 6 - Love Potion #9 - an old favourite around Liverpool  - hardly a C&W town

cheers, gryff

** For the Europeans:  Spanish Burgandy,  St Olav's Gate, and then for N.Americans  Blue Wing (you listening @Deltakosh- "south side of Seattle" - 2nd verse) which he used to play in the bars of East Vancouver. He actually has a song about N. Wales - my neck of the woods - was C&W ever so broad?

[Wingnut]

  You must like pain, Gryff.

I think we need to buy Drummer Lou's wife... a tripod... and maybe a quick video-shooting course.  And lead player Ben... aiming his light somewhere other than onto himself... what's the story there?  These kids nowadays.    Didja see me drop my pick, and then reach in my pocket for another, not find one, and have to reach to the floor to get the dropped one?  On break, I realized there were 4 picks on top my amp... easy grab.  Sad.  We were all pretty nervous.

Gryff, you are a music encyclopedia.  (Gryff "worked with" some hot music acts in earlier years, and hung around with some "big dogs" in his Liverpool days.  PM him for cool stories.)

All in all, we should probably get back to BJS...  it's more interesting than my crap variety band. 

[gryff]

54 minutes ago, Wingnut said:

Gryff "worked with"

Err ... you mean carried the equipment, Wingy 

And you betray my age - what is this old dude doing trying to use BJS ?

cheers,gryff

[jerome]

really nice videos and songs Wingy

[Wingnut]

@gryff They're all jealous of our age, G-man.  Had we not smuggled NCSA Mosaic out of Budapest and handed it to Blaxxun, these BJS youngsters would still be using turtle graphics.    They worship the water we walk-upon, ya know?  heh

[jerome]

[gryff]

6 hours ago, Wingnut said:

and handed it to Blaxxun

Ahh, @Wingnut my Blaxxun days - worlds  and avatars. Selling stuff in Cybertown to people from Australia to New York, from France to Prince George (BC) .

Even had stuff stolen - including my own voice - for cheap short lived copies of Second Life.

cheers, gryff

[Wingnut]

See, that's how you learned to be the killer modeler that you are today.  I can understand why people steal your stuff.  It's good stuff!

Anyway, folks, today I take my first dive into camera inputs, trying to learn enough to give this thread a decent solution.

Currently, I'm working with this playground, trying to clear all inputs and attach ONLY a mouse.  I think I was successful, but I am getting an error.  Help at will.

I'm also working with another playground, trying to hijack the FreeCameraDeviceOrientationInput into the playground, but I haven't been able to activate the hijacked code, yet.

Aside:  Somebody was working hard on this playground.  I am studying that, too.  Pro code, there.  When big dog programmers go experimenting, I want to bookmark those for later Wingnut enlightenment activities.    There's a vrCamera.setCameraRigMode in line 72 that is just delicious... and I really need to learn about these "rigs".

checkInputs func might be the place to give our 15-hour-wait user... a solution.  I'm going to keep learning, but I'm sooooo slow.  Any help is certainly welcome.

Pertinent links:  https://github.com/BabylonJS/Babylon.js/blob/master/src/Cameras/babylon.cameraInputsManager.js 
https://github.com/BabylonJS/Babylon.js/blob/master/src/Cameras/Inputs/babylon.freecamera.input.deviceorientation.js
https://github.com/BabylonJS/Babylon.js/blob/master/src/Cameras/VR/babylon.vrDeviceOrientationCamera.js 
http://doc.babylonjs.com/classes/2.4/CameraInputsManager 
and of course...  http://doc.babylonjs.com/tutorials/Customizing_Camera_Inputs

@chicagobob123 - I thought I would ping you because your reply is correct, there are ways to dispose (remove) specific attached inputs.  You can see some in line 14 and 15 in this playground.  SO, you might just as well come along with us and play with these camera inputs.  Let's invite @Terminator to visit, too.  Terminator, I come here to talk (incessantly) about these issues, because I didn't want to mess up your thread with possible wrongness (which falls easily out of my mouth quite often).  So, feel free to follow along with my camera.inputs playing, here.  AND DEFINITELY... everyone... tell us what you learn!  thx

Again, I believe the 't' is null/undefined error is possibly a framework bug...  seen in this playground .  I'm too newbie to know for sure, though,  This is fun learning, though.  I am considering making some diagrams, for easier learning.  Ideally, I would like to let JS and BJS "make" the diagrams FOR us, dynamically, though.  That way, the diagrams change when the framework changes... and we never need to "paintbox" changes to docs diagrams.  Help wanted.    Our new Canvas2D system should make in-playground diagramming... very possible and much easier than ever before.   

[chicagobob123]

You rang, 

I am having a real time trying to figure out the input system. 

I worked on moga gamepad controls and found out the right joystick isnt working but I have no idea why.

I wont know much until I get my blue tooth adapter for my PC and stop using my phone to test with. 

I found gamepadAngularSensibility and  gamepadAngularSensibility to be difficult to understand. 

Sooo I wrote stuff myself to work with the moga gamepad based on BABYLON.Gamepads 

That is easy enough to understand. You start it. Then you use the information for feedback.

Never got the onrightstickchanged of the moga to work on my android though. 

You do the camera position updates in the before render with a simple function.  function UpdateCamera() {}

Thats where I am on the game pad side of it. 

    function StartGamePad()
     {
      var gamepads = new BABYLON.Gamepads(gamepadConnected);

     // for google chrome start the monitoring if navigator.getGamepads() has a gamepad at index 0 for example
     // this is because chrome doesn't seem to support the gamepadconnected/gamepaddisconnected events perfectly yet,
     // it only detects the gamepad if you plug it in again but not if it is already connected

      if(navigator.getGamepads()[0]) {
      gamepads._startMonitoringGamepads();
     }
    }

    var gamepadConnected = function (gamepad) {

     gamepad.onleftstickchanged(function (values) {
      writeToScreen("onleftstickchanged "+values.x+" "+values.y);   
     });
     gamepad.onrightstickchanged(function (values) {
       alert("onrightstickchanged Worked");
     
     });

     gamepad.onbuttondown(function(bi) {
      buttonIndex=bi;
     });

     gamepad.onbuttonup(function (bi) {
      buttonIndex=-1;
     writeToScreen("Button Up "+bi);
     });

    };

 

PS I use this div tag and function to give me feedback 

    <div id="MessageDisplay1" style="position: absolute; top: 50px; left: 50px; color:black; touch-action:pan-y;"></div>

     function writeToScreen(message) {
      var pre=document.getElementById("MessageDisplay1");
      pre.style.wordWrap="break-word";
      pre.innerHTML=message;
     }