Mars Base Alpha Four. The Technicians manual.

  1. General Building Info
    1. Overview of Building
    2. How to get a flag
    3. Credits
    4. Building an area
  2. List of Building Commands
    [A-C] [D-E] [F-K] [L-O] [P-S] [T-Z]
  3. Queries
    [A-C] [D-F] [G-M] [N-R] [S-Z]
  4. Making your own commands
    1. Simple Commands
    2. Success and Failure
    3. Changing Player ID
    4. Automatically executed commands
    5. Variable referencing
    6. Command parameters
    7. Using Queries
    8. Embedded Newlines
    9. Drop To's
  5. Alarms and Fuses
  6. Pronouns

1 General Building Info

1.1 Overview of Building

Building on MBA4 - so how do I start?

Here is a nearly complete guide to building on MBA4.
This has been majorly adapted from the UglyMug Manual Text Files. ~Gushie.

The reference manual is all very well if all you need to know is the syntax of a command, but it's a bit bewildering when you don't know what any of the ideas mean. This section sets out to restore the balance, by providing a (hopefully) simple introduction to The Gentle Art of Building On MBA4.

Probably the first thing to do is to present a small example of something that's been built. Let's take a really simple thing to start with: a study. It's a room with a way in and out, a desk, a chair, a computer on the desk and a chiming clock.

The first thing to do is to work out roughly what you want in the room. In this case, I've already done that --- it's the list shown above.

The next thing to do is to have a think about each thing you want to build, and work out what type of MBA4 object would be best suited to it. There are eight kinds of object in MBA4: Alarms, Commands, Exits, Fuses, Players, Rooms, Things and Variables. I'll always use a capital letter when I mean a MBA4 type --- Room rather than room, for example.

