• This content was extracted from source code and may not be up-to-date.
  • SVN Revision 8051; 2007-12-27 18:17:01 -0600 (Thu, 27 Dec 2007)

• Wiki
  • Types (type) & Subtypes (subtype)
• SVN
  • If you have a copy of the source, the define.h file can be found in server/include/define.h, or
  • server/include/define.h

List of object types, their attributes and functionality

Type 0 means: The object has no special functionality. This usually applies for walls, floors and monsters.

• “is_floor 1” marks the object as floor. Any objects below will be invisible to the player. Never use a partly transparent pic for an object with is_floor! Every square visible to the player should contain a floor. Don't forget to put floors below walls and monsters!
• “no_pick 1” should be set for all floors. Prevents the player from picking the floor up.
• “unique 1”: If this attribute is set to a floor tile, this square is treated as a “unique map”. That means this part of the map doesn't get reset like normal maps. Thus, when a player drops items to this square, they'll stay there forever, unless picked up again.

All the unique and permanent apartments have this flag set to every floor tile.

• “blocksview 1” makes the wall blocking a player's view. Keep in mind that the player might still be able to look behind it with xrays. If necessary, make the wall two squares wide for perfect blocking view. It is very bad style when a player can see map-mechanisms with xray. If using a wall with “blocksview 0” (like fence/gates), be aware that the player can jump through it via dimension door. You must set “no_magic 1” and “damned 1” to prevent this.
• “no_pass 1” makes the wall non-passable. The player cannot walk through. You can create a secret passage by setting “no_pass 0” (and “no_pick 1”). Remember to put a hint somewhere so the player can find that spot! A huge room with a secret passage and no hint, that SUUUCKS.
• “tear_down 1”, “alive 1”, “hp/maxhp/level > 0” and some animation: This creates another form of secret passage - The break-away-walls.

• “alive 1” and “monster 1” turns an object into a basic monster: It blocks the way, (per default) attacks the player and usually it can be killed.
• “unaggressive 1” makes the monster stand still, not attacking the player until being attacked first. Should not be used for NPCs since the chance for accidentally killing an unaggressive creature is rather high.
• “friendly 1” should be used for all NPCs. When set to peaceful mode, a player won't attack such an NPC but push him instead. However, it is still possible to kill it. If your NPC plays a very important role in a quest, it might be useful to set immunity to all attacktypes (see “resist_<attacktype> <number>”).
• “Pow <number>”: If the creature can cast spells, this is how many spell points are regenerated each move.
• “Con <number>”: Monsters regenerate this many hit points each move. This is each time the monster has a move (same for Pow). So two monsters with the same Con can regenerate at different rates if their speeds are different.
• “Wis <number>”: 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 wisdom is 11, any player that moves within the 11×11 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.
• “hp > 0”: The monster's hitpoints
• “maxhp > 0”: The monsters maximum hitpoints (very important since most monsters regenerate hp fast).
• “resist_<attacktype> <number>” rises the monster's resistance from <attacktype> by <number> percent. 100 means perfect immunity. When set to -100, the monster will receive double damage from this attacktype.
• “attacktype <number>”: the bitmask <number> determines the monster's attacktypes. Attacktypes are: physical, magical, fire, cold.. etc. Read the details about attacktypes here.
• “exp <value>” defines the amount of experience a player will get for killing the monster. You should be very careful with setting exp values. Take a good look at existing arches and try to adopt the “overall power/exp”-ratio of monsters. Note that non-spellcasting monsters in general are *much* easier to kill, thus deserve lower exp.

Functionality of rods:
A rod contains a spell. The player can use this spell by applying and firing the rod. Rods need time to regenerate their “internal” spellpoints, lowering the effectiveness in combat. But unlike wands/scrolls, rods can be used endlessly.

• “sp <spellnumber>” sets the spell of the rod. A list of all spellnumbers can be viewed FIXME: here. 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!
• “level <number>” is the casting level for the spell of that rod. For attack spells, level should be set to something reasonable.
• “hp <number>” is the initial amount of spellpoints in the rod.
• “maxhp <number>”: <number> is the maximum amount of spellpoints the rod can hold. Make sure it is enough to cast the contained spell at least once. But don't set the value too high, that would make the rod too effective.

see also: type 35: horn (35), type 109: wand / staff (109)

Functionality of treasure:
A treasure-object turns into certain randomitems when the map is loaded into the game.

• “randomitems <treasurelist>” determines what kind of treasure will appear. Look into /crossfire/share/crossfire/treasures for details about existing treasurelists.
• “auto_apply 1” 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 set “auto_apply 0”. That way, the player has to apply the object (the chest), then the treasure is generated.
• “hp <number>”: <number> 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. (Setting “nrof” for treasure - objects doesn't have any effect!)

About usage of the random-artifact treasurelist:
This will generate powerful stuff like girdles, xray helmets, special swords etc. If you put this as reward to your quest, players might be motivated to do it more than once. BUT, by doing so they will get a huge number of different artifacts! Besides, players will always seek the place with the most easy-to-get random artifact and ignore all others. My advice: Don't use it! Attract players with good fighting experience (from monsters), potions, spellbooks, money, and non-random artifacts.

Functionality of potions:
The player can drink these and gain various kinds of benefits (/penalties) by doing so.

• “level <number>”: If the potion contains a spell, the spell is cast at level <number>. For other potions it should be set at least to 1.
• “cursed 1” generally turns benefits into penalties (see below). 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 >:)
• “Str/Dex/Con/Int/Wis/Pow/Cha <num>” makes a stat-potion. The player's stat will rise/fall by value <num> for permanent (of course there is an upper limit). Generally there shouldn't be stat potions granting more than one stat. Cursed potions will subtract the stats if positive.
• “resist_<attacktype> <number>” makes a resistance potion. Resistance from <attacktype> by <number> percent. The effect is only temporary, and it does NOT add on the values from the player's equipment. Cursed potions will make negative resistance.. very nasty in combat!
• “sp <spellnum>”: When a player drinks this potion, the spell of number <spellnum> will be casted (once). This should work for any given spell. Look for spellnumbers here. E.g. heal is “sp 35”, magic power is “sp 67”.
• “attacktype 1048576” makes an improvement potion. (I know, using attacktype for this is very ugly, bleah!!) If your potion is NOT supposed to be an improvement potion, leave attacktype zero.

