Which movement types automatically (as opposed to manually) activate this object. "> Which movement types deactivate this object (e.g. button). "> Determines which kinds of movement this object can use (e.g. for monsters) or grants (e.g. for amulets). "> Objects using these movement types cannot move over this space. Objects using these movement types are allowed to move over this space. Takes precedence over 'blocked movements'. The types of movement that should by slowed down by the 'slow movement penalty'. If <slow movement> is set to a value greater zero, all creatures matching 'slow move' will be slower than normal on this spot. <slow movement> 1 - rough terrain <slow movement> 2 - very rough terrain ... <slow movement> 5 - default for deep swamp ... <slow movement> 7 - spider web (sticky as hell) "> The speed left to the object. On every tick, if this value is higher than 0, the object acts/triggers/moves etc. and the value gets decremented by 1. Otherwise, it is incremented by <speed> on every tick. "> Whether the teleporter should only be activated on push. Whether the teleporter should only be activated on release. "> &resistances_flesh_desc; &resistances_flesh_desc; &resistances_flesh_desc; &resistances_flesh_desc; &resistances_flesh_desc; &resistances_flesh_desc; &resistances_flesh_desc; &resistances_flesh_desc; &resistances_flesh_desc; &resistances_flesh_desc; &resistances_flesh_desc; &resistances_flesh_desc; &resistances_flesh_desc; &resistances_flesh_desc; &resistances_flesh_desc; &resistances_flesh_desc; &resistances_flesh_desc; &resistances_flesh_desc; "> "> &player_stat_desc; &player_stat_desc; &player_stat_desc; &player_stat_desc; &player_stat_desc; &player_stat_desc; &player_stat_desc;

&player_res_desc; &player_res_desc; &player_res_desc; &player_res_desc; &player_res_desc; &player_res_desc; &player_res_desc; &player_res_desc; &player_res_desc; &player_res_desc; &player_res_desc; &player_res_desc; &player_res_desc; &player_res_desc; &player_res_desc; &player_res_desc; &player_res_desc; &player_res_desc; &player_res_desc; &player_res_desc;

"> ]> This is the name of the object, displayed to the player. This is the plural name of the object. A plural name must be set for all items that can be picked up and collected by the player. This is the object's title. Once an object is identified the title is attached to the name. Typical titles are "of Mostrai", "of xray vision" etc. The image-name defines what image is displayed for this object in-game. You can tag objects with an identifier. Tagged objects can be found quickly from their tag, which makes them useful to tag exits and refer to those by their name. This value determines the number of objects in one stack (for example: 100 goldcoins => "number = 100"). You should set this at least to one, for any pickable object - otherwise it won't be mergeable into a stack. This value defines the object's weight in grams (1000g is 1kg). Objects with zero weight are not pickable for players. Still, set the "non-pickable"-flag for explicitly non-pickable objects (hey, this is opensource.. you never know ;) ). Determines the value of the object, in units of silver coins (one platinum coin == 50 silver coins). Value for buying/selling will be further modified by various factors. Hence, testing values in-game is usually inevitable. If <glow radius> is set to a value greater zero, the object appears lit up on dark maps. <glow radius> can be a value between 0 and 4, the higher, the more light does the object emit. This bitmask-value informs the player of which material(s) the object consists. Material does also affect how likely the object can be destroyed by hazardous spell-effects. If set, the object cannot be picked up (Neither by players nor monsters). Generally makes the object invisible. Depending on the object-type, some can be made visible by the show_invisible spell. If in doubt, test it. Putting an invisible object under the floor always prevents it from being shown. If an item is set to block view, players (and monsters) cannot see byond it unless they cross it or manage to stand ontop. If an item is identified, the player has full knowledge about it. An <unpaid> item cannot be used unless a player carried it over a shop mat, paying the demanded price. Setting this flag makes sense only for pickable items inside shops. The sound this objects makes on a map. Enter either a sound alias from arch/res/sound.conf.res or a path. If you enter <path> in this field it will point to sound/<path>.ext The sound this objects makes when it is destroyed. Enter either a sound alias from arch/res/sound.conf.res or a path. If you enter <path> in this field it will point to sound/<path>.ext &movement_types_terrain; Curses can have various effects: On equipment and food, they generally harm the player in some way. A damned item/floor on the ground makes it impossible for players to use prayers on that spot. It also prevents players from saving. Damnation on equipment works similar to a curse. Unique items exist only one time on a server. If the item is taken, lost or destroyed - it's gone for good. A godgiven item vanishes as soon as the player drops it to the ground. This text may describe the object.
A particularly nice feature of abilities is that they can hold two spells: One for short range- and one for long range use. \n\n You should know that spellcasting monsters receive abilities via <treasurelist>. ]]>
You should keep in mind that magic abilities allow players to get better resistance. You can turn off the magic part to make the spells more dangerous. However, this really shouldn't be neccessary unless you work on very high level maps. And what fun is a magic resistance cloak when it has no effect? ]]> The monster will use the specified <short range spell> when the player is within 6-square radius (of the monster's head). The monster will use the specified <long range spell> when the player is at least 6 squares away (from the monster's head). Setting a <long range spell> is optional. If unset, the <short range spell> gets used all the time. Sometimes you'll want a monster to use one ability more than others. To achieve this, set the <importance> to a value greater than one. Abilities with this value zero/unset are counted to be of <importance> one. Example: A monster with "small fireball" of <importance> 3 and "paralyze" of <importance> 1 will averagely cast three out of four times the "small fireball". This flag specifies whether the ability <is magical> in nature. If enabled, all spells produced by this ability will have magic attacktype added to the usual attacktypes. This should always be set for spell-like abilities. "Natural" abilities like a dragon's firebreath are an exception. Note that non-magical abilities are more dangerous because magic resistance does not protect from those. &move_on; This string specifies the item that must be put on the altar to activate it. It can either be the name of an archetype, or directly the name of an object. Yet, titles are not recognized by altars. Remember to put a note somewhere, telling the player what he is expected to drop on the altar. (Often this is put in the altar's name: E.g. "drop 100 platinums") The drop amount specifies the amount of items (specified in <match item name>) that must be dropped to activate the altar. If <match item name> is set to "money", then the value of the sacrificed money must be equal to <drop amount> (ie, if food=200, then 200 silver, 20 gold, or 4 platinum will all work.) Note that the maximum possible for <drop amount> is 32767. If a connection value is set, the altar will trigger all objects with the same value, when activated. This will only work once. When activated, the selected <spell> will be casted (once, on the player). This should work for any given spell. The altar will work infinitely in this way. Don't set both <spell> and <connection> for one altar. This text will be displayed to the player in the exact moment when the altar is activated. connection activated), except for the fact that they reset after usage. Hence, altar_triggers can be used infinitely. ]]>

...an item. -> Connect the altar_trigger (set "last_sp 1") to a creator.

...opening a gate. -> Connect the altar_trigger (set "last_sp 0") to the gate.

...information. -> Connect the altar_trigger (set "last_sp 1") to a magic_mouth. The big advantage over normal altars is the infinite usability of altar_triggers! If there are ten players on one server, they're quite grateful if things work more than once. =) ]]> This string specifies the item that must be put on the altar to activate it. It can either be the name of an archetype, or directly the name of an object. Yet, titles are not recognized by altars. Remember to put a note somewhere, telling the player what he is expected to drop on the altar. (Often this is put in the altar's name: E.g. "drop 100 platinums") The drop amount specifies the amount of items (specified in <match item name>) that must be dropped to activate the altar. If <match item name> is set to "money", then the value of the sacrificed money must be equal to <drop amount> (ie, if food=200, then 200 silver, 20 gold, or 4 platinum will all work.) Note that the maximum possible for <drop amount> is 32767. If a connection value is set, the altar will trigger all objects with the same value, when activated. This will only work once. When activated, this <spell> will be casted (once, on the player). This should work for any given spell. The altar will work infinitely in this way. Don't set both <spell> and <connection> for one altar. Being activated, the altar will reset after <reset time> ticks. After reset, the altar is ready to be activated once again. The default <reset time> is 30. If this attribute is enabled, the altar_trigger won't push the connected value by altar reset. Only ONCE by dropping the sacrifice. This is typically used when the altar is connected to a creator, e.g. for selling tickets. If this attribute is disabled (default), the altar_trigger will push the connected value TWICE per sacrifice: First by dropping sacrifice, second by reset. This mode is typically used for altars being connected to gates, resulting in the gate being opened and closed again. &move_on; This text will be displayed to the player in the exact moment when the altar is activated. This field describes which skill the player will be able to use wearing this item. &player_stat_resist_sections; This value defines the amount of armour-class bonus for wearing this item. <Armour class> lessens the chance of being hit. Lower values are better. It should usually be set only for armour-like equipment. The <weapon class> value adds to the overall weapon class of the wielder's melee attacks. Weapon class improves the chance of hitting the opponent. Weapon class is the "counterpiece" of <armour class>. It should usually be set only for weapon-like items. Lower values are better. The <item power> value measures how "powerful" an artifact is. Players will only be able to wear equipment with a certain total amount of <item power>, depending on their own level. This is the only way to prevent low level players to wear "undeserved" equipment (like gifts from other players or cheated items). It is very important to adjust the <item power> value carefully for every artifact you create! If zero/unset, the CF server will calculate a provisional value at runtime, but this is never going to be an accurate measurement of <item power>. A damned piece of equipment cannot be unwielded unless the curse is removed. Removing damnations is a tick harder than removing curses. A cursed piece of equipment cannot be unwielded unless the curse is removed. An item with this flag enabled will save the players life for one time: When the player is wearing this item and his health points reach zero, the item disappears, replenishing half of the player's health. An item with <save life> should not have any decent additional bonuses! Unique items exist only one time on a server. If the item is taken, lost or destroyed - it's gone for good. A godgiven item vanishes as soon as the player drops it to the ground. If you put this item into the inventory of a monster, and you want the monster to use/wear the item - you must set <is applied>. Enabling this flag doesn't make any sense if the item is NOT in a monster's inventory. &player_stat_resist_sections;

