Mob scripts are the logical complement to the mobprograms. A mobprogram is run completely at once. While this is fine for a lot of tasks, it is inapropriate for a lot of other ones. Consider a guard patrolling along a certain path -- trying to do this with a mobprogram would result in the guard running the whole path in a fraction of a second, hardly something realistic. Furthermore, the syntax would not be very convenient to do this task.
The mob scripts on the other side have been designed for exactly that kind of job. Mob scripts are executed one single command at a time, with timing in units of a Pulse.MOBILE, which is roughly 2 seconds. A script command mainly consists of one single letter, which makes them very compact. The current available letters are:
n e s w u d
Each one lets the mobile simply walk in the direction designated by the letter. In the future any number of other single-letter commands may be added as the need arises. (Whitespaces and carriage returns are ignored so put them in whereever they might enhance the readability and omit them where not). With these options, already nice things can be made, like a guard patrolling around Midgaard. To have more options to do things there are special letters: The '#' followed by the name of a mobprogram simply invokes the mobprogram on the current mob. (After the mobprog name a whitespace HAS to be placed for distinction from the rest of the script). The called mobprogram is executed as all mobprograms are in a single step. By putting them into a called mobprogram, virtually any possible command for a mob can be done from the mob script.
Because it is not very convenient to have to write a mobprogram for very simple tasks for mob scripts, there is a syntaktical short form for this: Any mobprogram can be written from within a script by putting it within curled braces {}. What happens if the script interpreter encounters such a mobprogram is the following: From the whole text within the braces, a new mobprogram is being created, given the name of the script appended with a $ and the number of the program in the script. Then the whole section in the script is being replaced by a #-style call of the mobprogram. To be able to put more than one mobprogram-statement in one line, any semicolon (";") encountered in the text between the braces is replaced by a newline.
So you might consider putting the following script onto the midgaard baker:
s s { smile armorer; say Howdy! What a nice day!} n n
to have him walk to his fellow shopkeeper, greet him and walk back.
Syntax of ScriptsThe script section in the areafile has the following syntax:
Syntax Description (not part of the areafile) #SCRIPTS this starts the script section #TheFirstScript this starts a new script, called 'TheFirstScript' www sss eee nnn Now any number of commands in any order may be put #SomeMobProg Call 'SomeMobProg' { smile } implicitly define and call a mob program ~ end the script #morescripts define some more scripts ... ~ #0 ends the section
While we know now how to write a mob script, we do not know how to put it onto a mobile for execution. There are several ways to acomplish this, depending on the effect to be created.
First there are those scripts that are run in an endless cycle from the moment of creation of the mobile on. Those can be put on the mobile in the mobile section itself, at the position where triggers are put on mobiles by:
S <scriptname> <speed>
where
S is the sign for denoting a mob script entry <scriptname> is the name of the script in the script section (without the # and case sensitive!) and <speed> is a number greater or equal than 1, denoting the speed of execution of mob script steps, that is, on speed 1 a script step is made every Pulse.MOBILE, on 2 every second, 3 every third and so on.
A script put on a mobile this way will directly be started on the mob after it is resetted in the area and will be run cyclically while the mob lives, that means, after completion, the script is started anew.
Note: script execution is bound on the mobile update. Thus, script execution is stopped for every mobile in areas without player chars, unless the mobile has the UPDATE_ALWAYS flag set.
The second possibility for putting and activating a script on a mobile is by a mobprogram statement, e.g. in reaction of some events. To handle scripts from mob programs, several mob commands area available:
mob clearscript <target> Removes and stops any script from the given mobile. (Even those set in the mobile section can be removed this way). mob scriptdelay <target> <delaytime> If there is a script on <target>, a single delay of <delaytime> pulse mobiles is set on the script. That means, the next script step will be delayed by that amount. For example:
{ mob scriptdelay $i 5 }
will delay the script at that point for 5 Pulse.MOBILE.mob setscript <target> <scriptname> [speed] [cycle] Puts and starts the script <scriptname> on the mob <target>.
[speed] is the step speed of the script (same as in the mobile section), default is 1.
[cycle] determines whether the script is run only once (default if ommitted or anything else than 'true' or in an endless cycle (if equal to 'true').
The parameters [speed] and [cycle] may be ommitted.mob setscriptspeed <target> <speed> Changes the speed setting on the mob <target> to the number given in <speed>. This way, the mob scripts of course can alter their speed by themselves, simply by:
{ mob setscriptspeed $i <newspeednumber> }
Using these commands, mob programs and mob scripts freely can interact with each other. Some examples for this are given in the next section.
ExamplesHere we will list some examples for the usage of mob scripts and programs. In the midgaard.are the following trigger may be put on Hassan:
M give GiveHassan all~
invoking the program GiveHassan whenever he is given an item. The program could look like:
#GiveHassan smile say Thank you, I will put that into the pit for poorer ones. mob setscript $i pitscript 1 false ~
Hassan thanks the donator and puts a mob script on himself, running once on max. speed:
#pitscript
n { put 1. pit } s
~
This script is very simple, Hassan walks one step north to the pit (assuming he started on the temple square), he invokes a mob program to put the item into the pit and in the next step he returns to the starting point. By putting these actions in a script rather than in a program, Hassan behaves much more 'naturally', since the actions are performed with a speed comparable to that of a human player typing and executing these commands.
A more complex example is the mayor of midgaard. He has the habit of walking twice a day through the city, in the morning opening the city gates and in the evening closing them again. This can be acomplished very easily using triggers and scripts. First the triggers put on the mayor:
M hour OpenGates 6~ M hour CloseGates 18~
The first one triggers at 6 o'clock in the morning and the other one at 6 pm in the evening. Each one calls a mob program, consisting of a single line:
#CloseGates mob setscript $i closeGates 1 false ~ #OpenGates mob setscript $i openGates 1 false ~
They only have the task of starting the 2 scripts on the mayor for one single run. Here area the scripts, first the one of the evening, closing the gates:
Remarks (not part of the area file)
#closeGates
wwnnennnnn * walk from office to east gate
{close e; * define prog for closing the gate
say I hereby declare the city of Midgaard closed!; * some nice speech...
if rand 30; * and some random action
smile;
wave;
endif}
wwwwww * walk to the west gate
{close w; say I hereby declare the city of Midgaard closed!;smile;wave}
* the same as before, just in one line
sseeeeeeessswsse * walk back to the offic
{flirt sec;chuckle} * some socials for the secretary
e * go into his office, end of script
~
#openGates * like the script before, only that he opens the gates this time...
wwnnennnnn
{open e;say I hereby declare the city of Midgaard open!;if rand
30;smile;wave;endif}
wwwwww
{open w;
say I hereby declare the city of Midgaard open!;
smile;
wave
}
sseeeeeeessswsse
{flirt sec;chuckle}
e
~
Conclusion
With the mob scripts not only a convenient syntax for walking long paths has been introduced, the author of the area has now complete control about the timing of the actions of his mobiles. Through the interaction of scripts and programs, the actions can not only be stretched about an arbitrare space of time, but scedules for mobiles can be set on, scripts can be run, controlling their own behavior through embedded mobprograms.
For example a program embedded in a script may check certain conditions and as a result speed up/down the script, cancel or delay it for some time or even switch to a different script for execution.