Functionality of food:
By eating/drinking food-objects, the player can fill his stomach and gain a little health.

• “food <number>”: The player's stomach will get filled with <number> of foodpoints. The player's health will increase by <number>/50 hp.

see also: type 72: flesh

Functionality of poison food:
When eating, the player's stomach is drained by 1/4 of food. If his food drops to zero, the player might even die.

Functionality of books:
Applying a book, the containing message is displayed to the player.

• “msg <text> endmsg”: <text> is the text “written” in the book.
• “level <number>”: If <number> is greater zero, the player needs a certain literacy level to succeed reading the book. The book can be read if: mental_level greater <number> - 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.

see also: type 85: spellbook , type 98: sign / magic mouth , type 111: scroll

Functionality of clocks:
Applying a clock, the time is displayed to the player

Functionality of arrows/bolts:
Arrows can be shot with bows, bolts with crossbows. They are usually weaker than melee but players can shoot from a safe distance.

• “race <name>” should be set to either “race arrows” or “race crossbow bolts”. If not, they won't work with bows/crossbows.
• “dam <number>” is the damage the projectile can inflict.
• “wc <number>”: weapon-class bonus
• “attacktype <attack_num>”: the bitmask <attack_num> determines the weapon's attacktypes. Read a more detailed description about attacktypes here.
• “food <number>” is the percentage chance of the projectile to break after hitting. “food 0” means it won't ever break, “food 100” means it will always break at first hit.

Functionality of Shooting Weapons:
Bows can fire arrows, crossbows can fire bolts. You could also create your own pair of projectile & shooting weapon. When the “race”-attribute of both matches, it should work.

• “race <name>” should be set to either “race arrows” or “race crossbow bolts”. If not, they won't work with bows/crossbows.
• “sp <number>”: After shooting a projectile, the player is frozen for a short period of time (to prevent shooting arrows machine-gun-like). The greater <number>, the shorter this period of time. “sp 1” means the player is frozen for a looong time. “sp 0” means the player is turned to stone forever. Nice, hum? =P

see also: type 15: weapon

Functionality of weapons:
Wielding a weapon, the object's stats will directly be inherited to the player. Usually enhancing his fighting-abilities. Non-magical weapons can be improved with scrolls.

• “dam <number>” is the damage this weapon does per hit. <number> will add to the base damage of the player.
• “attacktype <attack_num>”: the bitmask <attack_num> determines the weapon's attacktypes. Attacktypes are: physical, magical, fire, cold.. etc. Read a more detailed description about attacktypes here. Most artifact weapons have no more than one or two attacktypes. Keep in mind that all weapons can be blessed by the player's deity, 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.
• “resist_<attacktype> <number>” adds resistance to the weapon. Resistance from <attacktype> by <number> percent. Treat this with CARE. Look at other maps and what they require to do for getting this-and-that artifact.
• “Str/Dex/Con/Int/Wis/Pow/Cha <number>”: The wielder's stat(s) will rise/fall by value <number> for permanent. Again, don't mess around with this! Stats-bonus is very powerful. (Stat bonus does not mark a weapon being “magical”)
• “slaying <race>”: The weapon does triple damage to monsters of this <race> category. On the other hand, no god blessings are possible for such weapons.
• “last_sp <number>” determines the weapon-speed. The lower the faster, “last_sp 1” is best (that is lightning- fast). A typical average value is 8. Speed and damage should be kept in reasonable relation.
• “path_attuned/repelled/denied <spellpath>”: This modifies the player's attunement to certain spellpaths. Attunes are more a matter of rings/amulets, while repels/denies are quite common. Remember that weapons are in general the barbarians' tools, not the wizards'. Read the details about spellpaths here.
• “wc <number>”: weapon-class bonus
• “magical <number>” sets the weapon's magic bonus. It works just like wc, except that magic bonus can be improved by the gods or reduced by acid. Hence, it is less useful than direct wc on a weapon.

General notes on artifacts (equipment) with stats- or resistance-bonus:
Keep playbalance in mind! Such items mustn't be reachable without hard fighting AND questing. See “golden rules of map-making”.

Functionality of mail / breastplate armour:
Wearing an armour, the object's stats will directly be inherited to the player. Usually enhancing his defense.

• “resist_<attacktype> <number>” adds resistance to the armour. Resistance from <attacktype> by <number> percent. “physical protection” (= armour) is referred to as resist_physical.
• “Str/Dex/Con/Int/Wis/Pow/Cha <number>”: The wielder's stat(s) will rise/fall by value <number> for permanent.
• “path_attuned/repelled/denied <spellpath>”: This modifies the player's attunement to certain spellpaths.
• “last_heal <number>” poses a penalty to spell regeneration speed, for wearing the armour. The bigger <number>, the worse.
• “last_sp <number>” reduces the player's walking speed when wearing the armour. The bigger <number>, the worse.
• “sp <number>” speeds up the players mana-regen. rate by <number>. (negative values reduce mana-regen).
• “ac <number>”: armour-class bonus
• “magical <number>” sets the armour's magic bonus. It works just like ac, except that magic bonus can be improved by “scrolls of Enchant Armour” or reduced by acid. It is less useful than direct ac on the armour.
• “xrays 1” enables xray-vision for the player, while wearing this armour.

see also: type 33: shield , type 34: helmet , type 39: amulet , type 70: ring , type 87: cloak , type 99: boots , type 100: gloves , type 104: bracers , type 113: girdle

These all work more or less exactly like breastplate armour.

Functionality of pedestals:
Pedestals are designed to detect certain types of living objects. When a predefined type of living creature steps on the pedestal, the connected value is triggered.

