So this weekend I explored the possibility of running Entity script code entirely from a web browser. For example, here is Philip’s hypnotic FlockofFish.js entities script running in two different ways:
Of course… it’s not quite that simple. In my case it took something like ~3K SLOC of CoffeeScript to emulate enough of the APIs to get defaultScripts.js barely-loading without exceptions.
Just for fun here’s a screen shot taken from old single-core Android / Firefox (whopping ~6fps!). On iPad 2 / Safari it seemed workable though at around 30 fps – which might just be fast enough to tinker with actual objects on a Domain server over WebSockets or something.
Yeah totally – static analysis could go a long way here.
Back when generating an Overlays relationship diagram I was able to get by with a handful of grep|sed commands to extract the metadata, but to decipher the whole scripting API might require something more elaborate.
There is also a bit of state emulation needed to keep certain scripts from complaining – for example, returning reasonable results from Entities.getEntityProperties() depends on tracking values passed to earlier .addEntity and .editEntityProperties calls.
I tried loading your Hookgun scripts earlier and it looks like I’m still missing a few core methods like MyAvatar.addThrust, but in principle some unit testing etc. would already be possible on top of the current brute-force emulation.
EDIT: after mocking a few more functions the hook guns are now firing in-browser!
Yeah I noticed that too – when back at a good computer will have to run some more side-by-side tests to see where my bug is. Maybe I just need to maintain the object’s centroid when applying new dimensions?
Btw, that’s a very clever use of boxes to mock ropes!
On a different note, when tuning the physics did you ever wish you could rewind and reply time to test new parameters?
Because I keep thinking back to Bret Victor’s Invention on Principle video – especially around 10:30 in, where he leverages time as a free variable and “onion skinning” as part of the development process for physics simulations.
I had to actually test it constantly by using the tools, as I lacked the ability look. So isntead of any complex things I just decided to mix the target vector (GRAVITY) with the current GlobalVelocity with a 10% change per frame towards the target
Not the most ideal thing, Id rather have the engine handle the physics than me doing it via constant thrust, but Ill have to dig up on it.
Hmm, just discovered another way – apparently if you hold down the Shift key at just the right moment, Interface will place underlying scripting engines into debuggable mode…
Good question – this SHIFT hack seems to be a temporary kludge, so probably best to stick to the predictable Edit -> Console… case and manually load any particular scripts you want to work with from there.
To do that, hold down SHIFT continuously as you hunt for and click the Console… menu item – releasing SHIFT once the prompt appears. At that point you can type ‘debugger’ + Enter into the prompt and the QtScriptDebugger window should automagically appear.