OK, so when do you use each type? Here are some rules:

  • - If you want a 'location' in an area --- something that people can be inside, look around and talk to each other --- use a Room. Rooms are created using ' @dig'.
  • - If you want an inanimate or mechanical object --- a table, a clock, a book or a bookcase --- use a Thing. Create these using '@create'. Things can hold other Things, or even Players.
  • - If you want a way of getting between two places --- a doorway, walking in a direction --- use an Exit (' @open').
  • - If you want anything more complex, see later in the manual!
  • Looking at our simple example, we can see that the study should be a Room, the ways in and out should be Exits and everything else should be Things. We can see how to do most of it, although making the clock show the right time and/or chime could be troublesome.

    So how do I get my Room?

    It's quite possible to dig a Room and pretend it's in the middle of a vacuum --- in fact, if you don't do anything else to it, that's where it will be. Newly created Rooms are just empty spaces, with no relationship to anything else in the game. So:
    @dig Gushie's Lab
    Gushie's Lab created with room number #244.
    You own anything you create, so you can examine this new room using 'examine' ('ex'):
    ex #244
    Gushie's Lab (#244 R)
    Owner: Gushie(#213 PCRT); Key: *UNLOCKED*; Credits: 10; Flags:
    Contents:
    Mass Limit: None.
    Volume Limit: 10000 Litres
    So the new room has no contents, no ways in or out - in fact it's a perfectly normal piece of empty space.

    Now that we've got our Room, the next thing to do is to make it something other than an empty shell. Real rooms, such as the study we're trying to represent, don't just have a name. They're not all uniform, cubic, unlit grey spaces. So it is with the study we've built. It needs:

  • - a description,
  • - a size,
  • - some indication of how it's lit.
  • To describe a room you can either use 'edit #[ID]' or the following:

    You can set the description of a room using @des[cribe]. For example, our study could be described as follows:

    @desc #[id]= This is a small room in the complex.\
    There is a window opposite the door which gives a view of the rough martian terrain. Over the window is a cream coloured blind, half torn down one side
    \
    The walls to the room are a pale grey, and have coffee stains down them from when Gushie has got into a blinding rage and chucked his mug at the wall. The floor is covered by a threadbare carpet which also has coffee stains, and also a few annoying bits of blu-tack.
    There are several things to note about this description:
  • - It tells you about the room itself; nothing about the room's contents. We're going to represent the contents as Things anyway, so we don't need to mention them in the description as well.
  • - It gives keywords (window, martian terrain, curtains, carpet, maybe even coffee stains) of things that aren't really Things in their own right, but that a player may like to look at. We need a way of doing this.
  • - It says nothing at all about ways into and out of the room. We'll create these using Exits later, so there's no need to say anything about them In the description.
  • - It mentions the room's size. We need to set this up.
  • Since we're still involved in setting the room up, the next thing to do is to set the Room's size and weight limit. You do this using @vol[ume] and @mass respectively.

    Lets say the room's about 4 metres by 3 (12' by 9', for those who still work in Imperial units). That's 12 square metres. The ceiling of most houses is about 2.5 metres (8' or so), giving a volume of 30 cubic metres. MBA4 volumes are in litres; you get 1,000 litres in a cubic metre, so the volume of this room is 30,000 litres. To set this, type:

    @volume here=30000
    An interesting sideline: if you look back to the listing of the room's properties that we got using 'examine', you can see that its volume is set to 10,000 litres. Although this sounds like a lot, it's not much larger than a normal broom cupboard.

    The weight limit of the room is worked out similarly, except that we have to make some intelligent guesses as to what the floor will stand. We've said that it's a back bedroom; the floor (which is wooden) will probably take several tonnes before collapsing. So, we guess at around five tonnes (five tons, too). MBA4 masses and weights are in kilograms; at 1,000 kg per tonne, that's 5,000kg:

    @mass here=5000
    So, we have now set up an isolated room. It has a description and it's the right size. However, we still have to connect it up to the rest of MBA4, and we still have to fill it with Interesting Things For The Players To Play With. Read on, O intrepid technician...

    Making the Right Connections

    An isolated room isn't much good to anybody; it needs linking into the rest of the game. There are two parts to this:
  • - It needs ways in and out (done using Exits),
  • - It needs to be placed in an area.
  • (See section about areas). Now that the room's been placed in its correct area, we can set up ways into and out of it. Let's assume that we've already built the corridor of the house, and described it. We want to create a doorway that's the way out to the landing. We use an Exit for this job.

    Exits are created using '@open'. This requires a list of exit names. Each name in the list is separated by a semicolon (';'). The first name in the list is special --- it's the one that is displayed in the list of 'Obvious exits' when you look at the room. If a player types any of the exit names, (s)he tries to go through the Exit. So, for a door to the landing:

    @open An electronic sliding door;ele;electronic ;electric;sli;sliding;door;out;exit;cor;corr;corridor
    This looks like a very long list of possible names, but don't panic. It was made up by using the following rules:
  • - Make the first name as descriptive as possible ('An electronic sliding door). Remember, the players will never need to type this --- they'll use one of the short names from the rest of the list --- but it's the one they'll see,
  • - Use any obvious nouns and noun phrases from the first name ('sliding ;door;electronic...etc'),
  • - Use the name of the Room to which the exit leads ('corridor'),
  • - Use any abbreviations you think the players will type ('cor;corr'),
  • - If it's the only way out of a dead-end room, use the standard sequence 'out;o;exit;back;leave'.
  • The exit is created in whichever Room you are at the moment. If this happens to be the wrong one, don't panic; you can pick the unlinked Exit up using 'get' and drop it in the correct place.

    Now that we've created the exit, we can link it to the landing. As MBA4 doesn't understand 'corridor' unless you're in the room, you need another way of referring to it. The usual way is to use the ID of whatever you're referring to (it's the number preceded by # when you look at something you own). This number is unique to the object and is guaranteed to refer to it at all times. So, if the landing is printed as:

    Corridor (#4756 R)
    then you can link the door to the landing using @link:
    @link door = #4756
    If you now examine the Exit, you will see:
    An electronic sliding door;ele;electronic;electric;sli;sliding;door;out; exit;cor;corr;corridor(#284E)
    Owner: Gushie(#213 PCRT); Key: *UNLOCKED*; Credits: 0; Flags:
    Contents:
    Location: Gushie's Lab (#244 R)
    Destination: Corridor(#4758 R)
    Exits work in one direction only --- just because we've created an Exit from the lab to the corridor, it doesn't mean we can get back again. To do that, we need an Exit going in the other direction as well. It's time to take a look round our study, remember its ID (we'll need it to link the Exit from the corridor) and step outside:
    out
    Now that we're on the landing, we can create our Exit into the study. It should re-use as many of the names from the 'out' Exit as possible. Since we already know the ID of the Room we're linking it to, we can open the Exit and link it all in one command:
    @open On your left is an electronic sliding door;left;l;lab;gushie;left door = #244
    We've had to alter it a bit, as there will be other electronic doors going to other Rooms. This one is the one on the left, so we've called it that. We've also fixed the other names so that they include 'left' where needed.

    Just to make sure, we can now go back to the lab:

    lab

    Exciting Exits

    Just as Rooms are different, so are Exits. It's not just their names, either; you may wish to change:
  • - whether an Exit is seen as soon as you look at a Room, or whether a player has to look for it,
  • - whether you can see what's on the other side of an Exit, and what you can see if you can't see through,
  • - who can go through an Exit,
  • - what happens when players try to use an Exit.
  • So, going back to our study, we might decide that the door is closed except when somebody opens it to go through. Since it's a solid electronic door, nobody can see through it. To make this kind of Exit, you set it OPAQUE:

    @set door=opaque
    If an Exit is OPAQUE and a player looks at it, they see whatever the Exit's description is. In this case:
    @desc door = It's large and grey and has a little sign on it saying\
    'Exit'\
    You can also see a small dent in it, obviously one of Gushie's tantrums again...
    lab
    Since the door's OPAQUE both ways, we had better do the same thing to the Exit from the landing:
    out
    @set lab=OPAQUE
    @desc lab = It's large and grey and has a plaque on it saying\
    'Captain Gushie's Room'\
    You had better be quiet when walking down here!
    lab
    If we hadn't done this and somebody looked at the door, they would see straight through it and into whatever Room is at the far end. This works fine for open bits of land (or open-plan houses), but it's not so good for doors.

    The OPAQUE flag controls whether you can see through an Exit or not.

    If we look at the study now, the Exit announces itself:

    Gushie's Lab (#244)
    This is a small room in the complex.
    There is a window opposite the door which gives a view of the rough martian terrain. Over the window is a cream coloured blind, half torn down one side
    The walls to the room are a pale grey, and have coffee stains down them from when Gushie has got into a blinding rage and chucked his mug at the wall. The floor is covered by a threadbare carpet which also has coffee stains, and also a few annoying bits of blu-tack.

    Obvious Exits:
    ele
    : An electronic sliding door(#284)
    Remember that only you see the # codes because you own them, all other residents see exactly the same without the codes.
    Most of the time, this is fine; but what about less obvious exits? In our case, how about a fire escape:
    @open window;wind;win;w;martian;terrain;t = [ID of terrain]
    gives us an exit through the window to the terrain. Since it's not going to announce itself, it doesn't need a fancy label as the first part of its name. All we need to do now is to make the exit a hidden one, using the DARK flag:
    @set window = DARK
    We don't want it OPAQUE, since we want a Player to be able to see through into the garden.

    We've now set up the static parts of the Exits, but haven't really thought about what happens when a Player tries to go through one. First of all, can they? This may sound silly, but things like a toughened glass window are pretty hard to get through --- yet, with an Exit, you can see what's on the far side. And, even if you can get through, what do you need?

    Access through Exits is controlled by the Exit's lock. A full description of locks is given later in this manual; for now, let's just note that you can lock an Exit to any logical expression involving bits of the game. Since we want to be able to get through the window (a quick route to the terrain while we're building things), but we don't want anyone else to, we can lock the Exit so that we're the key:

    @lock window = me
    This says that if anyone else tries to use the Exit, they'll fail.


    1.2 How to get a flag

    A Technician is a resident who is able to create scenary and commands. It is suggested that you have spent sometime looking around MBA4 and the manual before you request a Technician flag.

    To get a Technician's flag email mba4@alpha4.com. Since the Admirals don't really want that many technicians you will probably be refused but there is no harm in trying...
    You will probably be asked for some kind of proof that you can build and that you understand the manual. The Admiral or Head Technician will give you a small amount of credits for you to start. If you need more then you will have to justify yourself. For large projects, see an Admiral.


    1.3 Credits

    When you first become a Technician you will be given a few credits.
    If you need more then ask a Captain or Admiral and they will look around your stuff and tell you what is wrong. If they think it's total garbage they will discuss it with an Admiral or Head Tech and may take away your Technician flag. If they think it's under parr then they will not give you any credits until you fix it. If it is good they will give you some credits and a big smile.

    Costs

    Come actions have an associated Credit usage.
    Credit usage
    Command Quota
    @dig 10cr
    @create 10cr
    @open 2cr
    @command 20cr
    @variable 10cr
    @fuse 20cr
    @array 10cr

    1.4 Building an area

    In an attempt to keep MBA4 relatively organised, the powers that be would really like it if you organise your rooms into areas. The advantage of doing this, apart from neatness, is that you can place commands inside your 'top room', and they will work in any rooms in that area. Furthermore, a friendly Captain (if you can find one) will place your 'top room' into 'Top Area', enabling MBA4-wide commands like 'address' to work fully.

    To illustrate, allow me to indulge you in an example. I wish to create a house for myself, place it in an area, then get a Captain to move it to 'Top Area'. I'll try to make things easier to understand with diagrams of the area structure at each stage.
    The first step is to dig myself a 'top room'. This room won't have any entrance or exit; think of it as a container into which you place all your rooms. Other than that, it's just an ordinary room.

    @dig My top area My top area created with room number #250
    Now I proceed to dig the other rooms in the house.
    @dig Bedroom=Very messy, wouldn't want to be in here too long
    @dig Bathroom=Dear oh dear, a plumber would be nice around here
    @dig Kitchen=This is a laboratory for breeding new life forms
    @dig Living Room=Judging by the organic matter on the floor...
    At the moment, none of the rooms of my house are in an area. Commands like 'newscheck' will not work, and I won't be able to @open any exits from any of them. This is an important point: you have to control the room's area (and it must have one!) before you can open exits from it. If you attempt to do this, MBA4 will reply with the message 'You don't control (whatever)', where (whatever) is the name of the area containing the room. If the room isn't in an area, '*NOTHING*' will be displayed instead.

    To place the rooms in #250 (my top area), I use the @tel command thus:

    @tel #263=#250
    @tel #354=#250
    .
    .
    The first number being the id number of each room.

    MBA4 will respond 'Located.' for each of these commands. Now I can @open exits from these rooms to make the house navigable. Now that my house is in an area, I can put commands in #250 that will be available in all four rooms.

    There's one more thing to do. Wandering around my little house, I still can't use commands like 'newscheck' - I need a Captain to @tel #250 into 'Top Area'.

    tell Gushie Please Sir, could you move #250 into Top Area?

    Gushie tells you, "No problem my loyal technician."

    That's all there is to it! The MBA4 architecture from my point of view now looks like this:
    <BR>
        ------------<BR>
        | TOP AREA |<BR>
        ------------<BR>
             ||<BR>
         ----------<BR>
         |  #250  |<BR>
         ----------<BR>
             ||<BR>
  +-------+------+-------+<BR>
----    ----    ----    ----<BR>
|  |    |  |    |  |    |  |      <---- my house<BR>q
----    ----    ----    ----
    In most cases, when you get a Technician flag, the Admiral will automatically give you a top room and put in top area for you. The above is just in case we get busy and forget...


    2 Building Commands

    Syntax: "@array <name>"

    Creates an array initially with no elements.
    To create/reset an array element use the @desc command. e.g.

    @desc array_name[1] = This is the first element. @desc array_name[20] = This is the 20th element.

    To retrieve an array element use the @?desc query. e.g.

    @echo {@?desc array_name[1]}
    This is the first element.

    To destroy an array element use the @dest command. e.g.

    @dest array_name[20]

    will destroy the 20th element in the array shuffling all the remaining elements down 1. e.g. what was the 21st element will now be the 20th element etc.
    Players are restricted to 100 elements in an array.
    See also @?elements, @?exist, @?next, @?size, @?dictionary.


    Syntax: "@beep"

    Echoes a BEL character to your terminal. On most systems, this will cause a beep.


    Syntax: "@cfail[ure] <command1>=<command2>"

    The failure arm of "<command1>" is set to point to "<command2>". This means that when "<command1>" is executed, if the last simple command in it FAILS then control is transferred to the start of "<command2>". See also "@csuccess".


    Syntax: "@chpid"

    Short for CHange Player ID, this command is only useful inside a compound command. Normally, compound commands run with the ID of the player who invoked them; however between an "@chpid" and an "@unchpid", any commands use the ID of the owner. This causes the player using the command to be able to do anything that he/she is normally authorised to do, plus anything that the owner of the command is authorised to do. At the end of the command the "@chpid" ends, so in a series of commands it is necessary to have "@chpid" in each.

    This allows adventure-writers to create commands such as:

    @command OpenSesame = @chpid\
    @link door = #1234\
    @describe door = The door stands invitingly open. \
    @unchpid


    Syntax: "@command <name> [=commandlist]"

    This command creates a compound command. When any one of the ""s are typed, the "<commandlist>" (if any) is executed. The command list consists of a list of other commands on separate lines. The "<commandlist>" is the command's description, and can be set and changed using "@describe", or "edit"
    Use \'s to protect newlines.


    Syntax: "@controller <player|puppet> = <player>"

    Sets the controller of "<player|puppet>" to "<player>". You must control "<player|puppet>" already to do this - practically, this means that it is only useful if "<player|puppet>" is you, one of your existing puppets, or if you are an Officer.


    Syntax: "@create [ = <description> ]"
    Return value: The ID of the thing.

    Creates a thing with the specified name and specified description. Creation uses up 10 credits. Inside a command, directly after an "@create" the value of "$0" is the room's number.


    Syntax: "@cstring <thing>=<string>"

    Sets a string to be used instead of `Contents:' when a container is looked at.


    Syntax: "@csucc[ess] <command1> = <command2>"

    Links the success arm of the "<command1>" to "<command2>". This means that if the last simple command in the commandlist of this command ("<command1>") succeeds, the second command, "<command2>" is executed. See also "@cfailure" (section ). If you csucc a command to "HOME" then MBA4 will continue to search up the area tree for commands with the same name and then execute them.


    Syntax: "@desc[ribe] <object> [ = <description> ]"
    Return value: OK or Error.

    "<object>" can be a thing, player, exit, room, command, variable, or array/dictionary element specified as "<name>" or "#<number>" or "me" or "here".
    This sets the description a player sees when they use the command "look <object>". Without a description argument, it clears the message.

    For an exit this is the message a player sees when they try to look through the exit, if it is set OPAQUE.
    A commands description is its list of commands to execute.
    A variables description is its value.
    A \ at the end of the line is used for a new line.
    Most users will find the 'EDIT' command easier to use instead.
    See also Colours and Arrays.


    Syntax: "@destroy <object>"

    This command permanently destroys a game object. Players can only be destroyed by Captains. However puppets of players (which could also be players) can be destroyed by their controller, so watch out! Things cannot be destroyed if they are keys. It is a good idea to destroy or recycle unwanted items so as to reduce the rate at which the database expands. Destroying an object refunds the amount it of credits it cost to make. If you have lots of useless things, the Captains will get nasty. Remember to unlink exits before you destroy them or you will use the credit it cost to link it.
    See also Arrays


    Syntax: "@dictionary <name>"

    Creates an dictionary initially with no elements.
    Dictionaries are basically arrays, but instead of using numbers as indices, you can use words.
    To create/reset a dictionary element use the @desc command. e.g.

    @desc dict_name[wibble] = This is element wibble. @desc array_name[flibble] = This is element flibble.

    To retrieve a dictionary element use the @?desc query. e.g.

    @echo {@?desc dict_name[wibble]}
    This is element wibble.

    To destroy an array element use the @dest command. e.g.

    @dest dict_name[wibble]

    Players are restricted to 100 elements in a dictionary.
    See also @?elements, @?exist, @?next, @?size, @array.


    Syntax: "@dig <name> [= <Description>]"
    Return value: The room ID.

    Creates a new room with the specified name and displays its ID number (so that you can link exits to it). Inside a command, directly after an "@dig" the value of "$0" is the room's number. Digging a room costs 10 credits due to high real estate costs.


    Syntax: "@drop <object> [= <Message>]"
    Return value: OK or Error.

    This command sets a message to be seen by the player who drops the object. Without a message it clears the argument. This happens under different circumstances for different object types:

  • [Thing] drop message is activated when a player drops it.
  • [Exit] drop message is activated IN THE RECEIVING ROOM when a player goes through it.
  • [Room] drop message is activated when something falls through its dropto.
    Syntax: "@echo <string>"

    Echoes "<string>" to the player who invoked the command. Useful in compound commands to give information to the player. Used instead of success and fail if and only if you need variable substitution.

    Example:

    : @echo The time is: {@?realtime}
    The time is: Thu Feb 4 19:52:14 1993


    Syntax: "edit <object>"

    Enables you to change the description of objects that you own, in a nice user friendly(?) interface.

    Commands include:

    .end
    To leave the editor and save changes.
    .abort
    To leave the editor without saving changes.
    .up
    To go up a line.
    .down
    To go down a line.
    .top
    To go to the top of the description.
    .bottom
    To go to the bottom of the description.
    .delete
    To delete the current line.
    .view
    To view the description and give some statistics.
    .wipe
    To wipe the buffer.
    .commands.
    To give you an uptodate list of editor commands.
    See also Colour.


    Syntax: "@else"

    See @if.


    Syntax: "@end"

    See @if.


    Syntax: "@eval[uate] <expression>"

    Returns the result of evaluating "<expression>". The expression can be string, numeric or both. Most standard comparison and arithmetic operators are supported.

    Results of comparisons are numeric --- `0' means FALSE and `1' means TRUE. Brackets can be used to group subexpressions; otherwise, precedence is STRICTLY LEFT-TO-RIGHT although you can use parentheses.

    Arguments are space seperated so if you need a space in an operand then it must be surrounded by double-quotes.

    Bear in mind that @eval handles floating point as well so you may have to use int or dp sometimes.

    Arguments to commands are substituted before the variables are so be careful. The following will NOT work.

    @test {@eval $1 = ""}

    because if $1 is empty @eval will just see

    ' = "" ' which is meaningless. Use instead:

    @test {@eval "$1" = ""}

    Below are the operators that @eval understands.

    Obvious ones are =, !=, <, >, <=, >=, +, -, *
    \
    This does floating point division.
    sqrt
    Square roots the number returning a floating point answer.
    @eval sqrt 54.4
    cos, sin, tan, acos, asin, atan
    these are standard trig functions that return their answers in radians.
    @eval cos 34.2
    midstring
    Returns the a section of the given string. The first two arguments specify which part of the string.
    @eval midstring 4 7 "This is my sentence"
    Will return: s is
    length
    Returns the length of a string.
    @eval length "Another sentence"
    nchar
    Returns the nth character in the string.
    @eval nchar 5 feruyer
    would give: y
    nitem
    Returns the nth item in a list. It is given an integer, the seperator and the string:
    @eval nitem 2 ; window;win;wundow
    would return: win
    numitems
    Same as previous item but takes no integer argument and mearly returns the number of items in the list.
    @eval numitems " " "This has spaces"
    int
    Turn argument into an integer
    @eval int 5345.5
    div
    Same as division but only returns the integer part of the answer.
    @eval 34 div 13
    mod, %
    Returns the remainder part of a division
    @eval 454 mod 23
    substr
    Returns the postition of string 1 in string 2, starting at the position given by first argument (starting at 1).
    @eval substr 5 sexy "sexyKyliesexyMinogue"
    dp
    Given a number will truncate it to the required number of decimal places. First argument is the number of places needed. Second argument is the number to be done.
    @eval dp 3 543.43523423
    Returns: 543.435
    pi
    Returns the constant pi to quite a few decimal places. Needs no arguments.
    @eval pi
    ##
    Concatenates two strings together.
    @eval "this string" ## " with this"
    ~e
    Matches as if the string was an exit name.
    @eval out ~e leave;out;go
    ~g
    Matches as if the string was being got (?).
    @eval sword ~g "Blood Red Klingon Sword"
    &,^,|
    These are Bitwise AND, XOR and OR respectively.
    @eval 43 & 32
    &&, ||
    These are logical AND, and OR respectively.
    @eval 5 && 1
    !
    Logical NOT
    @eval ! 36
    ~
    Bitwise NOT
    @eval ~ 57
    namec
    Completes the name of a connected player.
    @eval namec captain
    would return:
    Captain_Vimes
    If he is connected.
    matchitem
    Checks to see if the given string is in the given list. Returns it's position in the list.
    @eval matchitem is ; two;suits;is;dead would return 3.
    If string is not present it will return 0. Matches *whole* string.
    head
    Returns the head of a list. First argument is the seperator and the second is the string.
    @eval head ; this;is;a;quickie
    would return:
    this
    tail
    Returns the tail of a list. First argument is the seperator and the second is the string.
    @eval tail ; this;is;a;quickie
    would return:
    is;a;quickie
    replace
    @eval replace 1 "Hello" "Goodbye" "Hello everybody" This would replace the first occurence of Hello with Goodbye in the final string. Replace '1' with 'all' if you want to replace all occurences.
    desclen
    Returns the total length of an objects description.
    @eval desclen "description" or possibly @eval desclen <object>
    upper
    Converts string to upper case.
    @eval upper "boom"
    lower
    Converts string to lower case.
    @eval lower "WHISPER"
    ljust
    Left justifies string. @eval ljust 10 "hello"
    rjust
    Right justifies string. @eval rjust 10 "hello"
    centre
    Centres string. @eval centre 10 "hello"
    Example:

    :square roots 456.4 and gets {@eval sqrt 456.4}


    Syntax: "ex[amine] <object>"

    Displays all available information about "<object>".
    "<Object>" can be specified as "<name>" or "#<number>", or as "me" or "here".
    You must control the object to examine it. You can examine objects in other rooms using "#<number>".


    Syntax: "@fail <object> [ = <message> ]"
    Return value: OK or Error.

    Sets the fail message for "<object>>". The message is seen by the player when he/she fails to use "<object>". Without a message argument, it clears the message.

    Syntax:
    "@find name =<string>"
    "@find desc[ription] =<string>"
    "@find cname=<string>"
    "@find cdesc[ription]=<string>"
    "@find ename=<string>"
    "@find edesc[ription]=<string>"
    "@find edest[ination]=<string>"
    "@find vname=<string>"
    "@find vdesc[ription]=<string>"
    "@find alarm" "@find <type>=<string>"
    Prints the name and object ID of every object you control that has the specified in the "<string>" field.

    The first and second forms are identical in function; they look through all objects hunting for the string as part of the name. The third looks for the string in the descriptions of all objects (and is VERY SLOW!). The two c forms look for the string in COMMAND names and descriptions ONLY.
    The last form looks through all the names of the given type that contain the specified string. @find is case-sensitive.


    Syntax: "@force <player> = <command>"

    Forces the game to act as though "<player>" had entered "<command>". This can be done by Captains on all players and by players on their puppets. If entered from the command line puts up the word 'Forced'


    Syntax: "@from <location ID>"

    When "<location>" is your own property, returns all the exits which go there, with numbers if you own them. Default is 'here'.


    Syntax: "@if <command>"
    Enables decision making with in commands. Use as follows:
    ...
    @if Command
    Command1 if Command returns OK
    Command2 if Command returns OK
    etc etc
    @else
    Command1 if Command returns Error
    Command2 if Command returns Error
    etc etc
    @end
    ...

    Command is just a normal MBA4 command. All commands return OK or Error and @if treats this in the same way that the (c/o)succ and (c/o)fail fields on a soft command are triggered. @if will often be used with the @test and @eval commands e.g.

    @if @test {@eval "{@?name me}" = "Gushie"}
    @echo Hello Gushie
    @else
    @if @test {@?set me = RESIDENT}
    @echo Hello Resident
    @else
    @echo Hello Newbie!
    @end
    @end


    Syntax: "@key <Container> = <Key>"
    Return value: OK or Error.

    This allows an object which is a container, ie both "OPEN" and "OPENABLE" to be "LOCK"ed and "UNLOCK"ed using the key. If a container is "LOCK"ed it means that they cannot "OPEN" the container unless they satisfy the lock. A key may be any Boolean expression involving players, things and commands.


    Syntax:
    "@link <exit> = <room ID>"
    "@link <player> = <room ID>" (not technician only)
    "@link <thing> = <room or thing ID>"
    "@link <room> = <room>"
    In its first form, can be used to set the destination of the exit specified by "<exit>" to the room specified by "<room ID>". The exit must be unlinked, and you must own both sides of the link all the way up the area , and all the areas they are in up to a common area (i.e. an area which both of the rooms are in).

    The second and third forms set the homes of Players and Things - the location to which they go when they type home. You must be able to see the rooms ID if you want to link to it.

    The last form sets the `dropto' on a room. The location to which dropped objects go.

    The words HERE, ME and HOME can be used to indicate, the current location, yourself and your home room respectively.


    Syntax: "@list <player|all> = <type>"

    Lists all objects of given type for given player. For residents it will mainly be used as "@list me = <type>.
    For Officers the ALL option lists all items of type. Use with caution!

    Types are THINGS, ROOMS, EXITS, COMMANDS, FUSES, ALARMS, PUPPETS, ALL The default is <type> = COMMAND.


    Syntax: "@lock <object> = <key>"

    Locks the "<object>" so that "<key>" must be satisfied before the object can be used successfully. "<object>" can be specified as "<name>" or "#<number>", or as "ME" or "HERE". Boolean expressions are allowed, using "&" (and), "|" (or), "!" (not), and parentheses "(" and ")" for grouping.
    To lock to a player, prefix their name with "*" (eg. "*Gushie"). You can lock to the result of a command as shown below. You may also lock to a flag using the @ sign.

    If a lock succeeds then the "@success" and "@osuccess" messages come into play and if the lock fails the "@fail" and "@ofail" messages are displayed. See the failure and success section.

    Examples:
    @lock here=me
    @lock desk=small key
    @lock no robots exit=!kryten
    @lock command result=ACommand
    @lock female toilets=@FEMALE
    @lock xor thing=(thing1 & !thing2) | (!thing1 & thing2)


    Syntax: "@mass <player|room|thing> = <value>"

    Sets the mass of a Player, Room or Thing (which you must control) to "<value>". For Things, you must also be in a location that you control. You can only set your own mass once.


    Syntax: "@name <object> = <new name>"

    Changes the name of given object


    Syntax: "@odrop <object> [ = <Message> ]"
    Return value: OK or Error.

    This command sets a message, prefixed by the player's name, to be seen by the other players in a room when the player drops "<object>". Without a message it clears the argument.


    Syntax: "@oecho <string>"

    Echoes "<string>" to all players in the room where the command was invoked. It is not prefixed with the name of the invoker. Used instead of osuccess, ofail if and only if you need variable substitution. Can only be used on your own locations.


    Syntax: "@oemote <string>"

    Emotes "<string>" to all players in the room where the command was invoked. It is prefixed with the name of the invoker. Used instead of osuccess, ofail if and only if you need variable substitution. Can be used anywhere.


    Syntax: "@ofail <object> [ = <message> ]"
    Return value: OK or Error.

    The "@ofail" message, prefixed by the player's name, is shown to others when the player fails to use "<object>". Without a message argument, it clears the message. To see when the ofail message is triggered see failure.


    Syntax: "@open <exit> [;<exit>] [=<dest-ID>]"
    Return value: The ID of the exit.

    Creates an exit in the specified direction(s). If "<dest-ID>" is specified, attempts an "@link" command to that ID. Otherwise, it is created unlinked. Opening an exit costs 2 credits. If you specify "<dest-ID>", linking costs 1 more credit.

    If an exit is left unlinked then may use the "@link" command to specify the location to which the exit is to be linked. The name of an exit can be changed, once created, using "@name".

    The name should consist of everything that a person can type to get through the exit, such as "North;N"


    Syntax: "@osucc[ess] <object>|<exit> [ = <message> ]"

    The "@osuccess" message, prefixed by the name of the player performing the appropriate action, is shown to others in the same room when the player successfully uses "<object>". Without a message argument, it clears the "@osuccess" message.


    Syntax:
    "@own[er] <object> = <player>"
    "@own[er] <object>"
    "@own[er] <player> = <player>"
    This changes the ownership of objects. The first form changes the ownership of a single object to the specified player, and can only be executed by Officers. The second and third forms may be used by anybody. The second form changes the ownership of the given object to you; to do this, the CHOWNOK flag must be set on the object (see "@set" section ). The third form changes the ownership of to the second player. Only Officers may change objects of players other than themselves, and the receiving player must have his/her own CHOWN_OK flag set.


    Syntax: "@recursionlimit <number>"

    This enables players to set the recursionlimit of a command, to less than the global recursionlimit (Normally 100) so that you can stop your recursive commands going out of control. Officers can increase the recursionlimit to above 100. (Use caution, recursive commands can seriously slow down the game, and the Admirals will not be too pleased...)


    Syntax: "@repeat"

    Use in conjunction with @until as follows

    ...
    @repeat
    Command1
    Command2
    etc etc
    @until <Command>
    ...

    The commands between the @repeat and @until commands are repeated until <Command> returns OK. See @if for more information.
    The commands in the loop are always performed at least once. To stop this use the @if command. e.g.

    @if
    @else
    @repeat
    Commands to repeat
    @until
    @end

    Example:

    @drop {@?myself} = 1
    @repeat
    @echo {@?odrop {@?myself}}
    @drop {@?myself} = @eval "{@?odrop {@?myself}}" + "1"
    @until @test {@eval "{@?odrop {@?myself}}" = "4"}
    would return...
    1
    2
    3


    Syntax: "@remote <location> = <command>"

    Invisibly teleports you to "<location>" (which must be a Room or Thing that you control), causes you to execute "<command>", and invisibly teleports you back. Useful for communicators, secret doors or anything where remote activation would help. None of the usual teleport effects occur.


    Syntax: "@set <object> = [!]<flag>"
    Return value: OK or Error.

    Sets (with no "!") or resets (with "!") the given "<flag>" on the "<object>".

    There is a list of flags on MBA4, to get it type 'help @set'

    Here is a list of flags.

    ABODE
    (ROOMS) Enables anyone to link to room.
    ASHCAN
    (ALL, EXCEPT PLAYERS) Causes object to be destroyed next time an officer types @gc. For rooms, destroys all exits it contains.
    BLOCKFRIENDS
    (PLAYERS) Set if a player is blocking friend tells.
    CHOWN_OK
    (ALL) Enables other players to own object. See @owner.
    COLOUR
    (ALL) On players enables colour codes to be sent to terminal. On exits/things, enables fail/succ messages contain colour. (See pronoun section)
    CONNECTED
    (PLAYERS) Not settable by player. Flag set when player is connected.
    CONVERSE
    (PLAYERS) Shows if a player is in converse mode.
    DARK
    (ALL) Officers: On when they are off_duty.
    Non-Officers: n/a
    Rooms: Contents of room not displayed.
    Variables: Officer owned variables cannot be seen by players.
    Things/Exits: Not seen when room looked at.
    Commands: Only other commands can execute it (cfail/csucc)/
    EARMUFFS
    (PLAYERS) Player does not receive shouts.
    EDITOR
    (PLAYERS) Set when player is in the editor.
    F_ABORT
    (FUSES) Set on abort fuses.
    FEMALE
    (PLAYERS) Set on female players.
    FIXED
    (ALL) Stops the item being dropped or picked up.
    GOHOME
    (PLAYERS) Player will go home when they connect. If not set they will go to the port.
    GUIDE
    (PLAYERS) Admiral only: Player is a guide.
    HAVEN
    (PLAYERS/ROOMS) Player: (Blocktells) - player doesn't receive tells, pages, shouts, friend tells. Guides+ don't see channels.
    Room: Stops shouts getting in rooms.
    INVITES
    (ROOMS) Only people on your invite list can enter the room.
    LINK_OK
    (ROOMS/THINGS) ?
    LISTEN
    (PLAYERS) When set people can see other players connect/disconnect.
    LOCKED
    (ROOMS) Only players on your key list can enter the room.
    MALE
    (PLAYERS) Set on male players.
    NEUTER
    (PLAYERS) Set on players who are unsure about their sex..
    NEWS
    (PLAYERS) Set on players currently in the News Computer
    NOTIMEOUT
    (PLAYERS) Admiral only: Player doesn't get timed out.
    NUMBER
    (PLAYERS) Don't see #-ID when looking at your objects.
    OFFICER
    (ALL) Player: (Admiral only) Gives player extra privileges.
    Command: (Officer only) Stops command showing in hack log when executed by resident.
    Other: (Officer only) Stops object being @destroyed.
    OPAQUE
    (EXITS) When set, players cannot see where exit leads. (i.e. door is solid)
    OPEN
    (THINGS) Lets thing contain other objects (If volume is large enough)
    OPENABLE
    (THINGS) Enables open, close, lock, unlock, enter, leave commands to work on thing.
    PUBLIC
    (PLAYERS) Set if players email is set public.
    RESIDENT
    (PLAYERS) Player will not be destroyed on logout.
    SEEECHO
    (PLAYERS) Player can see who echoed.
    STICKY
    (THINGS/ROOMS/FUSES) Things: Object returns 'home' when dropped.
    Rooms: Object goes to room's 'home' when dropped in room.
    Fuses: csucc/cfail executed after command that triggered fuse.
    TECHNICIAN
    (PLAYERS) Admiral/Head_Tech only. Enables player to add to database.
    TOM
    (FUSES) Short for Trigger On Movement. On rooms, triggers fuse when someone enters room/leaves room (I think). On exits, triggers when someone passes through exit. On players triggers everytime player moves.
    TRACING
    (PLAYERS) When set, shows how MBA4 processes @command's. Useful for debugging.
    VISIBLE
    (ALL)Enables other players to examine your objects.
    WIBBLE
    (PLAYERS) Stops player from talking/telling/shouting. Prints a wibbly message if they try to talk.
    I think I have got a complete list. If you know of any that are missing, please let me know. ~Gushie.
    Syntax: "@stats [<player>]"

    For residents, this states how many objects the Universe contains, and a breakdown of the number of each type that the resident owns. For Officers, this gets stats for the whole database (if no "<player>" is given) or for "<player>" if one is given.


    Syntax: "@succ[ess] <object> [ = <message> ]"

    Sets the success message for "<object>". "<Object>" can be a thing, player, exit or room, specified as "<name>" or "#<number>" or `"me"' or "here". The message is displayed when a player successfully uses "<object>".

    Without a message argument, it clears the message. To see more about success see section .


    Syntax:
    "@tele[port] [ <object1> = ] <object2>"
    "@location [ <object1> = ] <object2>"
    Teleports "<object1>" to "<object2>". You must control the destination, and either control "<object1>" or its current location. If the target room has a drop-to, "<object1>" will go to the drop-to room instead (If it is a thing). You can also teleport to a player by specifying "<object2>" as "*<player-name>", but you must control their current location, which can be a thing.

    If "<object1> =" is omitted, the default is `"me"'.


    Syntax: "@test <value>"

    "@test" fails and returns "Error" when "<value>" is "0". Any other value will cause it to succeed and return "OK". This is usually used for compare-and-test operations in compound commands. Used because some "@?" commands return three values so that they are not always success or fail.


    Syntax: "@true"
    Useful only in commands. Tells the command to succeed, i.e. go to the csuccess at the end of the command and output the success/osuccess messages.


    Syntax: "@unchpid"

    Used inside commands, to return a players Id to normal after a "@chpid"; due to this, it is not necessary to use "@unchpid" to `close off' a "@chpid" at the end of a command. If there are multiple "@chpid"s then one level is removed from the stack of effective-player-IDs.


    Syntax: "@unevaluate <value>"

    Removes $ and {} from expressions. Syntax: "@unlink <exit|room>"
    Return value: OK or Error.

    Removes the link on the exit in the specified direction, or removes the drop-to on the room. Unlinked exits may be picked up and dropped elsewhere. Be careful, anyone can relink an unlinked exit(?), becoming its new owner however you will be reimbursed your 1 credit!

    Remember you can use words such as "HERE" for the current location can be used. You cannot unlink a player or an object, you can only link them to somewhere else, as they must have a home.


    Syntax: "@unlock <object>"

    Removes the lock on "<object>", so that any attempted use succeeds, you must own the object to remove a lock!


    Syntax: "@until <command>"

    See @repeat.


    Syntax: "@var[iable] <name> [=<initial value>]"

    Creates a variable with that name, owned by the currect player, and attached to the current player. The variable's name is "<variable-name>". If an initial value is specified, that is placed in the description.

    To vary the value of the variable use "@desc <variable-name> = <value>". "<value>" may be any text string. Or you can use edit. Variables can be attached to other objects using "get", "drop" and "@teleport".
    They can be destroyed using "@destroy".

    "$<name>" textually substitutes the description of <name> at that point.

    The other fields on a variable are unused and free to be used by you (success, osuccess, fail, ofail, drop, odrop). See also @volume <player|room|thing> = <value>"

    Sets the volume of a Player, Room or Thing (which you must control) to "<value>" which is in litres. For Things, you must also be in a location that you control. You may only set your own volume once.


    3 Queries

    Syntax: "@?address <object>/<location>"

    Returns a string that holds a list of the address of the room specified, i.e. a list of the areas which the item is in. Default is "here". Can only be used on rooms.


    Syntax: "@?age <player>"

    Returns the players age.


    Syntax: "@?area <object>=<location>"

    Succeeds if "<object>" is in "<location>". Fails if it can't find "<object>", "<location>" or if "<object>" is not in "<location>".


    Syntax: "@?birthday <player>"

    Returns the players birthday.


    Syntax: "@?bps <object>"

    Returns the number of credits the object has. (bps stands for building points, and @?bps may one day (don't hold your breath) be replaced by @?credits.


    Syntax: "@?csucc <command>"

    Returns the cfail arm of a command (as set by @cfail).


    Syntax: "@?commands <thing>"

    Returns the first object on "<thing>"'s commands list. Returns "NOTHING" if there are no objects on the list. Fails if it can't find "<thing>".


    Syntax: "@?connected [<player>]"

    Succeeds if "<player>" is logged in. Fails if "<player>" is not logged in, or if it can't find "<player>".


    Syntax: "@?contents <thing>"

    Returns the first object on "<thing>"'s contents list. Returns "NOTHING" if there are no objects on the list. Fails if it can't find "<thing>".


    Syntax: "@?controller [<player>]"

    The default "<player>" is "me". Returns "<player>"'s controller. Fails if it can't find "<player>".


    Syntax: "@?cprompt <player>"

    Returns the converse mode prompt of player.


    Syntax: "@?cstring <thing>"

    Returns the contents string of an object (as set with @cstring).


    Syntax: "@?csucc <command>"

    Returns the csuccess arm of a command (as set by @csucc).


    Syntax: "@?desc[ription] <object>"

    Returns the description string for "<object>". Fails if it can't find "<object>".


    Syntax: "@?dest[ination] <object>"

    This returns the destination of the "<object>". If it is an exit then the destination is where you will end up if you go through it. If it is a player or a thing then it returns their home location. If it is a room then it returns the dropto of it.


    Syntax: "@?drop <object>"

    Returns the drop message for "<object>". Fails if it can't find "<object>".


    Syntax: "@?elements <array>"

    Returns 1 if "<array>" (Or Dictionary) contains any elements, NOTHING if it doesn't and Error is "<array> isn't an array or dictionary.


    Syntax: "@?exist <object>"

    "<Object>" can be a name ("Fred's book"), a variable name ("the-thing:a-variable") or an ID ("#12345"). It can also be an array or dictionary element, e.g. @?exist dict_name[element]
    Succeeds if "<object>" exists. Fails if it can't find "<object>".


    Syntax: "@?exits <object>"

    Returns the first object on "<objects>"'s exit list. Returns "NOTHING" if there are no exits on the list. Fails if it can't find "<object>".


    Syntax: "@?fail <object>"

    Returns the fail string for "<object>". Fails if it can't find "<object>".


    Syntax: "@?firstname <object>"

    Returns the first name of "<object>" when it has multiple ones, seperated by ;'s.


    Syntax: "@?fuses <object>"

    Returns the name or ID of the first fuse in "<object>"'s fuse list. Returns "NOTHING" if "<object>" has no fuses. Fails if it can't find "<object>".


    Syntax: "@?id [<item>]"

    The default "<item>" is `"me"'. Returns "<item>"'s id number if you control it. Fails if it can't find "<item>".


    Syntax: "@?idletime [<player>]"

    Returns the number of seconds that <player> has been idle Fails if it can't find the player.


    Syntax: "@?interval [<number of seconds>]"

    This will return the time in proper format (days, hours, mins etc..) that the number of seconds you have given represents.


    Syntax: "@?key [<object>]"

    Returns the key for the main lock for the specified object.


    Syntax: "@?location <object>"

    Returns the name or ID of "<object>"'s current location. For an exit, this is the `start' end of the exit. You need to own either the object or the location for this to work. Fails if it can't find "<object>".


    Syntax: "@?lock <object>"

    Returns the names or IDs of "<object>"'s lock.
    Example:
    @echo {@?lock Phaser Rifle}
    SecurityChief&#4425
    Fails if it can't find "<object>".


    Syntax: "@?mass <object>"

    Returns the mass of "<object>", in kilograms. Fails if it can't find "<object>".


    Syntax: "@?myself <object>"

    Returns the name or ID of the currently executing compound command. Fails if it's not called from within a compound command.


    Syntax: "@?name <object>"

    Returns the full name of "<object>". Fails if it can't find "<object>".


    Syntax: "@?next <object>"

    Returns the ID or name of the next object after "<object>" in whatever list "<object>" is in. This can be used to traverse lists when used in conjunction with @?contents, @?variable, @?fuses, etc.
    Can also be used to find the next element in a dictionary, e.g. @?next dict_name[element1] will return "element2" if that were the index of the next element.
    Returns "NOTHING" on end-of-list Fails if it can't find "<object>".


    Syntax: "@?odrop <object>"

    Returns the odrop string for "<object>" if the object exists and you control it. Fails, otherwise.


    Syntax: "@?ofail <object>"

    Returns the ofail string for "<object>" if the object exists and you control it. Fails otherwise.


    Syntax: "@?osuccess <object>"

    Returns the osuccess string for "<object>" if the object exists and you control it. Fails, otherwise.


    Syntax: "@?owner <object>"

    Returns the owner of any object in the game. Useful when you can't examine an object, but want to know who created it so you can do something even nastier to them.


    Syntax: "@?pending"

    See the items in the pending queue (e.g. alarms and fuses etc)


    Syntax: "@?pennies <object>"

    [See @?bps.]


    Syntax: "@?prefix <player>"

    Returns the players prefix.


    Syntax: "@?prompt <player>"

    Returns the players prompt.

    Syntax: "@?race [<player>]"

    Returns the string for "<player>" that set with "@race". Fails if it can't find "<player>".


    Syntax: "@?rand <number>"

    Returns a random number in the range 0 to "<number>-1".


    Syntax: "@?realtime [<saved time>]"

    Converts "<saved time>" to the form: "Fri Jun 28 11:39:13 2104" and returns it. If no "<saved time>" is given, the current system time is used.


    Syntax: "@?score [<player>]"

    The default "<player>" is "me". Returns "<player>"'s score. Fails if it can't find "<player>".
    (This is pretty pointless on MBA4 since we don't have scores!)


    Syntax: "@?set <object>=<flag>"

    Succeeds if "<flag>" is set for "<object>". Fails if "<flag>" is not set, or if it can't find "<object>". Use "@?exist" to disambiguate these two cases if you need to. See @set for a list of flags.


    Syntax: "@?size<array>"

    Returns the number of elements in <array> (Which could be a dictionary).

    Succeeds if "<flag>" is set for "<object>". Fails if "<flag>" is not set, or if it can't find "<object>". Use "@?exist" to disambiguate these two cases if you need to. See @set for a list of flags.


    Syntax: "@?success <object>"

    Returns the success string for "<object>" if the object exists and you control it. Note that this will be empty if nobody has ever set one. Fails otherwise.


    Syntax: "@?time"

    Returns the time in seconds since epoch (00:00:00 Jan 1 1970). Useful if you want to store a time for later computation.


    Syntax:
    "@?typeof <object>"
    "@?typeof <object> = <type>"
    The first form returns one of "Alarm", "Command", "Exit", "Fuse", "Player" etc., depending on the type of "<object>". The second form succeeds if "<object>" has type "<type>" (specified using the strings given above). Both forms fail if they can't find "<object>".


    Syntax: "@?variables <object>"

    Returns the name or ID of the first variable attached to "<object>". Returns the string "NOTHING" if there are no variables attached to the object. Fails if it can't find "<object>".


    Syntax: "@?volume <Thing|Player|Room>"

    Returns the volume of its argument. Containers have the same internal and external volume, because the coder's are lazy :-)


    Syntax: "@?who <person>"

    Returns the who string of the person. Fails if it can't find them.


    4 Making your own commands

    4.1 Simple commands

    If you want a command that is only needing in one room, and just displays text that isn't dependant on anything else except possibly the person who executed it, then you can use the following. Create an Exit in the room you want the command to be in, and link it to the same room. Set the Exit dark then lock the Exit to 'me&!me' i.e. it always fails because there is no object in MBA4 that is both 'you' and 'not you' at the same time. Then all you need to is set the fail and ofail accordingly. For example.
    @open sit = here
    @set sit = dark
    @lock sit = me&!me
    @fail sit = You sit in the comfortable chair.
    @ofail sit = sits in the comfortable chair.

    Now if Fred types 'sit', he will get the message: You sit in the comfortable chair,
    while everyone else in the same room sees: Fred sits in the comfortable chair.

    This has an advantage over commands in that they only cost 2 credits, while commands cost 10.


    4.2 Success and Failure

  • - You fail to use a thing when you cannot take it (because it's lock fails).
  • - You fail to use an exit when you cannot go through it (because it's unlinked or locked).
  • - You fail to use a room when you fail to look around (because it's locked). Although you still see the room's description, which gets displayed regardless of success or failure.
  • - When the last simple command in a Command returns failure.
  • - Success is of course the opposite.

  • 4.3 Changing Player ID

    See @chpid and @unchpid.

    4.4 Automatically executed commands

    .login
    This is a command that will be executed whenever you logon to the game, it must be on you, in an object you are carrying, or in the room that you are in. This is the only special thing about it, otherwise it executes the sames as any other command.
    .logout
    This is similar to .login except it executes on QUIT from the game.
    .enter
    This command is executed when ever a person enters a room or area.
    .leave
    This command is executed when a person leaves an area.

    4.5 Variable referencing

    Variable References
    -------------------
    "drop <Variable> = <Object>" will attach a variable to an object. To attach it to a room type "drop <Variable>". To get a variable back you must specify its full name, ie "get the-thing:fred".

    You can construct variable names out of expressions involving other variable names by surrounding the constructed name with braces (`{' and `}'). Braces can also be used when a colon just after a reference would otherwise screw things up. NB - Anything within {...}'s is executed as a command, therefore use "{@?desc <var>}", rather than "$<var>"


    4.6 Command parameters

    All of the parameters will stay the same through csuccess and cfail links except for $0 which changes whenever you execute a command. If you call a command by name then the parameters are all reset to new values.

    Return Parameter $0:

    This is set to the return value from the last command executed. It can be used in the next command.

    Example:

    @command openlink=@dig \$2\
    @open \$1 = \$0

    : openlink North;n = My new room wot I dug with openlink

    First input parameter $1:

    This is set to the first argument to a command. It is not set outside a command. The first argument is the bit between the command name and the first `=' sign.

    Example:

    @command yell=:yells "\$1!"

    yell hello
    Gushie yells "hello"

    Second input parameter $2:

    This is set to the second argument to a command. It is not set outside a command. The second argument is the bit after the first `=' sign, up to the end of the string.

    Example:

    @command ask=:asks \$1 the question "\$2"

    ask fred=How are you?

    Gushie asks fred the question "How are you?"

    Combined Input Parameter $3:

    This is the first and second input parameters all rolled into one (with an equals between them). It is useful for the lazy people of this world ie me! it allows the passing of the whole command line at the same time, to make short forms of commands.

    Example:

    @command wh=whisper \$3

    wh fred=Hi there.


    4.7 Using Queries

    Since queries don't return text just values you can't type them in at the command line. To make them work you need to enclose the query in curly brackets. So if for example you wanted to see your name you would type @echo {@?name me}. The same is true for the @eval function.
    Within commands if you only want them to be worked out when the command is executed, put a backslash in front of the first curly bracket.
    e.g. @command myname = @echo \{@?name me}
    Otherwise it would try to work out the query straight away and sticking the result in the command. \'s don't need to be used in the editor.

    4.8 Embedded Newlines

    It is possible to embed NEWLINEs in descriptions when using @desc. To do this, prefix the NEWLINE with a backslash. A backslash can still be generated by prefixing it with two other backslashes. eg.:

    @describe object=Here is a backslash:\\And here is a...\
    new line.
    Here is a backslash:\ And here is a..."
    new line."


    4.9 Drop-To's

    When the "@link" command is used on a room, it sets a dropto location for that room. Any object dropped in the room will go to that location. If the room is set to be STICKY, the effect of the dropto will be delayed until the last player leaves the room. The special location `HOME' may be used as a dropto, as in "@link here = HOME"; in that case objects dropped in the room will go to their homes. "@link = #" "@unlink "

    5 Alarms and Fuses

    An alarm is set on a command to make that command execute automatically at a certain time(s) during the week, or an amount of time into the future, relative to the time when the alarm is set.

    Syntax: "@alarm <alarm-name>= s m h d" (Officer only)
    "@alarm <alarm-name>= + s m h d" (Officer only)

    The first form sets an alarm to go off at the same time each week, days are numbered from 1 to 7, Monday is day 1. If you enter a `*' in any field then the alarm will execute for any value of that field. ie `0 0 9 *' is the alarm for opening the bank.

    The second form causes the alarm to execute only once, the amount of time that you specify into the future.ie `+ 0 0 1 0' causes the alarm to execute one hour into the future.

    To get the alarm to actually do something you have to set a csuccess on it to the command that you want to execute when the alarm goes off.

    Once an alarm has been created its value can be reset using "@desc".

    To turn an alarm off just describe it to null.

    This command is Officer-only due to the amount of processor time that alarms use.


    Syntax: "@fuse <name>"

    Creates a fuse called "<name>". The name is useless for all practical purposes; it just serves to identify the fuse. Whenever a fuse is triggered, its value (stored in its description) counts down by 1. If the value is non-zero, it executes any command linked to its cfail. If the value is 0, the value is re-loaded from the fuse's `drop' field and any command attached to its csuccess is executed.

    Fuses trigger when attached to different objects. Attaching one to a player will cause it to trigger each time the player types a command; to an exit, each time the exit is used; to a thing, each time the thing is picked up or dropped; and to a room, each time player types a command in that room.

    After creating a fuse, you set its description equal to the value t at you want the counter to start at.
    You then also set an "@drop" on it, ie:- "@drop <fuse-name>=<value>"

    This is the value that will go back into the fuse after it has gone BANG. Then all you have to do is set a "@csuccess" on the fuse for the command which should be executed when the fuse goes BANG, ie the counter reaches 0, and a "@cfail" for each time the fuse is activated, but doesn't go BANG, ie it just `ticks'.

    @fuse my-silly-fuse
    @describe my-silly-fuse = 20
    @drop my-silly-fuse = 10
    @csucc my-silly-fuse = {@command fsucc = !:wibbles loudly}
    @cfail my-silly-fuse = {@command fsucc = !:wibbles quietly}


    6 Pronouns

    In the previous example, you may have noticed that the fail message on the window sounds rather artificial:

    Grog bangs their nose on the window while trying to get out.
    'their' isn't the right possessive pronoun to use here --- Grog's male, so it should be 'his'. But you can't just put the male version in --- what if someone female tries this? The result would look even odder.

    Fortunately, there's a solution to this rather knotty problem. Since all MBA4 characters have a gender (male, female, neuter or 'I haven't set it yet'), all that's needed is something that converts to the correct pronoun when it's put into a message. In MBA4, these strings are all two-character, all start with a % sign and are known as pronoun-substitution strings.

    To use one of these strings, you need to know a bit of grammar. The strings are shown down the left-hand side of the following table; the resulting text for different genders is shown along the rest of the table.

    StringPronounMaleFemaleNeuter
    %sSubjecthesheit
    %SSubjectHeSheIt
    %oObjecthimherit
    %OObjectHimHerIt
    %pPossessivehisherits
    %PPossessiveHisHerIts
    So, to set up the window correctly:

    @ofail window=bangs %p nose on the window while trying to get out.
    When Grog tries to go through the window now, other players will see:

    Grog bangs his nose on the window while trying to get out.
    Things can get silly if you use many pronoun-substitution strings in the same message:

    @ofail window=bangs %p nose on the window. %S curses %oself as a fool.
    which gives one of the following (depending on the sex of the player who tries it):

    Grog bangs his nose on the window. He curses himself as a fool.
    Dawn bangs her nose on the window. She curses herself as a fool.
    DreamDragon bangs its nose on the window. It curses itself as a fool.

    Colours

    You add Colour to your descriptions/succs/fails etc by using the following codes.

    STRING EFFECT
    %hHilite text.
    %lNewline.
    %tTab.
    %NReturn to normal. (Uppercase)
    %f#Foreground colour (I.e. text) where # is a number.
    %b#Background colour.
    %uUnderline.
    %rReverse. (Swap foreground and background colours.)
    %%Displays a %.
    Where # is replaced by
    01234567
    Black Red Green Yellow Blue Magenta Cyan White
    Hilite and %f/%b maybe mixed for a larger range of colours.

    Back to the beginning.
    MBA4's Home Page

    Jonathan Corwin (Gushie). ©1995,96,97 MBA4.