• “slaying <race_type>” specifies the object we're looking for. If <race_type> 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 “slaying player” is set, any player stepping on the pedestal is a match. Very useful if you want to open a gate for players but not for monsters.
• “connected <connector_value>” defines the connector value to be activated when the pedestal is triggered.
• “walk_on 1”, “walk_off 1” should both be set or it won't work.

Notes on usage:
If you want to create a place where only players of a certain race can enter, put a type 41: teleporter over your pedestal. So the teleporter is only activated for players of the matching race. Do not use gates, because many other players could sneak in. If you put powerful artifacts into such places, generally set “startequip 1”, so that they are preserved for that one race and can't be traded to others.

see also: type 51: detectors , type 64: inventory checker , type 18: altar

Functionality of altars:
When a player puts a defined number of certain items on the altar, then either a spell is casted (on the player) or a connector is triggered. If the latter is the case, the altar works only once. Either way, the sacrificed item dissapears.

• “slaying <item_name>” specifies the item that must be put on the altar to activate it. <item_name> 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”)
• “food <value>” is the amount of items (specified as above) that must be dropped to activate the altar. If “slaying money” is set, then the value of the sacrificed money must be equal to <value> (ie, if food=200, then 200 silver, 20 gold, or 4 platinum will all work.) Note that the maximum possible for <value> is 32767.
• “walk_on 1” must be set or it won't work.
• “connected <activate_num>”: If <activate_num> is set, the altar will trigger all objects connected to it, when activated. This will only work once.
• “sp <spell_number>”: When activated, the spell of number <spellnum> will be casted (once, on the player). This should work for any given spell. Look for spellnumbers here. The altar will work infinitely in this way. Don't set both “sp > 0” and “connected > 0” for one altar.

see also: type 31: altar_trigger , type 56: holy altar

Functionality of locked doors:
A locked door can be opened only when carrying the appropriate type 21: special key.

• “slaying <unique_string>” must be identical with the slaying in the special key, then door is unlocked. It is VERY important to set <unique_string> to something that is unique among the CF mapset. DONT EVER USE the default string “set_individual_value”.
• “msg <text> endmsg”: When a player is trying to open the door without carrying the appropriate key, <text> is displayed to the player. This is a good opportunity to place hints about the special key needed to unlock the door.
• “no_magic 1”, “damned 1” should always be set to prevent players passing through the door by dimension door spell.

Notes on usage:
If you want to create a locked door that cannot be opened (no key), set a slaying like “no_key_available”. This will clarify things and only a fool would create a key matching that slaying. Door-objects can not only be used for “doors”. In many maps these are used with all kinds of faces/names, especially often as “magic force”. A good example is the map “Lake_Country/ebony/masterlev”. There you have magic forces (door objects) put under certain artifact items. To get your hands on the artifacts, you need to bring up the appropriate quest items (key objects).

see also: type 21: special key

Functionality of special keys:
When carrying the appropriate special key, a locked door can be opened. The key will disappear. This object-type can also be used for “passport”-like items: When walking onto an inventory checker, a gate for example might get opened. The “passport” will stay in the player's inventory.

• “slaying <unique_string>” must be identical with the slaying in the locked door, then it can be unlocked. It can also be used to trigger inventory checkers.
• “material 0” (no material) or “material 256” (adamantite) should be set. This prevents the key from getting burned or otherwise destroyed.
• “msg <text> endmsg”: This will add a description to the object. The player can read <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.

Notes on usage:
How to make a “passport”: You take the special key arch (archetype name is “key2”), set the face to something like card.111 and the name to “passport” - that's all. The slaying certainly must match with the appropriate inventory checker.

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”.

see also: type 20: locked door , type 64: inventory checker

Functionality of magic_ears:
Magic_ears trigger a connected value when the player speaks a specific keyword.

• “msg <text> endmsg” contains the keyword-matching-syntax. <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 triggered when the player speaks any of the given keywords. IMPORTANT: Upper/lower case does not make a difference!
• “invisible 1” should always be set for magic_ears. They cannot be discovered by the show invisible spell, so it doesn't matter if you put them above or below the floor.

Notes on usage:
Whenever you put magic_ears on your maps, make sure there are CLEAR and RELIABLE hints about the keywords somewhere. Don't make something like a gate that is opened by speaking “open” or “sesame”, expecting the player to figure this out all by himself.

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.

Functionality of altar_triggers:
Altar_triggers work pretty much like normal altars (drop sacrifice → connection activated), except for the fact that they reset after usage. Hence, altar_triggers can be used infinitely.

• “slaying <item_name>” specifies the item that must be put on the altar to activate it. <item_name> 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”)
• “food <value>” is the amount of items (specified as above) that must be dropped to activate the altar.

If “slaying money” is set, then the value of the sacrificed money must be equal to <value> (ie, if food=200, then 200 silver, 20 gold, or 4 platinum will all work.) Note that the maximum possible for <value> is 32767.