With positive luck bonus, the player is more likely to succeed in all sorts of things (spellcasting, praying,...). Unless the <luck bonus> is very high, the effect will be barely visible in-game. Luck bonus on one piece of equipment should never exceed 3, and such bonus should not be too frequently available. Positive <health regen.> bonus speeds up the player's healing process. Negative values slow it down. Positive <mana regen.> bonus speeds up the player's mana regeneration. Negative values slow it down. Positive <grace regen.> bonus speeds up the player's grace regeneration. Negative values slow it down. Since grace can be regenerated rather easy with praying, additional <grace regen.> bonus should be VERY RARE!! Positive <food bonus> slows down the player's digestion, thus he consumes less food. Negative values speed it up. Note that food is consumed not only for "being alive", but also for healing and mana-regeneration. <food bonus> only affects the amount of food consumed for "being alive". Hence, even with high <food bonus>, during a fight a player can run out of food quickly. Xray vision allows the player to see through obstacles in a two-square-wide radius. This is extremely helpful and desirable, so don't give it away for cheap on equipment. Stealth allows the player to move silently. This comes to effect if a player turns himself invisible and tries to sneak around monsters. (At least that was the idea behind it) If a player is wearing any piece of equipment with the ability to <reflect spells>, all kinds of spell-bullets and -beams will bounce off him. This works only about 90% of all times, to avoid players being completely immune to certain types of attacks. This is a very powerful ability and it shouldn't be handed out cheap! If a player is wearing any piece of equipment with the ability to <reflect missiles>, all kinds of projectiles (e.g. arrows, bolts, boulders) will bounce off him. This works only about 90% of all times, to avoid players being completely immune to certain types of attacks. &move_type; Click on the <attuned paths> button to select spellpaths. The player will get attuned to the specified spellpaths while wearing this item. Click on the <repelled paths> button to select spellpaths. The player will get repelled to the specified spellpaths while wearing this item. Click on the <denied paths> button to select spellpaths. The specified spellpaths will be denied to the player while wearing this item.

This text describes the item's "story". Every decent artifact should have such a description. What should NEVER be done is placing battleground tiles in open dungeons or other free kinds of land. It must not be possible to gain significant treasure for fighting on battleground, because it bears no risk.

(Battleground will cease to work when the image or name is changed, or when it is placed beneath another floor tile. This is not a bug, it is there to prevent any attempts of placing "hidden" battleground tiles anywhere.) ]]> The exit destinations define the (x, y)-coordinates where players get teleported after they died on this battleground. The exit destinations define the (x, y)-coordinates where players get teleported after they died on this battleground. If this value is set to be greater than zero, the player needs a certain literacy level to succeed reading the book. The book can be read if: mental_level greater <literacy level> - 5. Adding level to a book can be a nice idea, personally I like it when a player needs more than his fighting skills to solve a quest. However, keep the booklevel at least below 15 because it is quite hard to gain high mental levels. A godgiven item vanishes as soon as the player drops it to the ground. Unique items exist only one time on a server. If the item is taken, lost or destroyed - it's gone for good. This is the text that appears "written" in the book. This is the key string of the book. The key string is checked by an inventory checker. (This is used eg. for the gate/port passes in scorn) Boots with <speed bonus> will increase the player's walking speed while worn. This kind of bonus is quite desirable for players of low- and medium level. High level players usually have fastest possible walking speed and thus don't need <speed bonus> anymore. Still, this bonus is good for nice artifacts - not everything has to be for highest level. <magic bonus> works just like ac, except that it can be improved by "scrolls of Enchant Armour" or reduced by acid. It is less useful than direct armour-class bonus on the boots. Important: <magic bonus> on boots has no effect if there is no <armour class> set. It only works in combination with <armour class>. <magic bonus> works just like ac, except that it can be improved by "scrolls of Enchant Armour" or reduced by acid. It is less useful than direct armour-class bonus on the bracers. This poses a penalty to spell regeneration speed, for wearing the armour. The bigger the spellpoint penalty, the worse. Slowdown penalty reduces the player's walking speed when wearing the armour. Bigger values are worse - zero is best. <magic bonus> works just like ac, except that it can be improved by "scrolls of Enchant Armour" or reduced by acid. It is less useful than direct armour-class bonus on the armour. &move_on; &move_off; The button is pressed (triggered), as soon as <press weigh> gram are placed ontop of it. Every time the button is pressed or released, all objects with the same <connection> value are activated. This text may describe the item. You can use this message to explain the button's purpose to the player. This entry determines which initial items the character receives.

The player's strength will rise by the given value if he chooses this class. (Negative values make strength fall) The player's dexterity will rise by the given value if he chooses this class. (Negative values make dexterity fall) The player's constitution will rise by the given value if he chooses this class. (Negative values make constitution fall) The player's intelligence will rise by the given value if he chooses this class. (Negative values make intelligence fall) The player's power will rise by the given value if he chooses this class. (Negative values make power fall) The player's wisdom will rise by the given value if he chooses this class. (Negative values make wisdom fall) The player's charisma will rise by the given value if he chooses this class. (Negative values make charisma fall)

<magic bonus> works just like ac, except that it can be improved by "scrolls of Enchant Armour" or reduced by acid. It is less useful than direct armour-class bonus on the cloak. Important: <magic bonus> on cloaks has no effect if there is no <armour class> set. It only works in combination with <armour class>. This text may describe the item
A special feature of containers is the "cauldron", capable of mixing alchemical receipes. ]]>

First the random treasure chests - Those are NOT containers (but object type Treasure), they create random treasures when applied. Archetype name is "chest".

Second there are the permanent chests - Those are containers, they can be opened and closed again. Archetype name is "chest_2". ]]> If set, the container will hold only certain types of objects. Possible choices for <container class> are: "gold and jewels", "arrows" and "keys". Unfortunately it is not easy to create new container classes, because items need a matching counterpiece-attribute to the <container class> before they can be put inside a container. This attribute ("race") is set only for the existing container classes. If <key string> is set, only players with a special key of matching <key string> are able to open the container. The container can hold a maximum total weight of the given value in gram. Note that this weight limit is calculated *after* the weight reduction (<reduce weight>) has been applied. This value determines how much the weight of items is reduced in percent, when put inside the container. <reduce weight %> 0 means no reduction, <reduce weight %> 100 means items are weightless inside. Most default values are in the range of ten. If set, the container can be used as alchemy-cauldron. The player can put ingredients inside, close it, cast alchemy and if his formulae is true, he'll get what he longed for. Unique items exist only one time on a server. If the item is taken, lost or destroyed - it's gone for good. All contents of a unique container are unique as well. A godgiven item vanishes as soon as the player drops it to the ground. This is used for a certain kind of... "animation" when opening the container. Stick to the default arches here and you won't get into trouble. This text may contain a description of the container.
VERY IMPORTANT: Be careful with the exchange-ratio! When you drop items on a converter, the stuff you get must be of equal or lesser value than before! (Except if you are using "rare" items like dragonscales for payment). The code will not check if your ratio is sane, so the player could gain infinite wealth by using your converter. ]]> <cost arch> is the name of the archetype the player has to put on the converter, as payment. The player has to put <cost number> items of <cost arch> on the converter, in order to get <receive number> items of <receive arch>. <receive arch> is the name of the archetype to convert into. This field is ignored if the converter has items in inventory. In this case one of the inventory items is duplicated. The duplicated item is randomly chosen from all items present. The player has to put <cost number> items of <cost arch> on the converter, in order to get <receive number> items of <receive arch>. This text may contain a description of the converter. This string defines the object that will be created. You can choose any of the existing arches. This field is ignored if the creator has items in inventory. In this case one of the inventory items is duplicated. The duplicated item is randomly chosen from all items present. Whenever the connection value is activated, the creator gets triggered. &activate_on; If <infinit uses> is set, the creator will work infinitely, regardless of the value in <number of uses>. When this field is set the creator will periodically create stuff (and will still do so when the connection is triggered). A value of 1 means roughly 8 times a second. The creator can be triggered <number of uses> times, thus creating that many objects, before it dissappears. Default is <number of uses> 1 (-> one-time usage). The created object will bear the name and title specified in <name of creation>. If nothing is set, the standard name and title of the archetype is used. The created object will be of that level. If zero/unset, the standard level of the archetype is used.
What is "unique" about them, compared to inv. checkers/ pedestals? - First, detectors check their square for a match periodically, not instantly. Second, detectors check directly for object names. Third, detectors do not check the inventory of players/monsters. ]]> <match name> specifies the name of the object we are looking for. Actually it does also check for the <key string> in key-objects, but for this case inventory checkers are often more powerful to use. When the detector is triggered, all objects with the same connection value get activated. This value defines the time between two detector-checks. If you want the detector to behave almost like pedestals/buttons, set speed rather high, like <detection speed> 1.0. &speed_left; The speed left. This value is incremented by <speed> on every tick. If it is larger than 0, the detector checks, and the speed is decremented by 1. Directors are visible per default. ]]> never place directors facing each other with magic walls fireing into them! The spell-projectiles bouncing between the directors would accumulate to huge numbers and at some point slow down the server by eating memory- and CPU-time.

