All right, fixed it.  Very embarrassing regression, the fix was a trivial edit to one line of code.

Regarding Scenario 3.7, I can't really see how Scenario variables are more useful than JS ones since they're set before the scene is run instead of during, which makes them equivalent to regular variables, no?
[snip...]
If set() accepted a function instead of a value, then it could call the function at scene run time to produce the value. scene.variables could be a function that accepts the name of a variable and returns a function that returns the value of the variable. Other scenelets could then accept that function and get the variable's value. In code,

Code: (javascript) [Select]

scene.movePerson('hero', 'north', 5 * GetTileHeight(), 1, true)
     .set('heroX', function () { return GetPersonX('hero'); })
     .set('heroY', function () { return GetPersonY('hero'); })
     .panTo(scene.variables('heroX'), scene.variables('heroY'), 1)
     .run();

Yeah, I really only added variable support to get loops to work.  To be fair though, scenelets can modify variables as well (via the scene.variables object), but your lambda method is certainly better.  But really, this is the a good case in point for why I want to do a dedicated scene language, as it illustrates a use case where the intuitive method of doing things doesn't work properly.


So anyway, I do know that adding the new features is going to majorly increase the size of Scenario's codebase, which is why I was thinking of making it an optional component.  If you just include Scenario.js, you get exactly what you do now (plus whatever other new features make it into 4.0), and then you could also require 'SceneLanguage.js' or something to get the new scene language parser.

Yeah, I really only added variable support to get loops to work.  To be fair though, scenelets can modify variables as well (via the scene.variables object), but your lambda method is certainly better.  But really, this is the a good case in point for why I want to do a dedicated scene language, as it illustrates a use case where the intuitive method of doing things doesn't work properly.

I agree a dedicated scene language is almost necessary once you start adding more advanced features such as variables and loops. JS is not a very good host language for internal DSLs, unlike say Ruby where you could create a little scene language within Ruby. I'm not entirely convinced a whole new language is the way to go though (despite the fact that I've already written one).

So anyway, I do know that adding the new features is going to majorly increase the size of Scenario's codebase, which is why I was thinking of making it an optional component.  If you just include Scenario.js, you get exactly what you do now (plus whatever other new features make it into 4.0), and then you could also require 'SceneLanguage.js' or something to get the new scene language parser.

That sounds like a good approach. Again, if you want help implementing the scene language, I'd like to help you.

By the way, the call scenelet is broken: it should be [].slice.call(arguments, 2) since state isn't an explicit argument anymore.

By the way, the call scenelet is broken: it should be [].slice.call(arguments, 2) since state isn't an explicit argument anymore.

Whoops.  I don't think that one would have taken very long to bite me, as I use that functionality in a couple places in Specs. Thanks for the heads up!

On a sidenote, I do really like the lambda-function approach to variables, I think I'll implement that for Scenario 3.8.  I already have the call scenelet to call functions at runtime (functionality which, as noted above, I do use), this would just be an extension of that mentality.

Edit: Fixed the call scenelet.

Code: (javascript) [Select]

scene.movePerson('hero', 'north', 5 * GetTileHeight(), 1, true)
     .set('heroX', function () { return GetPersonX('hero'); })
     .set('heroY', function () { return GetPersonY('hero'); })
     .panTo(scene.variables('heroX'), scene.variables('heroY'), 1)
     .run();

I just realized, your above code could be done much more simply with the focusOnPerson scenelet.  I know it was just an example, but I don't know if you were aware or not:

Code: (javascript) [Select]

scene.movePerson('hero', 'north', 5 * GetTileHeight(), 1, true)
     .focusOnPerson('hero', 1.0)
     .run();

I just realized, your above code could be done much more simply with the focusOnPerson scenelet.  I know it was just an example, but I don't know if you were aware or not:

Code: (javascript) [Select]

scene.movePerson('hero', 'north', 5 * GetTileHeight(), 1, true)
     .focusOnPerson('hero', 1.0)
     .run();