• “walk_on 1” must be set or it won't work.
• “connected <activate_num>”: If <activate_num> is set, the altar will trigger all objects connected to it, when activated. (With “last_sp 0”, it triggers again when the altar is reset.)
• “last_sp 1”: If set, 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 “last_sp 0” is set (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.

Hints on usage:
Altar_triggers are very useful if you want to charge a price for…

• …an item. → Connect the altar_trigger (set “last_sp 1”) to a creator. See also: converters.
• …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.

see also: type 18: altar

see also: type 3: rod

Functionality of movers:
Movers move the objects above them. However, only living objects are affected (monsters/NPCs always, players optional). Movers have a direction, so players can be made to move in a pattern, and so can monsters. Motion is involuntary. Additionally, players or monsters can be “frozen” while ontop of movers so that they MUST move along a chain of them.

Multisquare monsters can be moved as well, given enough space. Movers are usually invisible.

• “attacktype 1”: If attacktype is nonzero, the mover “freezes” anyone it moves (so they are forced to move along a chain). However, this has nothing to do with the common in-game attacktypes. Default is “attacktype 1”.
• “maxsp <number>”: The player will be “frozen” for <number> moves. If unset, and “attacktype 1”, maxsp becomes 2. Otherwise it is zero by default.
• “walk_on 1” must be set or it won't work properly.
• “fly_on 1” means all flying (living) objects will get moved as well. A mover with “fly_on 0” will move only walking (non-flying) creatures.
• “speed <speed_value>” determines how fast a chain of these movers will push a player along (default -0.2).
• “sp <number>” specifies the mover's direction. 1=up, 3=right, 5=down, 7=left. A mover with “sp 8” will spin clockwise.
• “level 1”: If this is set, both players and monsters will be moved. The arches' default is “level 0”, 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.
• “lifesave 1” means the mover can be “used up” after a certain number of moves (→ hp). A mover of “lifesave 0” works infinitely. (I know this is opposite to the common sense of “lifesave”, but we gotta accept it)
• “hp <value>” has only a meaning if lifesave is set: <value> is the number of times minus one, that it will move a player before disappearing. (It will move someone <value>+1 times, then vanish).

Notes on usage:
NEVER EVER consider a mover to be impassable in the backwards direction. Setting “attacktype 1” makes it seemingly impossible but there is still a trick: One player can push a second player past the mover, in opposite to the mover's direction! The more movers, the more players needed. Hence, don't make a treasure room that is surrounded by movers instead of solid walls/gates. It should be noted though that this behavior can be used for intentionally multi-player maps, and there is one such example in Pupland , however it should be noted that forcing players to use that to get through would usually be considered a bit too counter-intuitive unless it is hinted to.

Btw, it does not make a difference putting movers above or below the floor. Moreover, movers that are “invisible 1” cannot be discovered with the show_invisible spell.

Note on directors:
Movers and Directors are separate 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).

see also: type 112: director

Functionality of teleporters:
When the player walks into a teleporter, he is transferred to a different location. The main difference to the object-type type 66: exit is the possibility to have teleporters connected to levers/buttons/etc. Sometimes teleporters are activated even against the players will.

Unlike exits, teleporters can transfer also items and monsters to different locations on the same map.

• “slaying <map_path>” defines the map that the player is transferred to. <map_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 slaying is set, ONLY players can get teleported. If slaying is unset (“slaying 0”), anything can get teleported: Players, monsters and items. In this case, the destined map is automatically the same map the teleporter is on.
• “hp <number>”, “sp <number>”: hp, sp define the (x, y)- coordinates of the exit's destination. If both are set to zero and “slaying 0” is set, 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 (sp,hp) are zero but slaying is set, the player will be transferred to the “default enter location” of the destined map. The latter can be set in the map's attributes as “hp”/“sp”, with crossedit there are input masks labeled “Start X”/“Start Y”. Though, please DO NOT use that. I wrote it here only so that you understand some existing maps. It turned out to be a source for numerous map-bugs.
• “speed <speed_value>”: If 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 <speed_value>. Default in the teleporter arch is “speed 0.1”. VERY IMPORTANT: If you want to have your teleporter activated via button/handle/magic_ear/etc, you must set “speed 0”!
• “connected <connector_value>”: If set, the teleporter will be activated when the connection is triggered. As stated above, to use this, speed must be zero.

Notes on usage:
Teleporters must always be placed above the floor in order to work correctly!

When creating maps, I guess sooner or later you'll want to have an invisible teleporter. If using “invisible 1”, the teleporter can still be discovered with the show_invisible spell. And you can't place it under the floor to prevent this. 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.

see also: type 66: exit

Functionality of creators:
A creator is an object which creates another object when it is triggered. The child object can be anything. Creators are VERY useful for all kinds of map-mechanisms.

• “other_arch <arch_name>” defines the object that will be created. You can choose any of the existing arches.
• “connected <connector_value>”: If <connector_value> is activated, the creator is triggered.
• “hp <number>”: The creator can be triggered <number> times, thus creating <number> objects, before it disappears. Default is “hp 1” (→ one-time usage).
• “lifesave 1” means the creator will work infinitely, regardless of hp.
• “slaying <name>”: The created object will bear the name <name>. If no slaying is set, the standard name of the archetype is used.
• “level <number>: The created object will be of level <number>. Again, if not set, the standard level of the archetype is used.

Notes on usage:
Don't hesitate to hide your creators under the floor. The created items will still always appear ontop of the floor.

see also: type 154: rune / trap

Functionality of detectors:
Detectors work quite much like inv. checkers/pedestals: If the detector finds a specific object, it toggles its connected value.

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.

• “slaying <name>” specifies the name of the object we are looking for. Actually it does also check for slayings in key-objects, but for this case inv. checkers are often more powerful to use.
• “speed <speed_value>” sets the time between two detector-checks. If you want the detector to behave almost like pedestals/buttons, set speed rather high, like “speed 1.0”.

Notes on usage:
There is one major specialty about detectors: You can detect spells blown over a detector! To detect a lightning bolt for example, set “slaying lightning” and “speed 1.0”. In combination with spellcasting walls, this can be very useful for map-mechanisms.

see also: type 17: pedestal , type 64: inventory checker , type 18: altar

Functionality of markers:
A marker is an object that inserts an invisible force (a mark) into a player stepping on it. This force does nothing except contain a string in its slaying field which can be discovered by detectors or inv. checkers. It is also possible to use markers for removing marks again. Note that the player has no possibility to “see” his own marks, except by the effect that they cause on the maps.

• “slaying <unique_string>” is the “lockcode” that can be detected by inv. checkers/detectors. If the player already has a force with that slaying, there won't be inserted a second one.
• “speed <speed_value>” defines how quickly it will mark something standing on the marker. Set <speed_value> rather high to make sure the player really gets his mark. I think “speed 1.0” should do fine.
• “food <number>” sets the duration of the force it inserts. If nonzero, the duration of the player's mark is finite: about 1 food per 10 seconds. “food 0” means the mark will stay on the player forever.
• “name <unique_string>”: When the player steps onto the marker, all existing forces in the players inv. with slaying <unique_string> will be removed. If you don't want to remove any marks, simply name your object “marker”. I know, involving an object's name in it's functionalities is rather uncommon and irritating… but hey, we gotta deal with it.
• “msg <text> endmsg”: In the moment when the player gets marked, the message <text> is displayed to him. You should usually set a message in any marker you create, because it's the only way for the player to notice what's going on.

