+1 on lambdas and passing state.

One thing I might want to see (I'm not fully decided on it yet, and I'll say why in a minute) is a scenelet having the ability to watch the state of another independent scenelet and act accordingly. I've seen this particular paradigm called "co-threading" among other terms in numerous projects independent of each other and is basically how byuu was able to set up bsnes to interact internally.

I'm not fully decided on wanting that yet because I know it can be done using global vars and probably more simply as a result; also, it's more likely that it'd be easier to just add a fork at a particular point within the given scenelet based on the global var to handle the state in question. The not-yet-updated Artyxx demo shows the easier method in action, IIRC, so I know such a thing can be done practically.

An example of how I'd probably use co-threading in Artyxx would be one scenelet "controls movement of a mook" (aka "mook movement" and for this example set to loop at least 8 times if mook isn't killed), one scenelet "controls movement of a boss" (aka "boss movement"), and the "boss movement" scenelet would trigger a bullet spray if "mook movement" scenelet numLoops>0 && numLoops%2==0. It's an idea I've been kicking around my brain for a while and I know it'd enhance the perception of enemy AI in NShoot.

Just released 3.8, which fixes bugs related to doWhile and fork, adds lambda conditionals, and a bunch of under-the-hood refactoring.

@NEO
Yeah, not sure on that.  If I'm understanding this correctly, you're referring to something like what Lua calls "coroutines", where two functions run in a kind of relay race: One does what it needs to do then yields to the other, which does what IT needs to do then yields to the original function, and so on and so forth.  Cooperative multithreading, in other words.  Unless I'm misunderstanding and you actually mean something different?

"Cooperative multithreading" was the exact term I was looking for that was shortened to "co-threading," yes.

As I said, I haven't even completely sold myself on needing it explicitly.

Yeah, you can already kind of do this anyway, even without resorting to global variables. Every scenelet gets a reference to the scene running it as an argument to the update function.  All you do, in your mook mover, is have it increment a variable bound to the scene object (be careful not to overwrite any internal properties or methods!), then in your boss mover have it examine that same property and act accordingly.  For 3.9 I think I'll change it to not pass the scene object directly but a separate context object, to prevent accidents.

EDIT: Never mind, that won't work. Several internal scenelets (such as fork) rely on being passed the real scene object and would be a lot more complicated to implement otherwise.

Where can I download the latest Scenario script?

Where can I download the latest Scenario script?

The first page of this topic. Click on the "View Raw" link at the bottom of the Gist and then save that file.

I didn't see a gist there... until I hard-refreshed the page (ctrl F5). Xenso should do the same. That's a weird issue.

I didn't see a gist there... until I hard-refreshed the page (ctrl F5). Xenso should do the same. That's a weird issue.

I'd wager that's a result of a delayed or incomplete load of the GitHub script that embedding the gist actually calls. If so, that's a GitHub issue rather than an SMF or spheredev.org issue.

I didn't see a gist there... until I hard-refreshed the page (ctrl F5). Xenso should do the same. That's a weird issue.

Weird. What browser are you on? It works fine for me in Firefox 22 on Windows 7.

So, nearly two years later and the best I can come up with is a minor point release adding support for a minisphere-only feature (I may have fixed a bug or two in the interim as well, but I'm not positive on that).  Oh well.  In any case, Scenario 3.8.1 is available.

For anyone that doesn't know, Scenario is now included with minisphere as part of miniRT, since way back to version 1.1 in fact.  It works exactly the same as before, except you include miniRT.js (using RequireSystemScript) instead of Scenario.js and you use "new mini.Scene()" instead of "new Scenario()"