-
You know you want it.
[url]http://www.mudmagic.com/codes/server-snippet/1558[/url]
[url]http://www.mudmagic.com/codes/server-snippet/1558/board/663/693[/url]
-
I implemented this on the testport and it appears to work fine. Basically I just used Kyndig's code from mudmagic and tweaked it a little, changing the pulse so we can pause for finer increments of time.
Something like the following could be done on for example, a say trigger:
````
say Greetings, $N. I will now tell you the story of King Alemnos.
mob queue 2 say Alemnos was borne into the royal family of Achaeus.
mob queue 5 say He raised an army of soldiers as loyal as they were skilled.
mob queue 8 say After some unpleasantness with the Emperor of Plith, he declared war on that city.
mob queue 12 mob echo $I scratches $s beard.
mob queue 15 say Right now he leads a federation of Athemia in war against Seralia.
````Keep in mind how this code works. It doesn't actually pause the mob prog execution - this would be near impossible to do elegantly. The program is run in one go, and the "mob queue" commands stack up a list of "events" with respective delays in a global queue. These are handled in the update handler and executed accordingly. Since the $* args are expanded at the time of mob prog execution, it doesn't have any problem parsing them. It's important to understand this to get the desired results - if, in the above example I were to add "say And that's the end of the story" after all of the mob queue lines, the mob would say the first and last line immediately, then all of the queued lines, which might pose some confusion for people who think that the Mprog is actually being paused.
After some testing of this, I'll implement it into the main game. I am generally not too big on snippets but this one was quick and easy enough to do. I can tweak it some more to allow finer delays if necesarry - but we had better decide on a standard before we start writing mprogs. Currently each "1" in mob queue corresponds to about half a second.
With a little bit more work on my part this can be expanded to rooms and obj progs as well, although I will have to work it in carefully to keep the room and obj interpreters happy.
Test away, and give me some feedback 8)
Reminder to self: can cause infinite recursion with something like this:
__Mob prog 1201:__
````
mob queue 1 mob call 1201
mob queue 2 mob call 1201
mob queue 3 mob call 1201
mob queue 4 mob call 1201
````
-
Actually, this right there also gives a type of multi-channel delay system.
mob queue mob call [ parameters]
It's not 100% the same as delay triggers due to the following that I can discern:
4. This allows the use of $q *AND* $n instead of just $q
7. Visibility becomes static at the time of the queue instead of determined at the time of the triggered script, since all the $-codes are expanded in the mob call, which may or may not be desired. What the entity can see at the time of the queue command determines if the called script can see, regardless if that changes during the delay.
10. Using parameters in the script call will LOCK the values in the script since the command is fixed at the time of the queue. This will allow the use of a mob servicing multiple players in concurrent "delays". Normal delay triggers are forced to use $q which can change from the time the mob starts a delay and when it fires the trigger, forcing you to code accordingly.
Example: mob queue 3 mob call 1234 $n
The only thing I'd like to see is the $-codes be handled differently with respect to #2\. Perhaps make a SEPERATE queue command that doesn't expand the $-codes until execution and pass a structure containing all the $-code information. This will have to be handled with care because any $-code could be made invalid by the time the command is executed.
-
~~@Nibelung:~~
> Actually, this right there also gives a type of multi-channel delay system.
>
> mob queue mob call [ parameters]
>
> It's not 100% the same as delay triggers due to the following that I can discern:
>
> 4. This allows the use of $q *AND* $n instead of just $q
>
> 7. Visibility becomes static at the time of the queue instead of determined at the time of the triggered script, since all the $-codes are expanded in the mob call, which may or may not be desired. What the entity can see at the time of the queue command determines if the called script can see, regardless if that changes during the delay.
>
> 10. Using parameters in the script call will LOCK the values in the script since the command is fixed at the time of the queue. This will allow the use of a mob servicing multiple players in concurrent "delays". Normal delay triggers are forced to use $q which can change from the time the mob starts a delay and when it fires the trigger, forcing you to code accordingly.
>
> Example: mob queue 3 mob call 1234 $n
>
> The only thing I'd like to see is the $-codes be handled differently with respect to #2\. Perhaps make a SEPERATE queue command that doesn't expand the $-codes until execution and pass a structure containing all the $-code information. This will have to be handled with care because any $-code could be made invalid by the time the command is executed.
I can definitely agree with this. I'll have to have a look to see how simple a delayed expansion of $-codes would be. It could be simple to do with a pointer in the event struct to the character which triggered the script. Two commands might be necesarry, but we might be able to get away without them - can we think of any useful instances in which we would WANT visibility to be pre-determined at the time the script is run?
-
To tell you the truth, nothing that I can think of that can't be handled by the expanding version in the same manner. Frankly, scripts should have 100% visibility on all $-codes. That's why there is the visibility ifcheck. ;)