Notes on usage:
Markers hold real cool possibilities for map-making. I encourage you to use them frequently. However there is one negative point about markers: Players don't “see” what's going on with them. It is your task, as map-creator, to make sure the player is always well informed and never confused.

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.

see also: type 64: inventory checker

Functionality of holy_altars:
Holy_altars are altars for the various religions. Praying at a holy_altar will make you a follower of that god, and if you already follow that god, you may get some extra bonus. (See: god intervention)

• “other_arch <god_name>” specifies the God that the altar belongs to. 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 “other_arch 0” and “level 0”.
• “level <number>”: To re-consecrate an altar, the players skill level (wisdom level) must be as high or higher than the level field. In this 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 “level 100”. Some characters might need those altars, they would be very unhappy to see them re-consecrated to another cult.

see also: type 18: altar

An object owned by a player that can convert a monster into a peaceful being incapable of attack. This item type is the basis by which the peace spell functions. If the attack succeeds, the victim becomes unaggressive, will run away, assumes random movement, and is no longer considered a monster. All the creature's experience is transferred to the owner of the peacemaker.

Functionality of magic walls:
Magic walls fire spells in a given direction, in regular intervals. Magic walls can contain any spell. However, some spells do not operate very successfully in them. The only way to know is to test the spell you want to use with a wall.

Several types of magical walls are predefined for you in the archetypes, and can be found on a pick-map available in crossedit .

• “dam <spellnumber>” specifies the spell the wall will cast. You can find a list of spellnumbers here.
• “level <number>”: The wall will cast it's spells at level <number>. “level 1” walls cast spells at minimal strength. “level 100” walls cast deadly spells. Arch default is level 1 - you should rise it to meet the overall difficulty of your map.
• “sp <number>” holds the direction in which the wall will cast the spell. 1=north, 2=northeast, 3=east,… , 8=northwest. A magic wall with “sp 0” will always fire in a random direction.
• “speed <speed_value>” 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”.
• “connected <connector_value>” means the wall will cast a spell when it is triggered via <connector_value>. Set “speed 0” or it won't have much visible effect.
• “no_pass 1”, “blocksview 1” should be set for “normal” wall-behavior: blocking view and non-passable. Yet, this is not a rule written in stone. You could make invisible, passable magic walls… the spells will then seemingly appear out of nowhere.
• “alive 1” means the wall can be attacked and destroyed. If set, you must also set the common monster-attributes: hp, maxhp, resistances. See description of monsters.

Notes on usage:
Spellcasting walls pose an interesting alternative to monsters. Usually they are set to be non-destroyable (“alive 0”). Thus, while monsters in a map can be cleared out, the magic walls remain. Low level characters for example will not be able to pass through their spell-area, hence they cannot loot a map that a high level character might have cleared out.

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“.

Functionality of inventory checkers:
Inventory checkers passively check the players inventory for a specific object. You can set a connected value that is triggered either if that object is present or missing (→ “last_sp”) when a player walks over the inv. checker. A valid option is to remove the matching object (usually not recommended, see “last_heal”).

Alternatively, you can set your inv. checker to block all players that do/don't carry the matching object (→ “no_pass”). As you can see, inv. checkers are quite powerful, holding a great variety of possibilities.

• “slaying <name>” specifies the object we are looking for: We have a match if the player does/don't carry a key object or a mark (→ see marker) with identical slaying <name>. Note that key objects usually appear as “passports” in this context. A typical example is the city gate mechanism of scorn.
• “race <archetype_name>” specifies the object we are looking for: We have a match if the player does/don't carry an object of archetype <archetype_name>.
• “hp <type_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 <type_value>. Example: Set “hp 15” (type 15 => weapon) and “no_pass 1”. 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. Nice, hum? :)
• “last_heal 1”: Remove object if found. 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 set last_heal, make sure to inform the player what's going on!

• “no_pass 1”: If set, only players meeting the match criteria can pass through that space. If “no_pass 0” (default), then the inv. checker acts like a trigger/button.
• “last_sp 1” means having that object is a match. “last_sp 0” means not having that object is a match.
• “connected <connector_value>” specifies the connector value to be activated if the inv. checker is triggered. This only makes sense along with “no_pass 0”.

General usage notes:
Putting a check_inventory space in front of a gate (one below) and one on the opposite side works reasonably well as a control mechanism. Unlike the key/door-combo, this one works infinite since it is independent from map reset. Use it to put a “structure” into your maps: Player must solve area A to gain access to area B. This concept can be found in nearly every RPG - simple but effective.

see also: type 21: special key , type 55: marker , type 17: pedestal , type 51: detector

Functionality of mood floors:
As the name implies, mood floors can change the “mood” of a monsters/NPC. For example, an unaggressive monster could be turned mad to start attacking. Similar, an aggressive monster could be calmed.

• “last_sp <number>” is used to determine what will happen to the monster when affected by the mood floor:
  • “last_sp 0”: 'furious' Makes all monsters aggressive
  • “last_sp 1”: 'angry' As above but pets are unaffected
  • “last_sp 2”: 'calm' Makes all monsters unaggressive
  • “last_sp 3”: 'sleep' Puts all monsters to sleep
  • “last_sp 4”: 'charm' Makes monster into a pet of person who triggers the square. This setting is not enabled for continuous operation, you need to insert a connected value!
• “connected <connector_value>”: This should only be set in combination with “last_sp 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!

Notes on usage:
Notes on usage: Mood floors are absolutely cool for NPC interaction. To make an unaggressive monster/NPC attack, put a creator with “other_arch furious_floor” under it. Connect the creator to a magic_ear, so the player speaks a keyword like “stupid sucker” - and the monster 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.)

Functionality of exits:
When the player applies an exit, he is transferred to a different location. (Monsters cannot use exits.) Depending on how it is set, the player applies the exit just by walking into it, or by pressing <a>pply when standing on the exit.