You'd better not place directors in monster vs. player combat areas too much, because that freaks out wizard-type players. ]]> Projectiles will leave the director flying in the selected <direction>. A director with direction <none> simply stops projectiles. (The latter works out a bit strange for some spells). &move_on; The <plaque level> is proportional to the disease's deadliness. This mainly reflects in the <damage>. It has no effect on most other symptoms. Neverthless, it is a very important value for all damage-inflicting diseases. The disease will only infect creatures of the specified <race>. "<race> *" means every creature can be infected. Every time the disease "moves" the severity of the symptoms are increased by <progressiveness>/100. (severity = 1 + (accumlated progression)/100)

The <infectiosness> defines the chance of new creatures getting infected. If you set this too high, the disease is very likely to be too effective. <infectiosness>/127 is the chance of someone in range catching it. The <attenuation> value reduces the diseases' <infectiosness> everytime it infects someone new. This limits how many generations a disease can propagate. <infection range> sets the range at which infection may occur. If positive, the <infection range> is level dependant - If negative, it is not: E.g. "<infection range> -6" means creatures can be infected in six square range, and <plaque level> doesn't modify that. <persistence> defines how long the disease can persist OUTSIDE a host. The disease can "move" <persistence> times outside a host before it vanishes. A negative value means the disease lasts for permanent (which is only recommended to use in maps without monsters). The disease will last in the host for <curing duration> "disease moves" (Assuming the host survives and doesn't use a curing spell). After this period the disease is naturally cured, which provides the host with immunity from this particular disease of lower or equal level. A negative value means the disease can never be cured naturally. Note that this value can be further modulated by spell-parameters, if the disease is registered as spell in the code. Due to that, most default diseases take a lot longer to cure than it seems. The <speed> of the disease determines how fast the disease will "move", thus how fast the symptoms strike the host. &speed_left;

The disease will attack the host with the given <attacktype>. Godpower attacktype is commonly used for "unresistable" diseases. A disease with a positive <damage> value will strike the player for that amount of damage every time the symptoms occur. A negative <damage> value produces %-based damage: "<damage> -10" means the player's health is reduced by 10% every time the symptoms strike. Diseases with %-based damage can be dangerous - but not deadly - for players of all levels. If set, the specified arch is created and dropped every time the symptoms strike. This can be various things: farts, body pieces, eggs ... Even monsters can be created that way. You could also make a disease where some exotic stuff like money/gems is created. If set, the disease imposes a <slowdown penalty> while being infected. The player's speed is reduced by <slowdown penalty> % of normal value. When the player manages to cure this disease (with a curing spell), he is awarded with <exp. for curing> experience. Every time the disease "moves", the player's mana is reduced by the value of <mana depletion>. For negative values, a %-based amount is taken. Every time the disease "moves", the player's food is reduced by the value of <food depletion>. For negative values, a %-based amount is taken. This value increases the player's healing rate. Negative values decrease it. This value increases the player's rate of mana regeneration. Negative values decrease it.

The player's strength will rise by the given value while being infected. (Negative values make strength fall) The player's dexterity will rise by the given value while being infected. (Negative values make dexterity fall) The player's constitution will rise by the given value while being infected. (Negative values make constitution fall) The player's intelligence will rise by the given value while being infected. (Negative values make intelligence fall) The player's power will rise by the given value while being infected. (Negative values make power fall) The player's wisdom will rise by the given value while being infected. (Negative values make wisdom fall) The player's charisma will rise by the given value while being infected. (Negative values make charisma fall)

This text is displayed to the player every time the symptoms strike. &movement_types_terrain; The more <hitpoints> the door has, the longer it takes to be broken. Doors of high <armour class> are less likely to get hit. <armour class> can be considered the "counterpiece" to <weapon class>. This string defines the object that will be created when the door was defeated. This entry determines what kind of traps will appear in the door. Set this flag to move treasure items created into the environment (map) instead of putting them into the object. It will multiply the number of items in the pile, by the <multiply factor>. If the latter is set to zero, it will destroy objects. ]]> not acceptable to allow duplication of anything other than coins, gold and jewels. Besides, it is very important that the chance to loose the input matches the chance to earn winnings.
A duplicator with <multiply factor> 3 for example should have a loosing rate of 2/3 = 67%. ]]> Only objects of matching archtype, lying ontop of the duplicator will be duplicated, multiplied or removed. All other objects will be ignored. The number of items in the target pile will be multiplied by the <multiply factor>. If it is set to zero, all target objects will be destroyed. An activator (lever, altar, button, etc) with matching connection value is able to trigger this duplicator. Be very careful that players cannot abuse it to create endless amounts of money or other valuable stuff! &activate_on;
You can be quite creative with the outlook of secret exits (their "face"). Don't forget to give the player relyable hints about them though. ]]> The exit path defines the map that the player is transferred to. You can enter an absolute path, beginning with '/' (for example "/peterm/FireTemple/fire1"). It can also be a relative path, not beginning with '/' (On the map "/peterm/FireTemple/Fire2" for example I could use the relative path "Fire1"). Use relative paths whenever possible! Note that upper/lower case must always be set correctly. However, please use lower case only. It is well possible to have an exit pointing to the same map that the exit is on. If slaying is not set in an exit, the player will see a message like "the exit is closed". The exit destinations define the (x, y)-coordinates where the exit leads to. If both are set to zero, the player will be transferred to the "default enter location" of the destined map. The latter can be set in the map- properties as "Enter X/Y". Though, please DO NOT use that. It turned out to be a source for numerous map-bugs. The exit destinations define the (x, y)-coordinates where the exit leads to. If both are set to zero, the player will be transferred to the "default enter location" of the destined map. The latter can be set in the map- properties as "Enter X/Y". Though, please DO NOT use that. It turned out to be a source for numerous map-bugs. &move_on; If set, this message will be displayed to the player when he applies the exit. This is quite useful to throw in some "role-play feeling": "As you enter the dark cave you hear the sound of rustling dragonscales...". Well, my english is poor, but you get the point. =) If set, then players using this exit will have their savebed position set to the destination of the exit when passing through. For dragon players, flesh plays a very special role though: If the flesh has resistances set, a dragon player has a chance to gain resistance in those categories. The only constraint to this process is the <flesh level>. Don't forget that flesh items with resistances have to be balanced according to map/monster difficulty. ]]>
Generally adding special flesh-treaties for dragon players is a great thing to do. Always consider that dragon players might really not be interested in that special piece of weapon or armour, so don't let the dragon-fellows miss out on the reward completely. ]]> The player's stomache will get filled with this amount of foodpoints. The player's health will increase by <foodpoints>/50 hp. The <flesh level> is not visible to the players and it affects only dragon players. Normally this value reflects the level of the monster from which the flesh item originates. Dragon players always search for flesh of highest level possible, because it bears the best chance to gain high resistances. A godgiven item vanishes as soon as the player drops it to the ground. &resistances_flesh_section; This text may describe the item.

&movement_types_terrain; This flag indicates this spot contains wood or high grass. Players with activated woodsman skill can move faster here. This flag indicates this spot contains hills or large rocks. Players with activated mountaineer skill can move faster here.

If enabled, it is impossible for players to use (wizard-) spells on that spot. If enabled, it is impossible for players to use prayers on that spot. It also prevents players from saving. Unique floor means that any items dropped on that spot will be saved byond map reset. For permanent apartments, all floor tiles must be set <unique map>. This text may describe the object. The player's stomache will get filled with this amount of foodpoints. The player's health will increase by <foodpoints>/50 hp. A godgiven item vanishes as soon as the player drops it to the ground. magic_ear) or carrying special key-objects (-> inventory checker). Unlike locked doors, gates can get shut again after a player has passed, which makes them more practical in many cases. ]]> The speed of the gate affects how fast it is closing/opening. Whenever the inventory checker is triggered, all objects with identical <connection> value get activated. This only makes sense together with <blocking passage> disabled. The <position state> defines the position of the gate: Zero means completely open/down, the "number of animation-steps" (usually about 6 or 7) means completely closed/up state. I suggest you don't mess with this value - Leave the default in place. &movement_types_terrain; Restricting the use of spells to pass this gate. This has an effect only if <block view> is disabled. Restricting the use of prayers to pass this door. This has an effect only if <block view> is disabled. <magic bonus> works just like ac, except that it can be improved by "scrolls of Enchant Armour" or reduced by acid. It is less useful than direct armour-class bonus on the helmet. Important: <magic bonus> on girdles has no effect if there is no <armour class> set. Girdles shouldn't have <armour class>, thus <magic bonus> is pointless here. If the gloves provide <armour class>, <magic bonus> will increase it. If the gloves have <weapon class> instead, then <magic bonus> will increase that. Every time the handle is applied, all objects with the same <connection> value are activated. This text may describe the item. You can use this message to explain the handle's purpose to the player. Like magic walls, such floors add a permanent thrill to your map. You can use that to safely chase off too-weak players, or just to have something different. ]]> &move_on; This attribute specifys the attacktypes that this floor uses to damage it's victims. Attacktypes are: physical, fire, cold.. etc. If you want a real tough hazard floor, add more than just one attacktype. The <base damage> defines how much damage is inflicted to the victim per hit. The final damage is influenced by several other factors like the victim's resistance and level. <weapon class> improves the chance of hitting the victim. Lower values are better. Usually, hazard floors like lava are supposed to hit the victim all the time. Therefore, <weaponclass> should be set to something like -30. I guess this value is supposed to work similar to monster levels. But in fact, it does not seem to have an effect. Set any non-zero value to be on the safe side.

