I'm not that familiar with the scripting engine, but what of a system of
condition/callback pairs?
For example, three scripts:
script, callback0, begin
...reveal a secret...
end
script, callback1, begin
...dimensional-portal opening...
end
script, callback2, begin
...make bubbles...
end
callback0 should fire every time a "day" passes.
callback1 should fire every time a two certain crystals get too close together
callback2 should fire every time a two certain crystals get too close together,
and there is a bubble mage
So the conditional functions could look like (I don't know plotscripting,
sorry):
bool function condition0()
{
if(dayHasPassed) return true
else return false
}
bool function condition1()
{
if( abs(redCrystalPos.x - blueCrystalPos.x) < 5 AND abs(redCrystalPos.y -
blueCrystalPos.y) < 5 )
return true
else return false
}
bool function condition2()
{
if(condition1() AND bubbleMageInGroup) return true
else return false
}
Register the callbacks with their conditional test:
registercallback(callback0, condition0)
registercallback(callback1, condition1)
registercallback(callback2, condition2)
The callback checking routine would need to run continually. Therefore, the
scripts should be non-blocking.
I think this would have the effect that events could take place outside the
map, but would affect the gameplay. Neh, maybe that's too much to implement.
> From: Ralph Versteegen <[email protected]>
> Sent: Thursday, June 10, 2010 10:39 AM
>
> > On Thu, Jun 10, 2010 at 7:50 AM, James Paige <[email protected]>
> > wrote:
> >> I have noticed that sometimes new users misunderstand how the "if"
> >> command works. I see someone write code like:
> >>
> >> if(condition) then(action)
> >>
> >> but this code only runs once in their "new game" script, and they wonder
> >> why "action" fails to happen each and every time that "condition" comes
> >> true
> >>
> >> This wouldn't work until script multitasking was supported, but what if
> >> there was a flow control command like:
> >>
> >> script, my script, begin
> >> whenever(condition) do(action)
> >> end
> >>
> >> This would be shorthand for writing:
> >>
> >> script, my script, begin
> >> whenever loop
> >> end
> >>
> >> script, whenever loop, begin
> >> while(true) do(
> >> if(condition) then(action)
> >> wait(1)
> >> )
> >> end
>
> I assume that you meant (using the currently proposed script
> multitasking constructs):
>
> script, my script, begin
> new script (whenever loop)
> end
>
> (I think that "fork script" might be better than "new script")
>
> >> 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.
>
> 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
>
> (Here parentscript is NOT the function described on the wiki, and
> means "parent script", not "parent script thread")
>
> 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)
>
> >> (* actually, I can think of one language that has something like this.
> >> The machine language for the ancient Daytronics System-10 mainframe has
> >> the EXU command which executes code any time a logic bit changes state.
> >> This is also the one and ONLY flow control of any kind that the language
> >> supports. All other flow control patterns have to be painstakingly
> >> cobbled together with a series of EXU commands and bit flips)
>
> Now there's a crazy idea!
>
> >> ---
> >> James
>
> * 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?
>
>
> Eeek! Top-posting!
>
> On 10 June 2010 16:48, Seth Hetu <[email protected]> wrote:
> > Lua scripters always tell me that this is easy as pie in Lua, though I
> > don't know first-hand.
> >
> > They also tell me that this leads to a problematic chain of functionality:
> >
> > //Trigger whenever a player's HP is below 10
> > when (player.hp < 10)
> > (flash screen)
> > end
> >
> > Which leads to:
> >
> > //Simplified form of "get a user who's nearby"
> > when (user1.x-user2.x < 5)
> > (do something)
> > end
> >
> > By itself, this is no problem. But then consider the user wants to
> > trigger "whenever two users are nearby". They could put the previous
> > fragment inside two loops:
> >
> > //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.)
>
> Such a flag would be totally impractical to implement.
>
> To me, the interesting assumption you've made in your example is that
> user1 and user2 have been copied, rather than referring to the user1
> and user2 variables in the parent function. I am planning on exposing
> the original variables in embedded scripts. But maybe this is a case
> for not doing that? And I don't like the idea of treating variables in
> whenever and in newscript differently. Also at issue is making local
> and global variables behave differently.
>
>
> The best way to write that using the proposed multitasking constructs
> looks like it'll be:
>
> script, foo, begin
> ...
> new script, begin
> for each (user1, all_users) do, begin
> for each (user2, all_users) do, begin
> if (user1.x-user2.x < 5 and user1!=user2) then (new script
> (do something))
> end
> end
> end
> ...
> end
>
> Also, hopefully script thread switching will be implemented really
> efficiently, so having hundreds of whenever's running won't be too
> worrisome.
>
> > I'm not saying this is a bad idea; I can see its appeal. Just giving
> > some thoughts on what users will expect once they understand
> > "whenever" triggers.
> >
> > -->Seth
> _______________________________________________
> Ohrrpgce mailing list
> [email protected]
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
_______________________________________________________
Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting
http://www.doteasy.com
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