• “slaying <map_path>” defines the map that the player is transferred to. <map_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. 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”.
• “hp <number>”, “sp <number>”: hp, sp define the (x, y)- coordinates of the exit's destination. 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's attributes as “hp”/“sp”, with crossedit there are input masks labeled “Start X”/“Start Y”. Though, please DO NOT use that. I wrote it here only so that you understand some existing maps. It turned out to be a source for numerous map-bugs.
• “walk_on 1”: If set, the player will apply the exit by just walking into it. This must be set for the invisible exits for example. If “walk_on 0”, the player has to step onto the exit and press <a> to get transferred.
• “fly_on 1”: If set, the player will apply the exit by “flying into it”. Flying means the player is levitating. E.g. he might wear the levitation boots.
• “msg <text> endmsg”: If set, <text> 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 got the point.
• “unique 1” defines the destined map as “personal unique map”. That means there will be a separate version of that map for every player out there. This feature is used for the permanent apartments (in Scorn/Nuernberg/Caterham…). It should not be used for anything else than apartments, since Crossfire is a *multi*player game. In such a permanent apartment don't forget to set “unique 1” for all floor tiles too (see floors). An exit pointing outside of a “personal unique map” must be “unique 0”.

Notes on usage:
If you want to have an invisible exit, set “invisible 1” (, of course “walk_on 1”), and put it *under* the floor. Otherwise it could be detected with the show_invisible spell.

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.

see also: type 41: teleporter

se also type 6: food

Functionality of spellbooks:
By reading a spellbook, the player has a chance of learning the contained spell. Once learned from a book, the spell is available forever. Spellbooks with high level spells require some skill-level to read.

• “sp <spellnum>” defines the contained spell. You can look up the spellnumbers here. You could alternatively use the slaying.
• “slaying <spell_name>” also defines the contained spell, just like sp, but here you write the spell's name instead of it's number. Saves you the hassle to look it up, and makes your stuff more readable to others.
• “msg <text> endmsg” could contain a nice description of the spellbook's cover or something.

Notes on usage:
Don't put any of the godgiven spells into a spellbook! These are reserved for the followers of the appropriate cults. Handing them out in a spellbook would violate the balance between different religions.

If you want to have a random spellbook, you must use the type 4: treasure arch “random_spells” instead.

see also: type 8: book

Holes send objects that fall through them to a new location on the current map.

• The destination after falling through the hole is random.
• Become “full” (Can stop working) if destination is blocked.
• May be opened and closed via connection.
• Monsters, spells, etc. can fall through.
• Can trigger on all movement types.

Examples

• connect/Hole/pit.arc|pit.arc

Special Object Attributes

Functionality of signs / magic_mouths:
The purpose of a sign or magic_mouth is to display a certain message to the player. There are three ways to have the player get this message: The player walking onto it (→ magic_mouth), the player pressing <a>pply (→ sign) or the player triggering a button/handle/etc (→ magic_mouth).

• “msg <text> endmsg” contains the <text> that will be displayed to the player.
• “invisible 1” should always be set if you want to have the object work as magic_mouth. Put magic_mouths *under* the floor, to prevent them being affected by the show_invisible spell. If you want to have a sign, set “invisible 0”. That way the player can see the object, thus apply it, and get the message.
• “walk_on 1”: If set, the player gets the message when walking on top of the object. “invisible 1” should be set in this case. This is the typical configuration for a “magic_mouth”: The player walks through a dungeon and suddenly he gets a message. Use this to create some roleplay atmosphere, and to inform the player about possible dangers or secrets.
• “fly_on 1”: If set, the player gets the message when flying (=levitating) ontop of the object. Usually this should be set together with walk_on.
• “connected <connector_number>” means the message will be printed when the object is triggered via <connector_value>. This should be used in combination with “invisible 1” and “walk/fly_on 0”. If activating your magic_mouth this way, the message will not only be printed to one player, but all players on the current map!
• “food <number>”: If “food” is set, the sign/magic_mouth can be applied (printing the message) only <number> times. For signs this really shouldn't be used, while for magic_mouths it is extremely helpful. 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. “food 1” does a perfect job in such cases. Otherwise set “food 0” for infinite use (that is the default).

Notes on usage:
Use signs and magic_mouths, plenty of them! Place magic_mouths to add some true roleplay feeling to your maps, support your storyline or give hints about hidden secrets/dangers. Place signs to provide the player with all kinds of useful information for getting along in your maps.

see also: type 8: book

Functionality of converters:
Converters are like “exchange tables”. When the player drops a specific type of items, they get converted into other items, at a predefined exchange-ratio.

• “slaying <give_item>”: <give_item> is the name of the archetype to convert from.
• “other_arch <get_item>”: <get_item> is the name of the archetype to convert into.
• “sp <sp_value>”, “food <food_value>” defines the exchange-ratio: For <food_value> pieces of <give_item> the player will get <sp_value> pieces of <get_item>.
• “walk_on 1” and “no_pick 1” must always be set for converters.

Notes on usage:
Converters are better than shopping with doormats, because the converters never get sold out. For some items like food or jewels those “exchange tables” are really nice, while for the more important stuff like potions converters should not exist.

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 dragon-scales for payment). The code will not check if your ratio is sane, so the player could gain infinite wealth by using your converter.

See also: type 42: creator

Functionality of savebeds:
When the player applies a savebed, he is not only saved. Both his respawn-after-death and his word-of-recall positions are pointing to the last-applied savebed.

• “no_pick 1” makes sure the savebed is non-pickable. DO NOT CHANGE THIS!
• “no_magic 1”, “damned 1” marks the savebed as no-spell-area. Again, DO NOT CHANGE THIS. Sometimes players die in auto fire mode…

Notes on usage:
Put savebed locations in towns, do not put them into dungeons. It is absolutely necessary that a place with savebeds is 100% secure. That means:

• Monsters must not be able to reach the savebeds under any circumstances!
• If there are NPCs around, make sure they have “friendly 1” set.
• Insert a reliable 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.