If enabled, it is impossible for players to use (wizard-) spells on that spot. If enabled, it is impossible for players to use prayers on that spot. It also prevents players from saving. Unique floor means that any items dropped on that spot will be saved byond map reset. For permanent apartments, all floor tiles must be set <unique map>. <magic bonus> works just like ac, except that it can be improved by "scrolls of Enchant Armour" or reduced by acid. It is less useful than direct armour-class bonus on the helmet. Important: <magic bonus> on helmets has no effect if there is no <armour class> set. It only works in combination with <armour class>. Crowns for instance typically provide no <amour class>. The altar belongs to the god of the given name. Possible options for <god name> are: Devourers, Lythander, Mostrai, Gaea, Ruggilli, Gnarg, Gorokh, Valriel and Sorig. If you want to have an unconsecrated altar, set <god name> 0 and eventually <reconsecrate level> 0. To re-consecrate an altar, the player's wisdom level must be as high or higher than this value. In that way, some altars can not be re-consecrated, while other altars, like those in dungeons, could be. Altars located in temples should have at least <reconsecrate level> 120. Some characters might need those altars, they would be very unhappy to see them re-consecrated to another cult.
A horn contains a spell. The player can use this spell by applying and "fireing" (blowing) the horn. Unlike wands/scrolls, horns can be used endlessly. ]]> Sets the <spell> of the horn. Consider twice before handing out any horns to players, since they can be used endlessly without any mana cost! Horns with heal/ restoration/ protection spells, IF available, MUST be very very VERY hard to get! The casting level of the <spell> determines it's power. For attack spells, level should not be set too high. This value represents the initial amount of spellpoints in the horn. Naturally, this is quite unimportant. When the horn is fully charged up, it will hold this maximum amount of spellpoints. Make sure it is enough to cast the contained spell at least once. But don't set the value too high, as that might make the horn way too effective. A godgiven item vanishes as soon as the player drops it to the ground. This text may contain a description of the horn. &resistances_basic;
Alternatively, you can set your inv. checker to block all players that do/don't carry the matching object.

As you can see, inv. checkers are quite powerful, holding a great variety of possibilities. ]]> This string specifies the object we are looking for: We have a match if the player does/don't carry a key object or a mark with identical <key string>. Note that key objects usually appear as "passports" in this context. A typical example is the city gate mechanism of scorn. This string specifies the object we are looking for: We have a match if the player does/don't carry an object of archtype <match arch name>. This value specifies the object we are looking for: We have a match if the player does/don't carry an object that is of type <match type>. Example: Set <match type> 15 (type 15 => weapon) and <blocking passage> enabled. Now you have an inv. checker blocking all players that carry any kind of melee weapon. To pass, a player is forced to leave behind all his weaponry... bad news for a warrior. ;) Enabled means having that object is a match. Disabled means not having that object is a match. Whenever the inventory checker is triggered, all objects with identical <connection> value get activated. This only makes sense together with <blocking passage> disabled. &movement_types_terrain; <remove match> means remove object if found. Setting this is usually not recommended because inv. checkers are in general invisible. So, unlike for altars/ locked doors, the player won't expect to lose an object when walking over that square. And he doesn't even get a message either. So, *if* you enable <remove match>, make sure to inform the player what's going on!

slaying slayer:[yield ]new_item[;slayer:[yield ]new_item]*

with [] denoting optional part, and * any number of preceding []. 'new_item' must be the name of an existing archetype.

Example, for object apple: slaying knife:2 half_apple

This means that, when applying a knife (should be an Item Transformer), one 'apple' will be transformed into 2 'half_apple'.]]> <number of uses> controls how many times the item transformer can be used. The value 0 means "unlimited" Contains the verb that is used to construct a message to the player applying the item transformer. A godgiven item vanishes as soon as the player drops it to the ground. This text may contain a description of the item transformer. This text may describe the object. A godgiven item vanishes as soon as the player drops it to the ground. The <key string> in the door must be identical with the <key string> in the special key, then the door is unlocked. It is VERY important to set the <key string> to something that is unique among the CF mapset. DONT EVER USE the default string "set_individual_value". Restricting the use of spells to pass this door. This should be set in most cases. (Don't forget that the spell "dimension door" is easily available at about wisdom level 10). Restricting the use of prayers to pass this door. This should be set in most cases. When a player is trying to open the door without carrying the appropriate key, this text is displayed to the player. This is a good opportunity to place hints about the special key needed to unlock the door.
Magic_ears are typically used for interaction with NPCs. You can create the impression that the NPC actually *does* something according to his conversation with a player. Mostly this means opening a gate or handing out some item, but you could be quite creative here. ]]> The Magic_ear will trigger all objects with the same connection value, every time it is activated. This textfield contains the keyword-matching-syntax. The text should have the following format: "@match <keyword1>|<keyword2>|... ". Any number of keywords from one to infinite is allowed. Make sure they are seperated by a '|'. Examples: "@match yes", "@match gold|treasure". The connected value will be triggerd when the player speaks any of the given keywords within a two-square radius. IMPORTANT: Upper/lower case does not make a difference!
Several types of magical walls are predefined for you in the archetypes, and can be found on the "connected" Pickmap. ]]>
Another point of magic walls is that if the player dies, he has to face them all again. Magic walls can add a kind of "permanent thrill" to your maps.

Be careful that your magic walls don't kill the monsters on a map. If placing monsters, eventually take ones that are immune to the walls' spell(s).

It is possible to make walls rotate when triggered. But that is so confusing (and useless IMHO) that I did not mention it above. You can find a working example on the map "/pup_land/castle_eureca/castle_eureca8". ]]> The magic wall will cast this <spell>. The wall will cast it's spells at level <spell level>. "level 1" walls cast spells at minimal strength. "level 100" walls cast deadly spells. Arch default is level 1 - you should always set this value to meet the overall difficulty of your map. Every time the <connection> value is triggered, the wall will cast it's spell. You should set <casting speed> to zero, or this won't have much visible effect. &activate_on; The <casting speed> defines the spellcasting speed of the wall. You can fine-tune how long the duration between two casts shall be. If you want to create a wall that can be activated (cast per trigger) via connected lever/button/etc, you must set "speed 0". &speed_left; The magic wall will cast it's spells always in the specified <direction>. A magic wall with direction set to <none> will always fire in a random direction. &movement_types_terrain;

Walls with <is destroyable> enabled can be attacked and (eventually) destroyed by the player. If disabled, all other attributes on this tab, as well as resistances, are meaningless. The more <hitpoints> the wall has, the longer it takes to be destroyed. <max hitpoints> are the maximum amount of hitpoints the wall can have. This only makes sense if the wall can regain health. A magic wall of high <armour class> is less likely to get hit from an opponent. <armour class> can be considered the "counterpiece" to <weapon class>.

&resistances_basic;
Note that the player has no possibility to "see" his own marks, except by the effect that they cause on the maps. ]]>
Please avoid infinite markers when they aren't needed. They're using a little space in the player file after all, so if there is no real purpose, set an expire time. ]]> The <key string> can be detected by inv. checkers/detectors. If the player already has a force with that <key string>, there won't be inserted a second one. When the detector is triggered, all objects with the same connection value get activated. The <marking speed> defines how quickly it will mark something standing on the marker. Set this value rather high to make sure the player really gets his mark. I think <marking speed> 1.0 should do fine. &speed_left; This value defines the duration of the force it inserts. If nonzero, the duration of the player's mark is finite: about 1 food per 10 seconds. <mark duration> zero/unset means the mark will stay on the player forever. When the player steps onto the marker, all existing forces in the players inventory with a <key string> matching <delete mark> will be removed. If you don't want to remove any marks, leave this textfield empty. Note that the string <delete mark> is set as the name of this marker. So don't be confused, and remember changing the name will take effect on the marker's functionality. In the moment when the player gets marked, this text is displayed to him. You should really set a message in any marker you create, because it's the only way for the player to notice what's going on. When a player picks an item from a shop and attempts to walk over the shop mat, the item's selling-price is automatically subtracted from the player's money.

For money, always use the default arches. Don't modify them. ]]>

Place only monsters of slightly varying (increasing) strength. It's no fun to play for two hours just to find out the last monster is unbeatable. Similar, it's not exciting to fight orcs after passing a room of dragons.
This rule applies only for linear maps (one room after the other), with treasure at the end. You can sprinkle the treasure around, or make non-linear maps - That is often more entertaining.

Places with high level monsters must not be easy to reach. Balrogs, Dragonmen and the likes should be at the end of a quest, not at the beginning.

Don't stick monsters together that tend to kill each other. Fire- and cold dragons in one room for example is a bad idea. By weakening and killing each other they are easy prey for players, not worth the experience they hold.

Create your own monsters, especially for "boss"-type monsters. Having stage-bosses guarding treasure is a lot of fun when done right. Avoid to create monsters with completely non-intuitive abilities: Don't give ice-spells to firedragons or vice versa. Don't add draining attack to trolls, etc. Additionally, you should inform the player before he bumps right into some very special/unusual monster.

