On 11 June 2010 09:16, James Paige <[email protected]> wrote: >> I assume that you meant (using the currently proposed script >> multitasking constructs): >> >> script, my script, begin >> new script (whenever loop) >> end > > Yeah, I was reckless with my example :) > >> (I think that "fork script" might be better than "new script") > > I agree. "new" is a bit too overloaded. I like "fork" or maybe "spawn"
"spawn" and "fork" sound nice (maybe we should have a poll?). Now if we could just find a phrase to replace "script thread". >> >> Does that seem like a thing that would be worth having? It seems pretty >> >> cool to me... but I can't think of any other language* with a similar >> >> flow control structure, which makes me wonder if it has already been >> >> tried and declared harmful by older wiser minds. >> >> I don't think it's crazy. But what concerns me is forking a script >> that runs forever - this can explode very easily. I also think it >> would lower the usefulness of whenever, because I think most such >> conditions will have exceptions. How about tying whenever to its >> parent script chain in some way? One possibility would be that if the >> script from which it was called exits, and whatever called that exits, >> etc, all the way back to the original plotscript/fork, then the >> whenever stops. For example, if you write a script >> MyAwesomeBattleSystem which runs a script SetupEffects which contains >> a bunch of whenevers which do various things, you'd probably want all >> those whenevers to stop functioning when the battle ends. However, >> MyAwesomeBattleSystem isn't necessarily a plotscript, it might be >> called from some main loop. Hmm. Maybe we could add a "stop all child >> whenevers" command. Or kill whenevers whenever their parent script >> exits. Or maybe this is getting too complicated. > > Probably. We don't really need a command like this, I just thought it > was interesting to think about. > > Although maybe some of those concerns would be resolved by a syntax like > > whenever (condition) do (action) until (condition) I suppose that's a fairly simple solution. Can't decide on whether we should add this. >> Food for thought: >> >> In a large script which does something in the background like walk >> NPCs about a map you want to exit the script as soon as the map is >> left. Unfortunately doing this rigorously requires checking whether >> the map has changed after every wait statement*. Otherwise the script >> will either throw an error or start moving NPCs on the new map (a >> common bug in Powerstick Man XE). My solution is (I'm planning on >> adding this script to plotscr.hsd): >> >> script, exit script on map change, begin >> new script, begin >> variable (this map) >> this map := current map >> while (this map == current map) do ( >> wait >> if (parent script == 0) then (exit script) # stop if the parent exits >> ) >> kill script (parent script) >> end >> end >> >> plotscript, rascal chasing a duck, begin >> exit script on map change >> # chase a duck ... >> end > > Nice! I really like that! > >> Adding whenever might make it simple to express such exit conditions: >> >> plotscript, rascal chasing a duck, begin >> variable (this map) >> this map := current map >> whenever (this map <> current map) do (kill script (this script)) >> ... >> end >> >> (Not sure about how killscript and whenever would interact) > > That is neat, but I think the "exit script on map change" is cooler. Yes, but I meant that I think it'll be common for you to want to do something like that, so it would be good to make it easy to do. A condition that is checked continuously while a script is active, and then does something. But there are so many different variations (should it trigger just once and then deactivate? should it pause if its parent script is paused? should it pause if its parent script calls another script? should it have access to variables in the enclosing scope, or should they be copied?) that I think it could be a waste to add something too specific. >> * Actually, now that I think about it, waitfornpc probably breaks when >> the leave the map! But wait. The obvious solution is the have any >> waits immediately broken when the map changes, but what if script >> multitasking is implemented, and the map is set to save NPC state? If >> an NPC is in the middle of a scripted movement when you leave the map, >> maybe you DO want the script to pause and wait for the map to be >> reentered? Maybe it would be reasonable to make this behaviour the >> default if script multitasking and NPC state saving are both enabled. >> Thoughts? > > Interesting. I guss right now it would wait for the corresponding NPC on > the new map. > > I would be inclined to make "wait for NPC" break the wait when the map > changes (probably with a backcomppat bitset for the old buggyish > behavior) and then add a new command like "patiently wait for NPC" that > waits even if you leave the map and come back. I think I'd prefer a command/directive like "pause script when map changes". Come to think of it, that could actually be implemented as a script in plotscr.hsd too, but it'd require one script thread per pauseable/paused script. (Hmmm, perhaps we need a "hidden script thread" command.) Alternatively, we could add a new script trigger, "map script". So that's my suggestion, except the future of triggers is a bit unclear. >> > //Check if ANY users are nearby >> > for user1 in all_users: >> > for user2 in all_users: >> > when (user1.x-user2.x < 5 and user1!=user2) >> > (do something) >> > end >> > end >> > end >> > >> > This will create a LOT of whenever loops to keep track of. >> > Alternatively, you could support some kind of "pick any user" flag >> > inside whenever loops. This would also consume resources (though it >> > might be manageable.) > > Seems like this would be better expressed as: > > when(any_users_are_nearby()) (do something) > > And then to put the looping check in a function named > any_users_are_nearby() But not totally equivalent, "do something" might contain wait commands. > --- > James > _______________________________________________ > Ohrrpgce mailing list > [email protected] > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