Functionality of wands / staves:
Wands contain a certain spell. The player can apply (ready) and fire the wand. After a defined number of casts, the wand is “used up”. It is possible to recharge a wand with scrolls of charging, but usually that isn't worth the cost.

• “sp <spellnum>” specifies the contained spell. You can look up the spellnumbers here.
• “level <number>”: The wand/staff will cast at level <number>. An average level for wands in shops is about 10.
• “food <number>” is the number of charges left before it is used up.

Notes on usage: Wands are quite seldom used. The reason probably is that they're generally not cost-efficient. Handing out high-level wands with powerful special spells isn't a good idea either, because of the recharge ability.

For low levels, staffs of healing/cure and word of recall are quite desirable though.

see also: type 3: rod , type 5: potion , type 111: scroll

see also: type 3: rod , type 5: potion , type 109: wand / staff

Functionality of containers: A player can put (certain kinds of) items in the container. The overall weight of items is reduced when put inside a container, depending on the settings.

A special feature of containers is the “cauldron”, capable of mixing alchemical receipes.

• “container <value>”: The container can hold a maximum total weight of <value> gram. Note that this weight limit is calculated *after* the weight reduction (→ Str) has been applied.
• “Str <value>” determines how much the weight of items is reduced in percent, when put inside the container. “Str 0” means no reduction, “Str 100” means items are weightless inside. Most default values are in the range of ten.
• “race <container_type>”: If set, the container will hold only certain types of objects. Possible choices for <container_type> are: “gold and jewels”, “arrows” and “keys”. Unfortunately it is not easy to create new container types, because they are hardcoded.
• “is_cauldron 1”: 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.
• “other_arch <arch_name>” 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.
• “no_pick 1” should be set for all containers that you're using as map-decoration/furniture, like bookshelves, (permanent) chests or deposit boxes. For the ones you want the player to have, set “no_pick 0”.

Note on chests: There are two types of chests: First the random treasure chests - Those are NOT containers (but object type 4), 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”.

Functionality of runes/ traps: A rune is a magical enscription on the dungeon floor. Traps are just like runes except they are not magical in nature, and generally have a physical attack.

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 traps and runes are already defined in the archetypes.

• “level <number>”: Level the rune will cast the spell it contains at, if applicable. A level 99 rune casts a very, very mean spell of whatever. (“level 0” runes won't detonate at all!) Level Also effects how easily a trap 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.
• “Cha <value>” determines what fraction of the time the rune is visible: It'll be randomly visible 1/Cha of the time. Also effects how easily the trap may be found.
• “sp <spellnum>” defines the spell in the rune, if any. (Many runes and all traps do direct damage).
• “slaying <spell_name>”: Name of the spell in the rune, if any. Slaying is optional, but if present, overrides sp. Recommended for use by mapmakers to ensure portability.
• “hp <number>”: The rune will detonate <number> times before disappearing.
• “attacktype <attack_num>”: If there isn't any spell (and race is unset), this attribute defines what attacktype to use for direct damage when the rune detonates.
• “msg <text> endmsg”: When the rune detonates, <text> is displayed to the victim. For especially powerful runes, create an appropriate thrilling description. ;)
• “dam <value>” 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.
• “maxsp <rotation_num>” sets the direction to cast the spell the rune contains, if any. 1=north, 2=northeast, 3=east, …, 8=northwest. In most cases this appears useless since the spell directly hits the player.
• “race <monster_arch_name>”: If this is set to the arch name of any monster, together with “slaying summon evil monster”, the rune will summon a bunch of those on detonation. (dam and attacktype will still be ignored in this case). In theory, runes are even capable of summoning multi-square monsters, given enough space. You'd better test it though.
• “maxhp <number>” should only be set to a summoning rune. It will then summon <number> creatures of <monster_arch_name>.

Notes on usage: Avoid monsters stepping on your runes. For example, summoning runes together with spellcasting- and attack-runes is usually a bad idea. One can use this feature intentionally though to create chain-reactions of summoning runes and such things, however one should be careful about doing this.

The following attributes are used for many different object-types: (These are only mentioned here, not in the detailed list of object-types above. Apply them to all objects where they make any “sense”.)

Note: When attributes are specified in multi-tile arch, most attributes need only be set in the head part, though there are some which may be uniquely set for each non-head part.

/**
 * @defgroup OBJECT_TYPE Object types.
 *
 * Only add new values to this list if somewhere in the program code, it is
 * actually needed.  Just because you add a new monster does not mean it has to
 * have a type defined here.  That only needs to happen if in some .c file, it
 * needs to do certain special actions based on the monster type, that can not
 * be handled by any of the numerous flags.  Also, if you add new entries, try
 * and fill up the holes in this list.  Additionally, when you add a new entry,
 * include it in the table in common/item.c
 *
 * type 0 is undefined and indicates non-valid type information.
 */
/*@{*/
#define PLAYER                      1
#define TRANSPORT                   2     /* see doc/Developers/objects */
#define ROD                         3
#define TREASURE                    4
#define POTION                      5
#define FOOD                        6
#define POISON                      7
#define BOOK                        8
#define CLOCK                       9
/*#define FBULLET                   10 */
/*#define FBALL                     11 */
/*#define LIGHTNING                 12 */
#define ARROW                       13
#define BOW                         14
#define WEAPON                      15
#define ARMOUR                      16
#define PEDESTAL                    17
#define ALTAR                       18
/*#define CONFUSION                 19 */
#define LOCKED_DOOR                 20
#define SPECIAL_KEY                 21
#define MAP                         22
#define DOOR                        23
#define KEY                         24
/*#define MMISSILE                  25 */
#define TIMED_GATE                  26
#define TRIGGER                     27
#define GRIMREAPER                  28
#define MAGIC_EAR                   29
#define TRIGGER_BUTTON              30
#define TRIGGER_ALTAR               31
#define TRIGGER_PEDESTAL            32
#define SHIELD                      33
#define HELMET                      34
#define HORN                        35
#define MONEY                       36
#define CLASS                       37    /* object for applying character class
                                           * modifications to someone */