Oh, thanks! I actually wasn't aware of that, in fact I was using call() to fake something like my above example with lambda-variables. Perhaps I should have read all the way through the code....
Still, I'm sure there are probably other use-cases for lambda-variables. Either way, I think they'd be worth it because the current approach doesn't really work in an intuitive manner. Although they're quite ugly. :/ (This is where a dedicated scene language would be a big win.)

This is where a dedicated scene language would be a big win.

As would JS having a proper lambda operator, but can't win 'em all I suppose. (CoffeeScript has one I believe, but I hate everything about CS; coming from a C background, I rather appreciate JS's Java-ness)

Is there a way to persist a scene? For example: you save the game during an ongoing event. Load the game and it's still going on. So I guess in that case scenario may be used for more than just a static cutscene that rips control away from the user. Picture the "city fair" scene from Chrono Trigger entirely ran by Scenario (the runners, bumping into the girl, the teleport).

It's probably something best suited to a layer between persist/analogue and Scenario.

That would be a ton of work, require major changes to the architecture, and I don't know that Scenario is really the best application for that anyway (seems better done in realtime with the entities' command generators or some framework wrapping those). I'll add it to the to-do list and see what I can do anyway, though.

Edit: The biggest problem I can see with Scenario being used for this is, suppose a background scene like the runners in CT is going on and then I want to do a cutscene wherein one of the runners walks over and talks to the heroes. The problem: the background scene wants to force him to keep following his path, causing odd things to happen. You could pause the whole running scene, but that might not be desirable to have all the runners just abruptly stop in their tracks.  Whereas if it's done in real time, you just suspend command generation for the one entity and everything's fine.

In case anyone missed it, I put up another hotfix earlier to fix the doUntil and doIf scenelets.  By now it must be painfully obvious to everyone that 3.7 was put out in a big hurry.   Remember kids: Haste makes waste!

That's not the real reason I'm posting, though. The real reason is to get suggestions for Scenario 4.0.  I want 4.0 to be awesome, so I figured I'd solicit suggestions from the forumites here, now that I know people actually use Scenario (in one form or another ).  So far my feature request list looks like this:

• Scene scripting language (tentative - may drop)
• Use lambdas to set variables dynamically at scene time and pass them to scenelets
• Ability to persist runtime state of a scene across sessions

Anyone have anything else to add to that list?

A scenelet debug overlay. YES.

See a graph of forks, sync spots and the current tracking through the scene. I'm sure this will be a challenge, but I mean it only takes looking at the current queue.

@Radnen
Neat idea, I'll see what I can do. Technically you have to look at more than just the current queue, you basically have to traverse the whole graph, since forks can be nested and sync is local to the fork level it appears in (this is more intuitive than waiting for all threads and also prevents deadlocks).  It'd be an interesting challenge to implement, to say the least.

I am unsure of the utility if this, though. Scenario is simple enough in concept that it's pretty easy to tell at a glance exactly what will happen when the scene is run. A debug view like this seems like a lot of work for little gain.

Every little bit helps

But, I'd wait a couple months or so until people start pointing out flaws or
engaging themselves in ideas where you can take it, then proceed on updating any further.
Or when you yourself have pooled a good collection of ideas to weed out and then implement.

Makes sense to me, but just an idea.
Love to see more projects from da Bruce.

So I just refactored the doIf and doWhile scenelets to take a function as its argument, to be unveiled in Scenario 3.8.  This allows you to use normal JS variables instead of relying on the clunky Scenario-specific variable implementation in 3.7.  Here's an example:

Code: (javascript) [Select]

var loopCount = 0;
new Scenario()
    .doUntil(function() { return loopCount++ < 3; })  // loop 3 times
        // add scenelet calls here
    .end()
    .run();

I want to say at this point that the set scenelet is redundant, as you can just use call to do anything else you need to do, like modifying variables or calling API functions.  The only real problem is passing variables to scenelets, so I may need to keep the set scenelet around anyway...

Haha, just found another bug: If you put a fork in a loop and the loop executes more than once, the forks will trample each others' state data. The problem is that a context is only created for each instruction once--when it's queued.  If the same instruction is encountered again (as in a loop), it reuses the same state data, which is a problem in a multithreaded situation.   Will be fixed in 3.8, for now don't try to use fork in a loop unless you synchronize at the end of each iteration.