Last but not least: Always keep an eye on the experience your monsters hold. Design your maps in a way that high experience is always well-defended. Don't make large rooms full with only one kind of monster. Keep in mind the different abilities/techniques players can use. I know it's impossible to make the perfectly balanced map. There's always some part which is found too easy or too hard for a certain kind of player. Just give it your best shot. And listen to feedback from players if you receive some. :-) ]]> When the monster is killed, items from the treasurelist will drop to the ground. This is a common way to reward players for killing (masses of) monsters. Note that you can always put items into the monster's inventory. Those will drop-at-kill just like the stuff from the <treasurelist>. Set this flag to move treasure items created into the environment (map) instead of putting them into the object. A monster's <level> is the most important attribute. <level> affects the power of a monster in various ways. Every monster should have a race set to categorize it. The monster's <race> can have different effects: Slaying weapons inflict tripple damage against enemy races and holy word kills only enemy races of the god. When a player kills this monster, he will get exactly this amount of <experience>. The experience will flow into the skill-category the player used for the kill. If you create special monsters of tweaked strenght/abilities, always make sure that the <experience> is set to a reasonable value. Compare with existing arches to get a feeling what reasonable means. Keep in mind that spellcasting monsters are a lot harder to kill than non-spellcasters! The <speed> determines how fast a monster will both move and fight. High <speed> makes a monster considerably stronger. &speed_left; This only takes effect if <multiply> is enabled. The monster will create a <breed monster> every once in a while. <breed monster> can be set to any valid arch-name of a monster. Multipart monster should not be used. Monsters with <generator> enabled will create a <breed monster> every once in a while. Mice are a good example for this effect. If enabled, you must also set <breed monster> or check <template generation> and put other monsters in the inventory. This only takes effect if <multiply> is enabled. The monster will create a new monster every once in a while by duplicating it's inventory. In this case, the <breed monster> value is never used and can be forgotten. Each time the monster need to generate an object, it will be a randomly chosen item from the inventory. When generator is destroyed, inventory is destroyed. &move_type; Several spells only affect undead monsters: turn undead, banish undead, holy word, etc. If a monster has something in the inventory, this value can be set to reflect the slowdown due to the carried weight. Set this flag to indicate that this monster is precious, i.e. it should not be lightly destroyed. This is most useful on pets and keeps the server from destroying them on destroy_pets/monster floors and will try to save them when the player logs out.

This number is a bitmask, specifying the monster's attacktypes for melee damage. Attacktypes are: physical, magical, fire, cold.. etc. Strong monsters often have more than just physical attacktype. When a monster with multiple attacktypes hits aan oponent, it will do as much damage as the "best" of it's attacktypes does. So, the more attacktypes, the more dangerous. Attacktypes "magic" and "chaos" are somehow exceptions. Among other parameters, <damage> affects how much melee damage a monster inflicts. <damage> is used as base value for damage per hit. <level>, <speed>, <weapon class> and resistances also take effect on the melee damage of a monster. Monsters of high <weapon class> are more likely to really hit their opponent. <weapon class> can be considered the "counterpiece" to <armour class>. The <health points> of a monster define how long it takes to kill it. With every successful hit from an opponent, <health points> get drained - The monster dies by zero <health points>. <max health> is the maximum amount of <health points> this monster can have. Monsters of low <armour class> are less likely to get hit from their opponent. <armour class> can be considered the "counterpiece" to <weapon class>. Values typically range between +20 (very bad) to -20 (quite good). Monsters regenerate this many health points each 4 ticks. Hence, the healing rate is independent of <speed>. A monster with this flag has the ability to <reflect missiles>, all kinds of projectiles (e.g. arrows, bolts, boulders) will bounce off. Monsters with <hitback> enabled hurt the attacker in proportion to the amount of damage the *attacker* inflicted. This damage is additional to the regular melee damage of the monster. As far as I know, hitback uses acid attacktype, and it only takes effect if the monster actually has acid attacktype at it's disposal. Acid spheres for example use this feature. Monsters with <one hit only> dissapear after one successful hit to a player.

If <can cast spell> is disabled, the monster cannot cast any spell. Only wands/rods/etc can be used, given the appropriate abilities. A monster with this flag has the ability to <reflect spells>, all kinds of spell-bullets and -beams will bounce off. Generally this flag should not be set because it puts wizard-type players at an unfair disadvantage. Like players, monsters need <spellpoints> to do magic. Monsters use them for both wizard- and prayer-spells. However, this value defines only the amount of *initial* spellpoints the monster starts with. When creating a spellcasting monster, remember that <max spellpoints> and <spellpoint regen.> are more important than just initial <spellpoints>. <max spellpoints> is the maximum number of spellpoints a monster can hold. Setting this to high values has little effect unless the monster has a decent <spellpoint regen.>, or the spell "regenerate mana" at it's disposal. Monsters regenerate this many spellpoints each 16 ticks. Hence, the spellpoint regeneration rate is independent of <speed>. To make a real tough spellcasting monster, the rate of spellpoint regeneration is most important. If your monster is still not casting fast enough, give it the spell-ability of "regenerate mana". That, paired with high <max spellpoints>, is the ultimate thing. Click on the <attuned paths> button to select spellpaths. The creature will get attuned to the specified spellpaths. Click on the <repelled paths> button to select spellpaths. The creature will get repelled to the specified spellpaths. Click on the <denied paths> button to select spellpaths. The creature won't be able to cast spells of the specified paths.

The <detect hidden> value gives monsters the ablitity to find hidden/invisible creatures. Higher values make for better detection-skills. Enabling <see invisible> makes this value obsolete. A monster with the ability to <see invisible> cannot be fooled with by invisible or hiding players. This flag is a must-have for high-level monsters. When a monster is unable to detect invisible players, it can be killed without fighting back. A monster with the ability to <see in darkness> cannot be fooled by spells of darkness or dark maps. This flag is a "should-have" for high-level monsters. When a monster is unable to see in darkness, players can cast darkness and sneak around it safely. Monster is able to wield weapon type objects. Monster is able to use missile-weapon type objects. Monster is able to wear protective equipment like brestplate armour, shields, helmets etc. Monster is able to wear rings. Monster is able to use wands and staves. Monster is able to use rods. Monster is able to read scrolls. Monster is able to use skills from it's inventory. For example, you can put a throwing skill object and some boulders into the monster's object and set <can use skills>.

When <monster behaviour> is enabled, this object will behave like a monster: It can move and attack enemies (which are typically players). This flag should be set for all monsters as-such. Monsters which don't move, like guards, should also have <monster behaviour>, but in combination with <stand still>. It should *not* be set for things like immobile generators. <unaggressive> monsters do not attack players unless attacked first. <friendly> monsters help the player, attacking any non-friendly monsters in range. Monsters which <stand still> won't move to leave their position. When agressive, they will attack all enemies who get close to them. This behaviour is commonly known from castle guards. In older versions of Crossfire it was possible to eventually push a <stand still>-monster out of position by force. I believe this is no longer possible. Neverthless, you should still be cautious when lining up <stand still>-monster in order to "defend" something: Such monsters are rather easy to kill. It's good for low level maps, but not much more. Being <asleep>, a monster won't move unless a player enters the <sensing range> of the monster. Usually the sensing range is larger than the players line of sight. Due to that, in most cases the player won't ever notice weither a monster was asleep or not. This entry defines which kinds of environment actions the creature is able to perform. Click on the <pick up> button and select which types of objects the creature should try to pick up. Note also that if <can use armor>, <can use weapon>, <can use ring>... etc are set, then the creature will pick up the matching items even if this is not set here. <sensing range> determines how close a player needs to be before the creature wakes up. This is done as a square, for reasons of speed. Thus, if the <sensing range> is 11, any player that moves within the 11x11 square of the monster will wake the monster up. If the player has stealth, the size of this square is reduced in half plus 1. If this is set to default, the standard mode of movement will be used. This movement is not in effect when the monster has an enemy and should only be used for non agressive monsters. This is a percentage value in the range 0-100. When the monster's health points drop below this percentage (relative to max health), it attempts to run away from the attacker.

&resistances_basic; A grimreaper is a monster that vanishes after it did some number of draining attacks.

The object vanishes after this number of draining attacks.

To turn an NPC into a pet, put a charm_floor under it and connect it directly to a magic_ear. Then the player speaks a keyword like "help me" - and the NPC joins him as pet.

(Of course you must always give clear hints about keywords! And there is no reason why you couldn't use a button/lever/pedestal etc. instead of a magic_ear.) ]]> <mood> is used to determine what will happen to the monster when affected by the mood floor: <mood> 'furious': Makes all monsters aggressive <mood> 'angry': As above but pets are unaffected <mood> 'calm': Makes all monsters unaggressive <mood> 'sleep': Puts all monsters to sleep <mood> 'charm': Turns monster into a pet of person who triggers the square. This setting is not enabled for continous operation, you need to insert a <connection> value! This should only be set in combination with <mood number> 4. Normally, monsters are affected by the mood floor as soon as they step on it. But charming (monster -> pet) is too powerful, so it needs to be activated. Typically it is connected to an altar, for buying a "hireling". But a powerful pet could as well be the reward for solving a quest. Or even better: It could be *part* of a quest! If enabled, it is impossible for players to use (wizard-) spells on that spot. If enabled, it is impossible for players to use prayers on that spot. It also prevents players from saving.
Multisquare monsters can be moved as well, given enough space. Movers are usually invisible. ]]>
Btw, it does not make a difference putting movers above or below the floor. Moreover, movers that are set to be invisible cannot be discovered with the show_invisible spell.

Note that Movers and Directors are seperate objects, even though they look and act similar. Directors only do spells/missiles, while movers only do living creatures (depending on how it is set: monsters and players). ]]> If forced movement is enabled, the mover "freezes" anyone it moves (so they are forced to move along a chain). For players there is no way to escape this forced movement, except being pushed by a second player. The player will be "frozen" for that many moves. If <freeze duration> is zero, with <forced movement> enabled, then <freeze duration> gets assigned the "default value" 2 automatically. The movement speed value determines how fast a chain of these movers will push a player along (default is -0.2). &speed_left; The mover will push creatures in the specified <direction>. A mover with direction set to <none> will spin clockwise, thus pushing creatures in unpredictable directions. If enabled, the mover gets "used up" after a certain number of moves (specified by <number of uses>). If disabled, the mover works infinitely. This value has only a meaning if <gets used up> is set: <number of uses> is the number of times minus one, that it will move a creature before disappearing. (It will move someone <number of uses>+1 times, then vanish).

