The Sapphire Room Format ------------------------ Creating room specifications usable by the Sapphire MUD server consists of creating a ASCII text file (any standard text editor will do,) and definning the room's values using a special syntax. A room's values are defined using the format, <keyword> <value(s)> ; with two exceptions. First is the room number, which is defined with #<number> and must be the first string in the text file. Second is the `end' keyword which needs no values because it simply tells the Sapphire DB loader that no more values are to be defined for this room. Other then the room number and the `end' keyword, every keyword-value(s) should end with a semi-colon (`;'). This is mostly so the Sapphire DB loader can find errors more easily. Each room specification needs to be in it's own file, putting multiple room specifications in one file will not stop the server from starting, but all data after the `end' keyword of the first room specification will be discarded. Normal keywords may be used in any order you like. For example, title "Generic Room"; desc "This is a room description.\n\r" [format]; is no different then desc "This is a room description.\n\r" [format]; title "Generic Room"; to the Sapphire DB loader. If you do not define a value it assumes a default value. This is useful for saving time, and disk space, if there are values which simply do not need to be defined for a room. Keywords and any values that are not in qoutes (`"') are case-insensitive. You may also have comments in room specification files. For a comment put an asterisk (`*') to start the comment. The comment will terminate when the end of the line is reached. You may not place comments before the room number. Following is an example of an actual room specification file for you to study. #1000 * Tatt's room; written by Tatt :) title "Tatt's room"; desc "You are in a small, warm room. Many old books are\n\r stacked in every corner and on every flat surface. There\n\r is a dim light that fills the room, although you fail\n\r to see its source.\n\r" [format]; north_desc "You see the void." [format]; northeast_desc "You see another room created by Tatt." [format]; room_flags [inside, immortal]; north 1001 standard; northeast 1002 door "door" [closed, locked, key 1000]; npcs [1000[][]1200, 1001[][]1200]; objects [50[]1200]; end; Currently Defined Fields Syntax: image "<filename>" ; The image file for the "picture" of this room. Currently supported formats are JPEG (.jpg/.jpeg) and GIF (.gif). Syntax: title "<string>" ; Room title, appears above the room description when a player looks. Hints: Should not be longer then about 5 words and should not have a period (`.') at the end as it is not a sentence. Syntax: desc "<string>" [<"format"|" ">] ; Room description, seen when a player looks. If the square brakets after the string contain the word `format' then the string will be automaticly formated to fit all terminal screens. If the square brakets are left empty the defined format will be used. Hints: You should try not to describe anything thats changes, because the description will not change to go with it. For example, you should generally not describe positions of doors, or NPCs. Syntax: room_flags [<flags>] ; It is good form to put a comma (`,') between each flag, although it is not required. Currently implmented flags: inside - Room is inside. outside - Room is outside. dark - This room will be dark. invis - All characters and objects in this room will be invisible. nonpcs - NPCs are not allowed in this room. private - No more then two characters may be in this room. immortal - Only immortals may enter this room. unsafe - Players may kill each other in this room. weather - Weather will affect this room. Syntax sector <sector type> ; Currently implmented sector types: void city water Syntax: temperature <number> ; Normal room temperature, allowed range is +1000 to -1000. Syntax: northdesc "<string>" [<"format"|" ">] ; Syntax: southdesc "<string>" [<"format"|" ">] ; Syntax: eastdesc "<string>" [<"format"|" ">] ; Syntax: westdesc "<string>" [<"format"|" ">] ; Syntax: updesc "<string>" [<"format"|" ">] ; Syntax: downdesc "<string>" [<"format"|" ">] ; Syntax: northeastdesc "<string>" [<"format"|" ">] ; Syntax: southwestdesc "<string>" [<"format"|" ">] ; Syntax: northwestdesc "<string>" [<"format"|" ">] ; Syntax: southeastdesc "<string>" [<"format"|" ">] ; Direction description, seen when a player looks in the given direction. If the square brakets after the string contain the word `format' then the string will be automaticly formated to fit all terminal screens. If the square brakets are left empty the defined format will be used. Hints: You should try not to describe anything thats changes, because the description will not change to go with it. For example, you should generally not describe positions of doors, or NPCs. Syntax: north <number> <exit type> ... ; Syntax: south <number> <exit type> ... ; Syntax: east <number> <exit type> ... ; Syntax: west <number> <exit type> ... ; Syntax: up <number> <exit type> ... ; Syntax: down <number> <exit type> ... ; Syntax: northeast <number> <exit type> ... ; Syntax: southwest <number> <exit type> ... ; Syntax: northwest <number> <exit type> ... ; Syntax: southeast <number> <exit type> ... ; First, the number of the room to connect the exit to. Second, the exit type and any special values that go along with it. Currently implmented exit types: standard - A standard exit (no door); no extra values needed. door - An openable (if unlocked) door; extra values needed (discribed below.) shared - Uses all values from the remote side. If there is no remote side there will be an error. No extra values needed. Extra values for the door exit type: "<names>" [<flags>] The string is a list of names (seperated by spaces) used to preform operations on the door. Currently implmented door flags: closed - Default position is closed. locked - Door is, by default, locked. hidden - Hidden until found with `search'. key <number> - Object number of key for this door. Syntax: npcs [<npc list>] ; Syntax: objects [<object list>] ; Sapphire and Emerald are Copyright (C) 1996-1997 Christopher D. Granz