Area
Building |
· Home |
| Scripts are a new scripting language for mobs, rooms and objects. In its current state it supports much more functionality that mobprogs. We have lots of plans, but here is a description of the current state. First, scripts are more 'c-ish' that mobprogs. That doesn't really help you much if you don't know 'c', but for those of you who do, you know this means curly braces! To begin, scripts are defined at the end of the mob, object or room definition, like mobprogs. All scripts begin begin with the '@' sign. This is a flag that a script is coming! After the '@' sign is the type of the script followed by any optional parameters. This document contains all the dry boring script definitions. For a discussion on script design, and for some examples, see Writing good scripts, and Script Examples.
The BasicsScripts are a powerful and flexable way to add life to an area. There are 4 types of scripts, mob, object, room, and area. The vast majority of scripts end up being mob scripts, because this is a great way to make your mobs more interactive and interesting. Scripts are triggered when various actions happen in the mud. For example, a @give script will fire when someone gives something to the mob that has the script, a @speech script will fire when someone says something in the room with the mob, etc. For rooms, an @entry script would fire anytime someone entered the room. There are also @rand and @time scripts that are triggered by the mud itself as time goes on. See the list of Script Types for a compelte description of all the available scripts. Control Structures and Syntax:Ok, so now you know a little about the script types that can be used.. it's time to learn a little syntax. Scripts are segmented into nested sections called blocks. All blocks are encapsulated by a curly bracket : '{' and '}'. Your script body is one big block with statements and nested blocks embedded within. For example, a simple script:
This script will fire 10% of the time and cause the mob (I'm assuming this is attached to a mob) to say 'hi'! Of course, you can't do much with a script unless you have some control structures.. ie, some ways to make the script do things under certain circumstances and do other things under other circumstances. Therefore, scripts support the if..then control structure. @rand 10~ This script will say 'hi' to a random creature in the room if the creature is a player and not a mob (player character versus a non-player character). Scripts also support the if..then..else control structure. @rand 10~ Even better, scripts support the if..then..else if structure. @rand 10~ Of course you can nest if statements as well. @rand 10~ And / OrIf statements also support and / or boolean oporators. For example the previous script could be re-written with an and oporator like this: @rand 10~ With an and statement, all boolean checks must be true for the entire check to be true, if any one is false, the entire statement is false. With an or statement, all of the checks must be false for the entire check to be false, if any one is true, the entire statement is true. With an and statement, if any of the checks is false, the script parser stops evaluating any other checks. So in the above example, if $r was not a PC, the script parser would stop, and not try and evaluate the $r.level check. With and or statement, the script parser must check each statement to see if it is true or false. NOTE: the script parser does not accept nested ( ), so the following if check would not work: if (@ispc($r) and ($r.level < 50)) The extra ( ) surrounding the level check are not needed.
Pitfalls for people who know CWhile scripts resemble C in so far as they use brackets to contain blocks, the similarity really ends there. The script parser is a very simplistic parser, and does not contain nearly the sohistication of a standard C compiler. No semicolons all over the place No bitwise and / or No parenthasis groups Whitespace is required
|