If <move players> is enabled, both players and monsters will be moved. In the arches' default it is disabled - thus ONLY monsters get moved. Remember that "monsters" includes NPCs! This feature provides you with the possibility to make NPCs literally "come to life". Example: The player is talking with an NPC, speaking a certain keyword. This triggers a magic_ear and activates creators, creating (per default: monster-only) movers under the NPC's feet. The NPC starts "walking" on a predefined route! Note that it's useful to set this NPC immune to everything, preventing the player to push the NPC off his trace. Which movement types activate the mover.

the <match race> defines the object we're looking for. If <match race> matches the monster's or the player's race, we have a match. Yes, pedestals can detect a player's race! E.g. you could create a place where only fireborns can enter, by setting "slaying unnatural". If it is set to "player", any player stepping on the pedestal is a match. Very useful if you want to open a gate for players but not for monsters. When the pedestal is triggered, all objects with the same connection value get activated. &move_on; Optionally, pits can get closed and opened, similar to gates.

Monsters and items are affected by pits just as well as players. Even multipart monsters can fall through them, given enough space. ]]> When a <connection> value is set, the pit can be opened/closed by activating the connection. &activate_on; The pit will transport creatures (and items) randomly into a two-square radius of the destination coordinates. If the destination square becomes blocked, the pit will act like being filled up and not work anymore! The pit will transport creatures (and items) randomly into a two-square radius of the destination coordinates. If the destination square becomes blocked, the pit will act like being filled up and not work anymore! The <position state> defines the position of the gate: Zero means completely open/down, the "number of animation-steps" (usually about 6 or 7) means completely closed/up state. I suggest you don't mess with this value - Leave the default in place. &move_on; If the potion contains a spell, the spell is cast at this level. For other potions it should be set at least to 1. When a player drinks this potion, the selected spell will be casted (once). This should work for any given spell. E.g. heal is "sp 35", magic power is "sp 67". There are two types of special effects for potions: 'life restoration' - restore the player's stats lost by death or draining (this has nothing in common with the restoration spell!) 'improvement' - increase the player's maximum health/mana/grace by a very small amount. If a potion is cursed, benefits generally turn into penalties. Note that potions can be "uncursed" by praying over an altar, with relative ease. *But* the potion must be identified to notice that it is cursed >:) A godgiven item vanishes as soon as the player drops it to the ground. &player_stat_resist_sections; <initial mana> is the amount of spellpoints that the crystal holds when the map is loaded. The <mana capacity> defines how much mana can be stored in the crystal. This is what makes the crystal interesting. Wizard-players will always seek for crystals with large capacities.
It's very easy to add new pairs of weapons & projectiles. Just set matching <ammunition class> both for shooting weapon and projectile. ]]> This number is a bitmask, specifying the projectile's attacktypes. Attacktypes are: physical, magical, fire, cold.. etc. This works identical to melee weapons. Note that shooting weapons cannot have attacktypes. Only shooting weapons with matching <ammunition class> can fire these projectiles. For arrows set "arrows", for crossbow bolts set "crossbow bolts" (big surprise). In certain cases, the ammunition class is displayed in the game. Hence, when you create a new ammunition class, choose an intuitive name like "missiles", "spirit bolts" - whatever. You can also make special containers holding these projectiles by setting the <container class> to match your <ammunition class>. Slaying means the weapon does tripple (3x) damage to monsters of the specified race. If <slaying race> matches an arch name, only monsters of that archtype receive tripple damage. Tripple damage is very effective. The projectile <damage> significantly affects the damage done. Damage can be further increased by the shooting weapon's attributes. This value is supposed to be the base <weaponclass>, but it seems to have rather little effect. High values are good here, low values bad. The <chance to break> defines the breaking probability when this projectile hits an obstacle, e.g. wall or monster. The value is the %-chance to break, ranging from 0 (never breaking) to 100 (breaking at first shot). Magic bonus increases chance to hit and damage a little bit. Unique items exist only one time on a server. If the item is taken, lost or destroyed - it's gone for good. A godgiven item vanishes as soon as the player drops it to the ground. When a monster carries a projectile with <don't drop>, this item will never drop to the ground but vanish instead. If this object is shot, it can still drop after hitting an obstacle. You can prevent this by setting <chance to break> 100. This text may describe the projectile. This could be nice for very special ones. two rings! Due to that it is extremely important to keep rings in balance with the game.

Also keep in mind that rings are generally the wizard's tools. They should primarily grant bonuses to spellcasting abilities and non-physical resistances. ]]> ]]> Sets the <spell> of the rod. Consider twice before handing out special rods to players, since they can be used endlessly without any mana cost! Rods with heal/ restoration/ protection spells, IF available, MUST be very very VERY hard to get! The casting level of the <spell> determines it's power. For attack spells, level should be set to something reasonable. This value represents the initial amount of spellpoints in the rod. Naturally, this is quite unimportant. When the rod is fully charged up, it will hold this maximum amount of spellpoints. Make sure it is enough to cast the contained spell at least once. But don't set the value too high, as that might make the rod too effective. A godgiven item vanishes as soon as the player drops it to the ground. This text may contain a description of the rod.
Runes hit any monster or person who steps on them for 'dam' damage in 'attacktype' attacktype. Alternatively, the rune could contain any spell, and will cast this spell when it detonates. Yet another kind is the "summoning rune", summoning predefined monsters of any kind, at detonation.

Many runes are already defined in the archetypes. ]]> &move_on; This value sets the level the rune will cast the spell it contains at, if applicable. A level 99 rune casts a very, very mean spell of whatever. (<rune level> 0 runes won't detonate at all!) Level Also effects how easily a rune may be found and disarmed, and how much experience the player gets for doing so. Beware: High level runes can be quite a cheap source of experience! So either make them tough, or keep the level low. This value determines what fraction of the time the rune is visible: It'll be randomly visible 1/<visibility> of the time. Also effects how easily the rune may be found. The rune will detonate <number of charges> times before disappearing. <direct damage> specifies how much damage is done by the rune, if it doesn't contain a spell. This should be set in reasonable relation to the rune's level. If there isn't any spell (and <summon monster> is unset), this attribute defines what attacktype to use for direct damage when the rune detonates.

The selected <spell> defines the spell in the rune, if any. (Many runes do direct damage). Name of the spell in the rune, if any. <spell name> is optional, but if present, overrides the <spell> setting. This string defines the spell in the rune, if any. <spell arch> is optional, but if present, overrides the <spell> setting. You can choose any of the existing arches. If set, the rune will cast it's containing spell (if any) in this <direction>.In most cases this appears useless because the spell directly hits the player. If this is set to the arch name of any monster, together with <spell name> "summon evil monster", the rune will summon a bunch of those on detonation. (dam and attacktype will still be ignored in this case). Runes are even capable of summoning multi-square monsters, given enough space. You'd better test it though. This should only be set to a summoning rune. It will then summon that many creatures of the kind <summon monster>.

When the rune detonates, this text is displayed to the victim. For especially powerful runes, create an appropriate thrilling description. ;)

Monsters must not be able to reach the savebeds under any circumstances!

If there are NPCs around, make sure they have the friendly-flag set.

Insert a relyable exit! Make sure there is no possibility that players get trapped in a savebed location.

If possible, mark the whole site as no-spell area (Insert this arch called "dungeon_magic" everywhere). This is not required, but it makes the place much more safe. ]]> The spell of the scroll will be casted at this level. This value should always be set, at least to 1. When a player/monster applies this scroll, the selected <spell> will be casted (once). This should work for any given spell. A godgiven item vanishes as soon as the player drops it to the ground. <magic bonus> works just like ac, except that it can be improved by "scrolls of Enchant Armour" or reduced by acid. It is less useful than direct armour-class bonus on the shield.
It's very easy to add new pairs of weapons & projectiles. Just set matching <ammunition class> both for shooting weapon and projectile. ]]> Only projectiles with matching <ammunition class> can be fired with this weapon. For normal bows set "arrows", for normal crossbows set "crossbow bolts". In certain cases, the ammunition class is displayed in the game. Hence, when you create a new ammunition class, choose an intuitive name like "missiles", "spirit bolts" - whatever. After shooting a projectile, the player is frozen for a short period of time (to prevent shooting arrows machine-gun-like). The greater <shooting speed>, the shorter this period of time. 1 is minimum (=worst) and 100 is maximum (=best) value. You shouldn't set <shooting speed> lower than 10. YOU MUST NOT SET IT TO ZERO! (That would freeze the player for eternety). The <base damage> significantly affects the damage done by using this weapon. This damage is added to the projectile damage and then (if <ignore strength> disabled) a bonus according to the player's strength is added. This value is supposed to be the base <weaponclass>, but it seems to have rather little effect. High values are good here, low values bad. The <item power> value measures how "powerful" an artifact is. Players will only be able to wear equipment with a certain total amount of <item power>, depending on their own level. This is the only way to prevent low level players to wear "undeserved" equipment (like gifts from other players or cheated items). It is very important to adjust the <item power> value carefully for every artifact you create! If zero/unset, the CF server will calculate a provisional value at runtime, but this is never going to be an accurate measurement of <item power>. Usually the player's strentgh takes effect on the damage done by the shooting weapon. If <ignore strength> is set, the player's strength is ignored. A damned shooting weapon cannot be unwielded unless the curse is removed. Removing damnations is a tick harder than removing curses. A cursed shooting weapon cannot be unwielded unless the curse is removed. Unique items exist only one time on a server. If the item is taken, lost or destroyed - it's gone for good. A godgiven item vanishes as soon as the player drops it to the ground.