/*#define GRAVESTONE                38 */
#define AMULET                      39
#define PLAYERMOVER                 40
#define TELEPORTER                  41
#define CREATOR                     42
#define SKILL                       43    /* also see SKILL_TOOL (74) below */
#define EXPERIENCE                  44    /* This is basically obsolete now.
                                           * It used to contain experience for
                                           * broad skill categories.  This
                                           * value is now automatically
                                           * converted at load time. */
#define EARTHWALL                   45
#define GOLEM                       46
/*#define BOMB                      47 */
#define THROWN_OBJ                  48
#define BLINDNESS                   49
#define GOD                         50

#define DETECTOR                    51    /* peterm:  detector is an object */
                                          /* which notices the presense of */
                                          /* another object and is triggered */
                                          /* like buttons.  */
#define TRIGGER_MARKER              52    /* inserts an invisible, weightless */
                                          /* force into a player with a
                                           * specified string WHEN TRIGGERED. */
#define DEAD_OBJECT                 53
#define DRINK                       54
#define MARKER                      55    /* inserts an invisible, weightless
                                           * force into a player with a
                                           * specified string. */
#define HOLY_ALTAR                  56
#define PLAYER_CHANGER              57
#define BATTLEGROUND                58    /* battleground, by Andreas Vogl */

#define PEACEMAKER                  59    /* Object owned by a player which can
                                           * convert a monster into a peaceful
                                           * being incapable of attack.  */
#define GEM                         60
/*#define FIRECHEST                 61 */ /* FIRECHEST folded into FIREWALL */
#define FIREWALL                    62
/*#define ANVIL                     63 */
#define CHECK_INV                   64    /* b.t. thomas@nomad.astro.psu.edu */
#define MOOD_FLOOR                  65    /* b.t. thomas@nomad.astro.psu.edu
                                           * values of last_sp set how to
                                           * change:
                                           * 0 = furious, all monsters become
                                           *     aggressive
                                           * 1 = angry, all but friendly become
                                           *     aggressive
                                           * 2 = calm, all aggressive monsters
                                           *     calm down
                                           * 3 = sleep, all monsters fall asleep
                                           * 4 = charm, monsters become pets */
#define EXIT                        66
#define ENCOUNTER                   67
#define SHOP_FLOOR                  68
#define SHOP_MAT                    69
#define RING                        70
#define FLOOR                       71    /* Floor tile -> native layer 0 */
#define FLESH                       72    /* animal 'body parts' -b.t. */
#define INORGANIC                   73    /* metals, minerals, dragon scales */
#define SKILL_TOOL                  74    /* Allows the use of a skill */
#define LIGHTER                     75

/* The trap_part, wall, light_source, misc_object, monster, and spawn_generator
 * types are not used in any archetypes, and should perhaps be removed.
 */
/*#define TRAP_PART                 76 */ /* Needed by set traps skill -b.t. */

#define WALL                        77    /* Wall. Put it always in layer 1 if
                                           * not set is_floor */
/*#define LIGHT_SOURCE              78 */ /* torches, lamps, etc. */
#define MISC_OBJECT                 79    /* misc. objects are for objects
                                           * without a function in the engine.
                                           * Like statues, clocks, chairs...
                                           *  If perhaps we create a function
                                           * where we can sit on chairs, we
                                           * create a new type and remove all
                                           * chairs from here. */
#define MONSTER                     80    /* A real, living creature */
/*#define SPAWN_GENERATOR           81 */ /* Spawn point or monster generator */
#define LAMP                        82    /* Lamp */
#define DUPLICATOR                  83    /* Duplicator/multiplier object */
/*#define TOOL                      84 */ /* Tool for building objects */
#define SPELLBOOK                   85
/*#define BUILDFAC                  86 */ /* Facilities for building objects */
#define CLOAK                       87
/*#define CONE                      88 */
/*#define AURA                      89 */ /* Aura spell object */

#define SPINNER                     90
#define GATE                        91
#define BUTTON                      92
#define CF_HANDLE                   93
#define HOLE                        94
#define TRAPDOOR                    95
/*#define WORD_OF_RECALL            96 */
/*#define PARAIMAGE                 97 */
#define SIGN                        98
#define BOOTS                       99
#define GLOVES                      100
#define SPELL                       101
#define SPELL_EFFECT                102
#define CONVERTER                   103
#define BRACERS                     104
#define POISONING                   105
#define SAVEBED                     106
/*#define POISONCLOUD               107*/
/*#define FIREHOLES                 108*/
#define WAND                        109
/*#define ABILITY                   110*/
#define SCROLL                      111
#define DIRECTOR                    112
#define GIRDLE                      113
#define FORCE                       114
#define POTION_EFFECT               115   /* A force, holding the effect of a
                                           * potion */
#define EVENT_CONNECTOR             116   /* Lauwenmark: an invisible object
                                           * holding a plugin event hook */
#define CLOSE_CON                   121   /* Eneq(@csd.uu.se): Id for
                                           * close_container archetype. */
#define CONTAINER                   122
#define ARMOUR_IMPROVER             123
#define WEAPON_IMPROVER             124

/* unused: 125 - 129
 * type 125 was MONEY_CHANGER
 */
#define SKILLSCROLL                 130   /* can add a skill to player's
                                           * inventory -bt.*/
#define DEEP_SWAMP                  138
#define IDENTIFY_ALTAR              139
/*#define CANCELLATION              141*/ /* not used with new spell code */
#define SHOP_INVENTORY              150   /* Mark Wedel (mark@pyramid.com) Shop
                                           * inventories */
/*#define BALL_LIGHTNING            151*/ /* peterm:  ball lightning and color
                                           * spray */
/*#define SWARM_SPELL               153*/
#define RUNE                        154
#define TRAP                        155

#define POWER_CRYSTAL               156
#define CORPSE                      157

#define DISEASE                     158
#define SYMPTOM                     159

#define BUILDER                     160   /* Generic item builder, see subtypes
                                           * below */
#define MATERIAL                    161   /* Material for building */

#define OBJECT_TYPE_MAX             161   /* Update if you add new types */
/* END TYPE DEFINE */
/*@}*/