dev:object_types
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Last revision Both sides next revision | ||
|
dev:object_types [2018/04/08 13:05] karl Dix page linkings , needs an other cleanup next time |
dev:object_types [2018/04/08 14:22] karl [type 85: spellbook] |
||
|---|---|---|---|
| Line 52: | Line 52: | ||
| - | ==== type 3: Rod ==== | + | ==== type 3: rod ==== |
| - | Functionality of rods: | + | 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. | 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 [[#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! | + | * "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. | * "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. | * "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. | * "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) | + | see also: [[#type 35: horn]] (35), [[#type 109: wand / staff]] (109) |
| - | ==== type 4: Treasure ==== | + | ==== type 4: treasure ==== |
| - | Functionality of treasure: A treasure-object turns into certain randomitems when the map is loaded into the game. | + | 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. | * "randomitems <treasurelist>" determines what kind of treasure will appear. Look into /crossfire/share/crossfire/treasures for details about existing treasurelists. | ||
| Line 72: | Line 73: | ||
| * "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!) | * "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: | + | 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. | 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. | ||
| ==== type 5: potion ==== | ==== type 5: potion ==== | ||
| - | Functionality of potions: | + | Functionality of potions: \\ |
| The player can drink these and gain various kinds of benefits (/penalties) by doing so. | The player can drink these and gain various kinds of benefits (/penalties) by doing so. | ||
| Line 89: | Line 90: | ||
| ==== type 6: food ==== | ==== type 6: food ==== | ||
| - | Functionality of food: | + | Functionality of food: \\ |
| By eating/drinking food-objects, the player can fill his stomach and gain a little health. | 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. | * "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]] (72) | + | see also: [[#type 72: flesh]] |
| ==== type 7: poison food ==== | ==== type 7: poison food ==== | ||
| - | Functionality of poison food: | + | 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. | When eating, the player's stomach is drained by 1/4 of food. If his food drops to zero, the player might even die. | ||
| - | ==== type 8: books ==== | + | ==== type 8: book ==== |
| - | Functionality of books: | + | Functionality of books: \\ |
| Applying a book, the containing message is displayed to the player. | Applying a book, the containing message is displayed to the player. | ||
| Line 109: | Line 110: | ||
| * "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. | * "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]] (85), [[#type 98: sign]] (98), [[#type 111: scroll]] (111) | + | see also: [[#type 85: spellbook]] , [[#type 98: sign / magic mouth]] , [[#type 111: scroll]] |
| ==== type 9: clock ==== | ==== type 9: clock ==== | ||
| - | Functionality of clocks: | + | Functionality of clocks: \\ |
| Applying a clock, the time is displayed to the player | Applying a clock, the time is displayed to the player | ||
| - | ==== type 13: arrow/bolt ==== | + | ==== type 13: arrow / bolt ==== |
| - | Functionality of arrows/bolts: | + | 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. | Arrows can be shot with bows, bolts with crossbows. They are usually weaker than melee but players can shoot from a safe distance. | ||
| Line 129: | Line 130: | ||
| ==== type 14: shooting weapon ==== | ==== type 14: shooting weapon ==== | ||
| - | Functionality of Shooting Weapons: | + | 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. | 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. | ||
| Line 135: | Line 136: | ||
| * "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 | * "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]] (15) | + | see also: [[#type 15: weapon]] |
| ==== type 15: weapon ==== | ==== type 15: weapon ==== | ||
| - | Functionality of weapons: | + | 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. | 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. | ||
| Line 152: | Line 153: | ||
| * "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. | * "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: | + | 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. | Keep playbalance in mind! Such items mustn't be reachable without hard fighting AND questing. | ||
| See "[[#golden rules of map-making]]". | See "[[#golden rules of map-making]]". | ||
| - | ==== type 16: (brestplate) armour ==== | + | ==== type 16: armour ==== |
| - | Functionality of armour: | + | Functionality of mail / breastplate armour: \\ |
| Wearing an armour, the object's stats will directly be inherited to the player. Usually enhancing his defense. | Wearing an armour, the object's stats will directly be inherited to the player. Usually enhancing his defense. | ||
| Line 171: | Line 172: | ||
| * "xrays 1" enables xray-vision for the player, while wearing this armour. | * "xrays 1" enables xray-vision for the player, while wearing this armour. | ||
| - | see also: [[#type 33: shield]] (33), [[#type 34: helmet]] (34), [[#type 39: amulet]] (39), [[#type 70: ring]] (70), [[#type 87: cloak]] (87), [[#type 99: boots]] (99), [[#type 100: gloves]] (100), [[#type 104: bracers]] (104), [[#type 113: girdle]] (113) | + | 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 brestplate armour. | + | These all work more or less exactly like breastplate armour. |
| ==== type 17: pedestal==== | ==== type 17: pedestal==== | ||
| - | Functionality of pedestals: | + | 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. | 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. | + | * "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 [[:races: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. | * "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. | * "walk_on 1", "walk_off 1" should both be set or it won't work. | ||
| - | Notes on usage: | + | Notes on usage: \\ |
| - | If you want to create a place where only players of a certain race can enter, put a [[#dev:object_types#type_41teleporter|teleporter]] over your pedestal. So the [[#dev:object_types#type_41teleporter|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. | + | 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]] (51), [[#type 64: inventory checker]] (64), [[#type 18: altar]] (18) | + | see also: [[#type 51: detectors]] , [[#type 64: inventory checker]] , [[#type 18: altar]] |
| ==== type 18: altar ==== | ==== type 18: altar ==== | ||
| - | Functionality of altars: | + | 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. | 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. | ||
| Line 201: | Line 202: | ||
| * "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. | * "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]] (31), [[#type 56: holy altar]] (56) | + | see also: [[#type 31: altar_trigger]] , [[#type 56: holy altar]] |
| ==== type 20: locked door ==== | ==== type 20: locked door ==== | ||
| - | Functionality of locked doors: | + | Functionality of locked doors: \\ |
| - | A locked door can be opened only when carrying the appropriate [[#special key]]. | + | 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". | * "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". | ||
| Line 212: | Line 213: | ||
| * "no_magic 1", "damned 1" should always be set to prevent players passing through the door by dimension door spell. | * "no_magic 1", "damned 1" should always be set to prevent players passing through the door by dimension door spell. | ||
| - | Notes on usage: | + | 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). | 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]] (21) | + | see also: [[#type 21: special key]] |
| ==== type 21: special key ==== | ==== type 21: special key ==== | ||
| - | Functionality of special keys: | + | Functionality of special keys: \\ |
| When carrying the appropriate special key, a locked door can be opened. The key will disappear. | 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. | 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. | ||
| Line 227: | Line 228: | ||
| * "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. | * "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: | + | 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]]. | 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". | 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]] (20), [[#type 64: inventory checker]] (64) | + | see also: [[#type 20: locked door]] , [[#type 64: inventory checker]] |
| ==== type 29: magic ear ==== | ==== type 29: magic ear ==== | ||
| - | Functionality of magic_ears: | + | Functionality of magic_ears: \\ |
| Magic_ears trigger a connected value when the player speaks a specific keyword. | Magic_ears trigger a connected value when the player speaks a specific keyword. | ||
| Line 242: | Line 243: | ||
| * "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. | * "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: | + | 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 | 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. | like a gate that is opened by speaking "open" or "sesame", expecting the player to figure this out all by himself. | ||
| Line 250: | Line 251: | ||
| ==== type 31: altar_trigger ==== | ==== type 31: altar_trigger ==== | ||
| - | Functionality of altar_triggers: | + | 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. | 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. | ||
| Line 260: | Line 261: | ||
| * "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. | * "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: | + | Hints on usage: \\ |
| Altar_triggers are very useful if you want to charge a price for... | Altar_triggers are very useful if you want to charge a price for... | ||
| Line 269: | Line 270: | ||
| 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. =) | 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]] (18) | + | see also: [[#type 18: altar]] |
| + | ==== type 33: shield ==== | ||
| + | FIXME | ||
| + | |||
| + | ==== type 34: helmet ==== | ||
| + | FIXME | ||
| ==== type 35: horn ==== | ==== type 35: horn ==== | ||
| Line 277: | Line 283: | ||
| see also: [[#type 3: rod]] | see also: [[#type 3: rod]] | ||
| + | ==== type 39: amulet ==== | ||
| + | FIXME | ||
| ==== type 40: mover ==== | ==== type 40: mover ==== | ||
| - | Functionality of movers: | + | 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. | 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. | ||
| Line 295: | Line 303: | ||
| * "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). | * "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: | + | 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 counterintuitive unless it is hinted to. | + | 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 [[:world: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. | 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: | + | 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). | 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]] (112) | + | see also: [[#type 112: director]] |
| ==== type 41: teleporter ==== | ==== type 41: teleporter ==== | ||
| - | Functionality of teleporters: | + | Functionality of teleporters: \\ |
| - | When the player walks into a teleporter, he is transferred to a different location. The main difference to the object-type [[#exit]] is the possibility to have teleporters connected to levers/buttons/etc. Sometimes teleporters are activated even against the players will. | + | 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. | + | 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. | * "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. | ||
| Line 317: | Line 325: | ||
| * "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. | * "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: | + | Notes on usage: \\ |
| Teleporters must always be placed above the floor in order to work correctly! | 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. | 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]] (66) | + | see also: [[#type 66: exit]] |
| ==== type 42: creator ==== | ==== type 42: creator ==== | ||
| - | Functionality of creators: | + | 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. | 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. | ||
| Line 336: | Line 344: | ||
| * "level <number>: The created object will be of level <number>. Again, if not set, the standard level 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: | + | Notes on usage: \\ |
| Don't hesitate to hide your creators under the floor. The created items will still always appear ontop of the floor. | 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]] (154) | + | see also: [[#type 154: rune / trap]] |
| ==== type 51: detectors ==== | ==== type 51: detectors ==== | ||
| - | Functionality of detectors: | + | Functionality of detectors: \\ |
| Detectors work quite much like [[#inv. checkers]]/[[#pedestals]]: If the detector finds a specific object, it toggles its connected value. | Detectors work quite much like [[#inv. checkers]]/[[#pedestals]]: If the detector finds a specific object, it toggles its connected value. | ||
| Line 351: | Line 359: | ||
| * "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". | * "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: | + | 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. | 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]] (17), [[#type 64: inv. checker]] (64), [[#type 18: altar]] (18) | + | see also: [[#type 17: pedestal]] , [[#type 64: inventory checker]] , [[#type 18: altar]] |
| ==== type 55: marker ==== | ==== type 55: marker ==== | ||
| - | Functionality of markers: | + | 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. | 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. | Note that the player has no possibility to "see" his own marks, except by the effect that they cause on the maps. | ||
| Line 368: | Line 376: | ||
| * "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. | * "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: | + | 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. | 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. | 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]] (64) | + | see also: [[#type 64: inventory checker]] |
| ==== type 56: holy altar ==== | ==== type 56: holy altar ==== | ||
| - | Functionality of holy_altars: | + | 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]]) | 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". | + | * "other_arch <god_name>" specifies the [[:gods|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. | * "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. | 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]] (18) | + | see also: [[#type 18: altar]] |
| ==== type 59: peacemaker ==== | ==== type 59: peacemaker ==== | ||
| Line 392: | Line 400: | ||
| ==== type 62: magic wall ==== | ==== type 62: magic wall ==== | ||
| - | Functionality of magic walls: | + | 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. | 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. | + | Several types of magical walls are predefined for you in the archetypes, and can be found on a pick-map available in [[:crossfire:editors:x11:crossedit]] . |
| * "dam <[[#spellnumber]]>" specifies the spell the wall will cast. You can find a list of spellnumbers [[#here]]. | * "dam <[[#spellnumber]]>" specifies the spell the wall will cast. You can find a list of spellnumbers [[#here]]. | ||
| Line 405: | Line 413: | ||
| * "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]]. | * "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: | + | Notes on usage: \\ |
| - | Spellcasting walls pose an interesting alternative to monsters. Usually they are set to be undestroyable ("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. | + | 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. | 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. | ||
| Line 416: | Line 424: | ||
| ==== type 64: inventory checker ==== | ==== type 64: inventory checker ==== | ||
| - | Functionality of inventory checkers: | + | 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"). | 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"). | ||
| Line 431: | Line 439: | ||
| * "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". | * "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: | + | 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. | 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]] (21), [[#type 55: marker]] (55), [[#type 17: pedestal]] (17), [[#type 51: detector]] (51) | + | see also: [[#type 21: special key]] , [[#type 55: marker]] , [[#type 17: pedestal]] , [[#type 51: detector]] |
| ==== type 65: mood floor ==== | ==== type 65: mood floor ==== | ||
| - | Functionality of mood floors: | + | 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. | 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. | ||
| Line 449: | Line 457: | ||
| * "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! | * "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: \\ |
| Notes on usage: Mood floors are absolutely cool for NPC interaction. To make an unaggressive monster/NPC attack, put a [[#creator]] with | 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. | "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. | ||
| Line 459: | Line 467: | ||
| ==== type 66: exit ==== | ==== type 66: exit ==== | ||
| - | Functionality of exits: | + | 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. | 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. | ||
| Line 469: | Line 477: | ||
| * "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". | * "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: | + | 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. | 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. | 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]] (41) | + | see also: [[#type 41: teleporter]] |
| + | |||
| + | |||
| + | ==== type 70: ring ==== | ||
| + | FIXME | ||
| + | |||
| + | |||
| + | ==== type 72: flesh ==== | ||
| + | FIXME | ||
| + | |||
| + | se also [[#type 6: food]] | ||
| ==== type 85: spellbook ==== | ==== type 85: spellbook ==== | ||
| - | Functionality of spellbooks: | + | 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. | 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. | ||
| Line 485: | Line 503: | ||
| * "msg <text> endmsg" could contain a nice description of the spellbook's cover or something. | * "msg <text> endmsg" could contain a nice description of the spellbook's cover or something. | ||
| - | Notes on usage: | + | 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. | 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 arch "random_spells" ([[#type 4]]) instead. | + | If you want to have a random spellbook, you must use the [[#type 4: treasure]] arch "random_spells" instead. |
| - | see also: [[#type 8: book]] (8) | + | see also: [[#type 8: book]] |
| + | ==== type 87: cloak ==== | ||
| + | FIXME | ||
| ==== type 94: hole ==== | ==== type 94: hole ==== | ||
| Line 505: | Line 525: | ||
| **Examples** | **Examples** | ||
| - | * [[#http://crossfire.svn.sourceforge.net/viewvc/crossfire/arch/trunk/connect/Hole/pit.arc|connect/Hole/pit.arc|pit.arc]] | + | * [[http://crossfire.svn.sourceforge.net/viewvc/crossfire/arch/trunk/connect/Hole/pit.arc|connect/Hole/pit.arc|pit.arc]] |
| **Special Object Attributes** | **Special Object Attributes** | ||
| Line 516: | Line 536: | ||
| | | maxsp | | Whether the initial state is open (1) or closed (0). | | | | maxsp | | Whether the initial state is open (1) or closed (0). | | ||
| - | ==== type 98: sign/ magic mouth ==== | + | ==== type 98: sign / magic mouth ==== |
| - | Functionality of signs/ magic_mouths: | + | 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). | 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. | * "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. | * "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 ontop 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. | + | * "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. | * "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! | * "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). | * "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: | + | 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. | 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]] (8) | + | see also: [[#type 8: book]] |
| + | |||
| + | |||
| + | ==== type 99: boots ==== | ||
| + | FIXME | ||
| + | |||
| + | ==== type 100: gloves ==== | ||
| + | FIXME | ||
| ==== type 103: converter ==== | ==== type 103: converter ==== | ||
| - | Functionality of converters: | + | 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. | 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. | ||
| Line 543: | Line 570: | ||
| * "walk_on 1" and "no_pick 1" must always be set for converters. | * "walk_on 1" and "no_pick 1" must always be set for converters. | ||
| - | Notes on usage: | + | 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. | 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 dragonscales for payment). The code will not check if your ratio is sane, so the player could gain infinite wealth by using your converter. | + | 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]] (42) | + | See also: [[#type 42: creator]] |
| + | |||
| + | ==== type 104: bracers ==== | ||
| + | FIXME | ||
| ==== type 106: savebed ==== | ==== type 106: savebed ==== | ||
| - | Functionality of savebeds: | + | 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. | 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. | ||
| Line 558: | Line 589: | ||
| * "no_magic 1", "damned 1" marks the savebed as no-spell-area. Again, DO NOT CHANGE THIS. Sometimes players die in auto fire mode... | * "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: | + | Notes on usage: \\ |
| - | Put savebed locations in towns, do not put them into dungeons. It is absolutely neccessary that a place with savebeds is 100% secure. That means: | + | 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! | * Monsters must not be able to reach the savebeds under any circumstances! | ||
| * If there are NPCs around, make sure they have "friendly 1" set. | * If there are NPCs around, make sure they have "friendly 1" set. | ||
| - | * Insert a relyable exit! Make sure there is no possibility that players get trapped in a savebed location. | + | * 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. | * 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. | ||
| - | ==== type 109: wand/staff ==== | + | ==== type 109: wand / staff ==== |
| - | Functionality of wands/staves: | + | 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. | 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. | ||
| Line 577: | Line 608: | ||
| Notes on usage: | Notes on usage: | ||
| - | Wands are quite seldomly 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. | + | 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 desireable though. | + | For low levels, staffs of healing/cure and word of recall are quite desirable though. |
| - | see also: [[#type 3: rod]] (3), [[#type 5: potion]] (5), [[#type 111: scroll]] (111) | + | see also: [[#type 3: rod]] , [[#type 5: potion]] , [[#type 111: scroll]] |
| + | |||
| + | ==== type 111: scroll ==== | ||
| + | FIXME | ||
| + | |||
| + | see also: [[#type 3: rod]] , [[#type 5: potion]] , [[#type 109: wand / staff]] | ||
| + | |||
| + | ==== type 113: girdle ==== | ||
| + | FIXME | ||
| ==== type 122: container ==== | ==== type 122: container ==== | ||
| Line 601: | Line 640: | ||
| 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". | 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". | ||
| - | ==== type 154: rune/trap ==== | + | ==== type 154: rune / trap ==== |
| Functionality of runes/ traps: | Functionality of runes/ traps: | ||
| Line 857: | Line 896: | ||
| /* END TYPE DEFINE */ | /* END TYPE DEFINE */ | ||
| /*@}*/ | /*@}*/ | ||
| + | |||
dev/object_types.txt · Last modified: 2024/05/20 18:25 by leaf
Page Tools