The player's strentgh will rise/fall by the given value while wearing this shooting weapon. The player's dexterity will rise/fall by the given value while wearing this shooting weapon. The player's constitution will rise/fall by the given value while wearing this shooting weapon. The player's intelligence will rise/fall by the given value while wearing this shooting weapon. The player's power will rise/fall by the given value while wearing this shooting weapon. The player's wisdom will rise/fall by the given value while wearing this shooting weapon. The player's charisma will rise/fall by the given value while wearing this shooting weapon.

This text describes the weapons's "story". Every decent artifact weapon should have such a description. If enabled, items will appear on this square when the map is loaded. You need to specify a <treasurelist> to define what kinds of items are generated. The items will be unpaid. This entry determines what kind of treasure will appear, when <generate goods> is enabled. Look into /crossfire/share/crossfire/treasures for details about existing treasurelists. The <quality level> will be used for the quality of the generated goods. If zero/unset, <quality level> 5 is used. Usually this value doesn't need to be set, unless you want extraordinarily good/bad quality. If you want to make a shop with very high quality, meaybe charge an entrance fee, or make the shop hard-to-come-by. Note that <quality level> mainly affects chance of magic bonus and appearance of artifact-items. If enabled, it is impossible for players to use prayers on that spot. It also prevents players from saving. (Remember that <no magic> is always set for shop floors.) &move_on; When a connection value is set, the message will be printed whenever the connection is triggered. This should be used in combination with <invisible> enabled and <activate by walking/flying> disabled. If activating your magic_mouth this way, the message will not only be printed to one player, but all players on the current map. &activate_on; &move_on; If a counter-value is set (greater zero), the sign/magic_mouth can be applied (printing the message) only that many times. For signs this really shouldn't be used, while for magic_mouths it is extremely helpful. Monsters walking over the magic_mouth do not decrease the counter. Often, you might want to have a message displayed only one time. For example: The player enters your map and you put a magic_mouth to tell him about the monsters and how dangerous they look and all. Later, when all the monsters are killed and the player leaves the map, displaying the same message a second time would be silly. <counter> 1 does a perfect job in such cases. Otherwise set <counter> zero/unset for infinite use (that is the default). This text will be displayed to the player. The format of this field is: 'x1,y1,x2,y2'. It defines a rectangle on the map that will be searched for unpaid items. First, the predefined skill archtypes (in the 'skills' directory) can be seen as the global skill definitions. A skill which doesn't exists as an archtype cannot be learned or used by players. When you want to use skills in your maps, you may need to look up the <skill name>s of defined skill archtypes, because those strings are used as a reference in many skill-related objects.

Secondly, in order to enable monsters to use skills, you will need to copy default skill archtypes into the monsters' inventories. You can even customize the skills by changing stats. It is not recommended however, to use skills in your maps which are totally unrelated to any predefined skill archtype.

]]> The <skill name> is used for matchings. When a usable object has an identical <skill name>, players (or monsters) will need this skill to apply/use the object. This is the ratio of experience the players total should increase by when this skill is used. If this is zero, then experience only goes to to the skill. Values higher than 1 are allowed. Note that experience rewarded to the players total is in addition to that given to the skill. Eg, if player should get 500 exp for using a skill, and expmul is 1, the player will get 500 added to that skill as well as 500 to their total. The <skill type> defines the base functionality of the skill. Skill types are hardcoded in the Crossfire server. It isn't hard to create new skill types, but it requires a bit of server-coding. The <is native skill> flag has an effect only when this skill object is placed in the inventory of a monster (or player). If it is set, the monster or player knows the skill natively, which means he does not need a skill tool to use it. The <skill name> matches the skill object that can be learned from this scroll.
This object-type can also be used for "passport"-like items: When walking onto an invetory checker, a gate for example might get opened. The "passport" will stay in the player's inventory. ]]>
Of course you can be creative with names and faces of key-objects. A "mysterious crystal" or a "big dragon claw" (with appropriate faces) appear more interesting than just a "strange key", or "passport". ]]> This string must be identical with the <key string> in the locked door, then it can be unlocked. It can also be used to trigger inventory checkers. For Special Keys, material should always be unset or set to Adamantite. This prevents the key from getting burned or otherwise destroyed. Unique items exist only one time on a server. If the item is taken, lost or destroyed - it's gone for good. This can be used if you want to sell apartments on your map: Simply sell a unique passport/key, and place an inventory checker at the entrance of your apartment. A godgiven item vanishes as soon as the player drops it to the ground. This will add a description to the object. The player can read this text by clicking on the item in his inventory. Use this message to describe what the key/passport is good for. A player might have 50 different keys on his key-ring. Don't expect players to recall their purpose just by their names. Monsters can use spells which are put in their inventory (provided that certain "enabling" settings are correct). The monster's <treasurelist> can also be used to provide it with spells. ]]> The <skill name> matches the skill which is needed to cast this spell. This should be one out of "sorcery", "pyromancy", "evocation", "summoning" or "praying". If you want to fiddle with these, please take care not to upset the concept and balance of the various skills. The <spell type> defines the basic type of spell. Some of these types are of a more generic nature than others.
You can create widely customized spells only by adjusting the spell object in the spellbooks inventory. Refer to the description of spell objects for detailed information how to customize spells.
If you want to have a random spellbook instead, choose a <treasurelist> with a compilation of spells that the book may contain. ]]>
Note that there is no fundamental difference between the spellbooks of varying schools (pyromancy, sorcery, evocation, summoning, and even praying). The difference lies only in the spells they contain. It is up to you, the mapmaker, to pick the right type of book for your spells. ]]> There are two ways to put spells into a spellbook: 1. Put a spell object in the books inventory. In this case, treasurelist must be set to <none>. 2. Choose a treasurelist which contains spells. In that way, a spell will be chosen randomly from the list. A godgiven item vanishes as soon as the player drops it to the ground. This text may contain a nice description of the spellbook's cover or something. The spinner will change the direction of flying objects by 45 degrees per <direction number>. Negative values spin clockwise, positive values counter clockwise. Example: <direction number> -2 means spin 90 degrees clockwise. &move_on; The higher the <drowning speed>, the faster will players and items sink into the swamp. Swamp with very high <drowning speed> can be a nasty and unexpected death-trap. Players should get a warning before such areas. &speed_left; &move_on; &movement_types_terrain; If enabled, it is impossible for players to use (wizard-) spells on that spot. If enabled, it is impossible for players to use prayers on that spot. It also prevents players from saving.
Unlike exits, teleporters can also transfer items and monsters to different locations on the same map. ]]>
Fortunately, there is a cool trick to make a perfectly invisible teleporter: You simply add teleporter functionality to the floor itself. That means: You take the floor arch (e.g. "flagstone"), set "type 41", and add slaying/hp/sp/connected... everything you need. ]]> The exit path specifies the map that the player is transferred to. <exit path> can be an absolute path, beginning with '/' (for example "/peterm/FireTemple/fire1"). It can also be a relative path, not beginning with '/' (On the map "/peterm/FireTemple/Fire2" for example I could use the relative path "Fire1"). Use relative paths whenever possible! Note that upper/lower case must always be set correctly. However, please use lower case only. If the <exit path> is set, ONLY players can get teleported. If the <exit path> is unset (empty), anything can get teleported: Players, monsters and items. In this case, the destined map is automatically the same map the teleporter is on. The exit destinations define the (x, y)-coordinates where the exit leads to. If both are set to zero and <exit path> is empty, the player will get teleported to another, randomly chosen teleporter on the same map (Slightly confusing for the player though). Make sure there actually *is* a second one in that case. If both are set to zero and <exit path> is set, the player will be transferred to the "default enter location" of the destined map. The latter can be set in the map-properties as "Enter X/Y". Though, please DO NOT use that. It turned out to be a source for numerous map-bugs. The exit destinations define the (x, y)-coordinates where the exit leads to. If both are set to zero and <exit path> is empty, the player will get teleported to another, randomly chosen teleporter on the same map (Slightly confusing for the player though). Make sure there actually *is* a second one in that case. If both are set to zero and <exit path> is set, the player will be transferred to the "default enter location" of the destined map. The latter can be set in the map-properties as "Enter X/Y". Though, please DO NOT use that. It turned out to be a source for numerous map-bugs. If a connection value is set, the teleporter will be activated whenever the connection is triggered. To use this properly, <activation speed> must be zero. &activate_on; If the <activation speed> is nonzero, the teleporter will automatically be activated in regular time-intervals. Hence, the player can just step on it and gets teleported sooner or later. The duration between two activates depends on the given value. Default in the teleporter arch is <activation speed> 0.1. VERY IMPORTANT: If you want to have your teleporter activated via button/handle/magic_ear/etc, you must set <activation speed> to zero! &speed_left; magic_ear) or carrying special key-objects (-> inventory checker). Unlike locked doors, gates can get shut again after a player has passed, which makes them more practical in many cases. Unlike normal gates, timed gates open when triggered but automatically close again after some time.]]> Whenever the inventory checker is triggered, all objects with identical <connection> value get activated. This only makes sense together with <blocking passage> disabled. If unset, the gate opens automatically after some time. &activate_on; The <position state> defines the position of the gate: Zero means completely open/down, the "number of animation-steps" (usually about 6 or 7) means completely closed/up state. I suggest you don't mess with this value - Leave the default in place. &movement_types_terrain; Restricting the use of spells to pass this gate. This has an effect only if <block view> is disabled. Restricting the use of prayers to pass this door. This has an effect only if <block view> is disabled. Defines the duration the gate remains closed. This only takes effect if the gate is not connected.
Traps hit any monster or person who steps on them for 'dam' damage in 'attacktype' attacktype and/or trigger a reaction.

