> 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" > >> 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) > 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. > * 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. > > //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() --- James _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
