Synopsis: How to delay mobprog command execution. April 98 From erwin@pip.dknet.dk Thu Apr 23 20:15:12 1998 Date: Thu, 23 Apr 1998 20:15:06 +0200 (MET DST) From: "Erwin S. Andreasen" X-Sender: erwin@shire.shire.dk Reply-To: erwin@pip.dknet.dk To: "Peck, Matthew x96724i1" cc: 'ROM-LIST' Subject: Re: Idea for mobprograms On Thu, 23 Apr 1998, Peck, Matthew x96724i1 wrote: > I had an idea for mobprograms and I thought I would pass it around, Problematic things: $n in program dies. Or $o disappears. Programs refers to them and bad things happen. Oh, and you'll also need to save the state of ifs, or let ifs and such be executed instantly. Nested ifs are not a problem though then. If you encounter an IF, if it is true, you remember next line as the next one to execute. If it is false, you skip until you are at the line AFTER the else, IF there is one, or then, until the ENDIF. Then execute as normal. Once you get to an ELSE, you skip until you find the corresponding ENDIF. Here is an older posting of mine on excactly that topic and how I solved the problem nearly 2 years and solved it again recently. From: erwin@pip.dknet.dk To: MERC/Envy Mailing List On Thu, 16 Jan 1997, Derek Snider wrote: > > Has anyone come up with a way of adding some delay to the parsing of > > mobprogram commands? > In SMAUG I added a prog type "script", which will sequentially run ONE line > from the program per mobile_update. I think this is what you want. > I also added a mpdonothing command (which does nothing), so that you can > put extra delays in the scripts. I've done something like this in my MOR (MobObjectRoom :) -progs: In any mob prog, you can do a "script +command" which will queue the command for execution. You can insert multiple commands by separating them with ;s (e.g. script +say You are brave..;;say But foolish!;say Die!), and use script + at any time again to append to current script (or script clear to clear). Also, it's possible for a mob to lock on to a player: if the player leaves the room, the script is cancelled. This is useful if you have a script line: script +, begins casting a spel;;;; : it gives the players a few seconds to run before it goes off, and the mob doesn't waste time afterwards trying to cast the spell on nothing. This can be done in any mob prog, not a special type of trigger. This way of queueing has the disadvantage that any if checks have to be resolved before you queue the commands, as the command are just parsed by the mob like it would have entered them. The performance is good: the script_update function uses less than 1% of total time: When new stuff is added to the buffer that contains the script, I expapnd it if necessary, when commands are executed I just advance a pointer and reallocate the buffer only when there's a lot of wasted space. It's a rather useful extension, and it was not very complicated to implement. I also (as I use Elwyn's Excellent Alias Code :) allow for the mobs to use speedwalking by doing e.g. a script +nnnsnenene: that will move them n, then next second n again etc. Great for guards that follow some schedule. IMHO an even better solution would be to combine mob progs and scripts, so that you can anywhere say: wait 4 and it will wait for 4 seconds: but that will involve things like: saving state of all varialbes (and what happens if the $n in the mob prog dies while you are waiting? what happens if a new trigger triggers on this mob?) With script queues like this, new mob progs are allowed to trigger: if the mob wants, it can check if it is scripting something and not start over again. ======= Since then, I've actually implemented the latter, using events. Saving all the variables is done by saving so-called keys of the objects/mobs: the keys can be used to retrieve the pointer again but will not retrieve dead mobs/objects. You can also lock on a person, and abort the waiting if they die. Number of instances of this mobprog thread can also be limited. It seems to work OK. C++ and events help a lot here; I have a Entity superclass which mobs, rooms, objects and areas derive from - this makes the restore/restart code a lot easier. I don't save calls however: if program A calls program B, and program B decides to do a WAIT then it seems to program A that program B has ended. ============================================================================== Erwin Andreasen Herlev, Denmark UNIX System Programmer <*> (not speaking for) DDE ==============================================================================