Many traps are already defined in the archetypes.]]> &move_on; Level effects how easily a trap may be found and disarmed, and how much experience the player gets for doing so. Beware: High level traps can be quite a cheap source of experience! So either make them tough, or keep the level low. This value determines what fraction of the time the trap is visible: It'll be randomly visible 1/<visibility> of the time. Also effects how easily the trap may be found. The trap will detonate <number of charges> times before disappearing. <direct damage> specifies how much damage is done by the trap. This should be set in reasonable relation to the trap's level. This attribute defines what attacktype to use for direct damage when the trap detonates. When the trap is detonated, all objects with the same connection value get activated. When the trap detonates, this text is displayed to the victim. For especially powerful or complex traps, create an appropriate and thrilling description. ;) Once a trapdoor has been opened (by a creature or items of sufficient weight,) it remains open, acting like an opened pit. ]]> &move_on; This value defines how much weight the trapdoor can hold. Once items or creatures are gathered on the trapdoor, with a total weight surpassing this value, then the trapdoor will open and things start falling through. The trapdoor will transport creatures (and items) randomly into a two-square radius of the destination coordinates. If the destination square becomes blocked, the trapdoor will act like being filled up and not work anymore! The trapdoor will transport creatures (and items) randomly into a two-square radius of the destination coordinates. If the destination square becomes blocked, the trapdoor will act like being filled up and not work anymore! This entry determines what kind of treasure will appear. Look into /crossfire/share/crossfire/treasures for details about existing treasurelists. "Auto-generate" must be set in order to have the treasure be created when the map is loaded. If you want to create a random treasure chest, you unset this flag. That way, the player has to apply the object (the chest), then the treasure is generated. "Create number" specifies how many pieces of the given treasurelist will appear. Note that for every piece there is a chance that nothing is generated. Also, sometimes there can be stacks of items generated, like for gems/money. The <quality level> will be used for the quality of the generated treasure instead of the map difficulty (as was done with shops). If zero/unset, the map difficulty will instead be used. (Example for comparison: Shop floors generate treasure of <quality level> 5 per default).
Note that the player has no possibility to "see" his own marks, except by the effect that they cause on the maps. ]]>
Please avoid infinite markers when they aren't needed. They're using a little space in the player file after all, so if there is no real purpose, set an expire time. ]]> The <key string> can be detected by inv. checkers/detectors. If the player already has a force with that <key string>, there won't be inserted a second one. Unlike a regular marker this is the connection that triggers this marker to activate. This value defines the duration of the force it inserts. If nonzero, the duration of the player's mark is finite: about 1 food per 10 seconds. <mark duration> zero/unset means the mark will stay on the player forever. When the player steps onto the marker, all existing forces in the players inventory with a <key string> matching <delete mark> will be removed. If you don't want to remove any marks, leave this textfield empty. Note that the string <delete mark> is set as the name of this marker. So don't be confused, and remember changing the name will take effect on the marker's functionality. In the moment when the player gets marked, this text is displayed to him. You should really set a message in any marker you create, because it's the only way for the player to notice what's going on. &movement_types_terrain; If set, the object is able to "roll", so it can be pushed around. This setting is used for boulders and barrels. This takes effect only with <blocksview> disabled. Restricting the use of spells to pass this wall. This takes effect only with <blocksview> disabled. Restricting the use of spells to pass this wall.
For low levels, staffs of healing/cure and word of recall are quite desirable though. Ideal rewards for low level quests. ]]> The <spell> specifies the contained spell. The <casting level> of the wand determines it's power. An average level for wands in shops is about 10. The wand can be used <number of charges> times before it is used up. It can be recharged with scrolls of charging. A godgiven item vanishes as soon as the player drops it to the ground. This text may contain a description of the wand. Anyways, there can be a lot more to weak walls than just finding them: Rising their defensive stats, weak walls can become a serious obstacle. An ice wall might only be torn down by a fire attack for example. A granite wall for instance might be very hard to destroy. ]]> For weak walls, <race> should always be set to "wall", unless you create something fancy like a building which is in fact meant to be a huge animal. Note that shovels slay walls, so they do tripple damage against weak walls. The <level> of a weak wall works similar to monster levels. Due to the fact that weak walls cannot attack, the level is much less important though. The <health points> of a weak wall define how long it takes to tear it down. With every successful hit from an opponent, <health points> get drained. <max health> is the maximum amount of <health points> this weak wall can have. Since walls generally don't heal, I doubt this has much real effect. Weak walls of high <armour class> are less likely to get hit. <armour class> can be considered the "counterpiece" to <weapon class>. &resistances_basic; This number is a bitmask, specifying the weapon's attacktypes. Attacktypes are: physical, magical, fire, cold.. etc. Most artifact weapons have no more than one or two attacktypes. Keep in mind that all weapons can be blessed by the player's diety, thus adding an additional attacktype. When a player hits a monster with a weapon that has more than one attacktype, then he will do as much damage as the "best" of his attacktypes does. So, the more attacktypes you've got, the better your chance to take advantage of a monster's vulnerabilities. (Btw: Same rule applies for monster vs. player.). Attacktypes "magic" and "chaos" are somehow exceptions. The <weapontype> characterizes the weapon's type of physical attack. It could best be considered a "subclassification" of the physical attacktype. For now, this is only used for attack messages! You should always set this correctly when creating new weapons for your maps. Matching <skill name> of the skill that is required to use this weapon. The damage value is used as base value for how much damage the weapon does per hit. The actual damage involves more dependencies, like wielder's level and defender's level. Look at existing weapons to get a feel for the range of weapon damage values. Slaying means the weapon does tripple (3x) damage to monsters of the specified race. If <slaying race> matches an arch name (e.g. "big_dragon"), only monsters of that archtype are hit with tripple damage. No god blessings are possible for weapons with a race set in this entry (That's because god blessings add tripple damage against their own enemy races). Tripple damage is very effective. The weapon speed determines how often the wielder can swing the weapon during a certain period of time. The lower the faster, <weapon speed> 1 is best (that is lightning- fast). A typical average value is 8. Speed and damage should be kept in reasonable relation. The weapon class value adds to the overall weapon class of the wielder's melee attacks. Weapon class improves the chance of hitting the opponent. For a weapon, magic bonus works just like weapon class, except that magic bonus can be improved by the gods or reduced by acid. Hence, it is less useful than direct weapon class value on a weapon. The <item power> value measures how "powerful" an artifact is. Players will only be able to wear equipment with a certain total amount of <item power>, depending on their own level. This is the only way to prevent low level players to wear "undeserved" equipment (like gifts from other players or cheated items). It is very important to adjust the <item power> value carefully for every artifact you create! If zero/unset, the CF server will calculate a provisional value at runtime, but this is never going to be an accurate measurement of <item power>. A damned weapon cannot be unwielded unless the curse is removed. Removing damnations is a tick harder than removing curses. A cursed weapon cannot be unwielded unless the curse is removed. An item with this flag enabled will save the players life for one time: When the player is wearing this item and his health points reach zero, the item disappears, replenishing half of the player's health. An item with <save life> should not have any decent additional bonuses! Unique items exist only one time on a server. If the item is taken, lost or destroyed - it's gone for good. A godgiven item vanishes as soon as the player drops it to the ground. &player_stat_resist_sections;

With positive luck bonus, the player is more likely to succeed in all sorts of things (spellcasting, praying,...). Unless the <luck bonus> is very high, the effect will be barely visible in-game. Luck bonus on one piece of equipment should never exceed 3, and such bonus should not be too frequently available. Positive <health regen.> bonus speeds up the player's healing process. Negative values slow it down. Positive <mana regen.> bonus speeds up the player's mana regeneration. Negative values slow it down. Positive <grace regen.> bonus speeds up the player's grace regeneration. Negative values slow it down. Since grace can be regenerated rather easy with praying, additional <grace regen.> bonus should be VERY RARE!! Positive <food bonus> slows down the player's digestion, thus he consumes less food. Negative values speed it up. Note that food is consumed not only for "being alive", but also for healing and mana-regeneration. <food bonus> only affects the amount of food consumed for "being alive". Hence, even with high <food bonus>, during a fight a player can run out of food quickly. Xray vision allows the player to see through obstacles in a two-square-wide radius. This is extremely helpful and desirable, so don't give it away for cheap on equipment. Stealth allows the player to move silently. This comes to effect if a player turns himself invisible and tries to sneak around monsters. (At least that was the idea behind it) If a player is wearing any piece of equipment with the ability to <reflect spells>, all kinds of spell-bullets and -beams will bounce off him. This works only about 90% of all times, to avoid players being completely immune to certain types of attacks. This is a very powerful ability and it shouldn't be handed out cheap! If a player is wearing any piece of equipment with the ability to <reflect missiles>, all kinds of projectiles (e.g. arrows, bolts, boulders) will bounce off him. This works only about 90% of all times, to avoid players being completely immune to certain types of attacks. Click on the <attuned paths> button to select spellpaths. The player will get attuned to the specified spellpaths while wearing this weapon. Click on the <repelled paths> button to select spellpaths. The player will get repelled to the specified spellpaths while wearing this weapon. Click on the <denied paths> button to select spellpaths. The specified spellpaths will be denied to the player while wearing this weapon.

This text describes the weapons's "story". Every decent artifact weapon should have such a description. The type of event that triggers a notify to the plug-in. The name of the plug-in that should be notified of the event, e.g. "cfpython" for python and "perl" for the Crossfire-Perl plug-in. The name of the extension to invoke (for python, this is the path to a script, for perl this is the name of a extension package without the ".ext" extension. A string that is passed unaltered to the extension above. Often used to pass options to the extension that alter its behaviour.