1. Determine if new archetype is really needed. Archetypes are only needed to add new images, or if the archetype simplifies creation of a very common item. Don’t make a new arch to simply customize an existing archetype.
2. Figure out which directory/category the object will belong to. This determines an appropriate location for it inside the ‘arch’ directory. For objects with many animations or that are very large, new subdirectory may be advisable.
3. Create a bitmap. It must be divisible by 32 in both height and width. The file format should be .PNG 256 colour with transparency.
4. Create additional bitmaps if you want animation or directional facing.
5. Split the bitmaps up into 32×32 bitmaps and named according to the naming.doc conventions in the arch tar package. Note, this is not really necessary at current time - non-split images should work properly, but some older clients may have problems with it. (the script “splitxbm” may be used and is included below).
6. Create an archetype entry. The file should be called object.arc, where object is whatever the new object is. This is the most complicated step. See “crossfire.doc” for an introduction on how to create archetypes.
   • Look at other similar archetypes to see how they have been made.
   • If a single 32×32 bitmap is created, only one archetype is needed, but if a larger bitmap is made which is cut down to several 32×32 bitmaps, use “linked” archetypes are needed. To create a linked archetype, add a ‘More’ line filed by the next piece. The X and Y coordinates in this next piece determine the offset from the head (first) object.
   • When making multipart objects, they should be rectangular. Non rectangular may work, but has not been tested. Note that for multi-part objects, in most cases, only the values in the head portion are used (eg, hp, damage, etc for monsters) so it is generally unnecessary to put a copy of all the head tags in the other parts.
   • See the section later in this document about animations.
7. If the archetype is a creature or NPC, and if it has abilities such as firebreathing or magical attacks, these abilities are put into the treasures file in the appropriate entry, and as invisible objects. This is also how inventory like bows or swords is given. Look at the other entries in the treasures file for the format to use. Note that if an existing entry in the treasures file does what you want, reuse it for the new archetype. There is no requirement that each archetype have a unique treasure list.

Objects are directly derived from archetypes. Everything the player sees in the game is an object. The player never deals with archetypes.

Archetypes are the master objects. All objects have an archetype that they are derived from. When an object is created, the archetype is used for all the default values in the object. When an object is saved, the code looks at the differences between the archetype and the object it is saving, and only changes the different values.

Archetypes are the entries in the ‘arch’ directory. The fields for archetypes and objects are generally the same.

Note that by using this archetype model, it means an archetype can get updated and all objects that are derived from it will get updated - this is very useful when new fields are added - the archetypes can get updated, and all objects in maps, player save files, wherever, get this new value.

It is valid to put items into an archetype, including a customized version. All objects created from the archetype will include the object(s) (including their own inventory).

The name in parentheses after a flag description is the name as it should be used in the archetype file. For example: Attack type (attacktype)

Note that one archetype can have multiple attack types by adding these values together. Thus, something with an attacktype of 65 would attack with both acid and physical.

Creatures can have various resistances. If a creature has a resistance value for a particular attacktype of 100, it is said to be immune to that attacktype. The amount of resistance directly reduces damage. A creature that has 25% resistance to fire only takes 75% of the damage. A creature 99% resistant only takes 1% of the damage.

A few notes: If a creature/object is immune to magic, then it will be immune to all damage from that attack, even if that attack type contains more than just magic.

Otherwise, a creature needs to be immune to all attack types in order to take no damage (thus, a creature that is immune to physical, but getting hit by a weapon that does physical and fire would take normal damage). The attack code goes through all the attacktypes, and calculates the damage that each will cause. It uses the highest damage total that any of these attacktypes will use.

For attacktypes that don’t deal physical damage but instead effect the creature in some way (drain, slow, paralyze, etc), the resistance in general reduces the effect (duration, amount drained, etc).

Set the variable attack_movement to one of the below (cut from define.h):

/******************************************************************************/
/* Monster Movements added by kholland@sunlab.cit.cornell.edu                 */
/******************************************************************************/
/* if your monsters start acting wierd, mail me                               */
/******************************************************************************/
/* the following definitions are for the attack_movement variable in monsters */
/* if the attack_variable movement is left out of the monster archetype, or is*/
/* set to zero                                                                */
/* the standard mode of movement from previous versions of crossfire will be  */
/* used. the upper four bits of movement data are not in effect when the monst*/
/* er has an enemy. these should only be used for non aggressive monsters.     */
/* to program a monsters movement add the attack movement numbers to the movem*/
/* ment numbers example a monster that moves in a circle until attacked and   */
/* then attacks from a distance:                                              */
/*                                                      CIRCLE1 = 32          */
/*                                              +       DISTATT = 1           */
/*                                      -------------------                   */
/*                      attack_movement = 33                                  */
/******************************************************************************/
#define DISTATT  1 /* move toward a player if far, but mantain some space,  */
                   /* attack from a distance - good for missile users only  */
#define RUNATT   2 /* run but attack if player catches up to object         */
#define HITRUN   3 /* run to then hit player then run away cyclicly         */
#define WAITATT  4 /* wait for player to approach then hit, move if hit     */
#define RUSH     5 /* Rush toward player blindly, similiar to dumb monster  */
#define ALLRUN   6 /* always run never attack good for sim. of weak player  */
#define DISTHIT  7 /* attack from a distance if hit as recommended by Frank */
#define WAIT2    8 /* monster does not try to move towards player if far    */
                   /* maintains comfortable distance                        */
#define PETMOVE 16 /* if the upper four bits of attack_movement 	    */
                   /* are set to this number, the monster follows a player  */
                   /* until the owner calls it back or off                  */
                   /* player followed denoted by 0b->owner                  */
                   /* the monster will try to attack whatever the player is */
                   /* attacking, and will continue to do so until the owner */
                   /* calls off the monster - a key command will be         */
                   /* inserted to do so                                     */
#define CIRCLE1 32 /* if the upper four bits of attack_movement             */
                   /* are set to this number, the monster will move in a    */
                   /* circle until it is attacked, or the enemy field is    */
                   /* set, this is good for non-aggressive monsters and NPC */
#define CIRCLE2 48 /* same as above but a larger circle is used             */
#define PACEH   64 /* The Monster will pace back and forth until attacked   */
                   /* this is HORIZONTAL movement                           */
#define PACEH2  80 /* the monster will pace as above but the length of the  */
                   /* pace area is longer and the monster stops before      */
                   /* changing directions                                   */
                   /* this is HORIZONTAL movement                           */
#define RANDO   96 /* the monster will go in a random direction until       */
                   /* it is stopped by an obstacle, then it chooses another */
                   /* direction.                                            */
#define RANDO2 112 /* constantly move in a different random direction       */
#define PACEV  128 /* The Monster will pace back and forth until attacked   */
                   /* this is VERTICAL movement                             */
#define PACEV2 144 /* the monster will pace as above but the length of the  */
                   /* pace area is longer and the monster stops before      */
                   /* changing directions                                   */
                   /* this is VERTICAL movement                             */
#define LO4     15 /* bitmasks for upper and lower 4 bits from 8 bit fields */
#define HI4    240

Pick Up specifiers (defined with pick_up)

Note also that if can_use_armor, can_use_weapon, can_use_ring, can_use_wand, can_cast_spell, can_use_bow are set, then the creature will pick up the matching items even if the pick_up element is not set to pick up those items.

This only applies to monsters. The player pickup method is much different.

This determines what treasurelist to use for generating the objects treasures. For archetypes, the default is none, but for other objects (like those loaded in maps), it will use the same treasure list as the archetype it descends from unless otherwise specified. In the case of objects, “none” can be be used to make no items generated.

The format of treasurelists is detailed further down in this file.

Treasure lists are also used to give spell and skill abilities to creatures.

Damage determines the amount of damage the creature does. The form this damage takes it determined by the attacktype the creature has.

When determining damage, a number between 1 and the damage value is rolled. Thus, even if you have a +6 damage bonus from strength, magic weapons, etc, a value of 1 could still be generated. Thus, even with very high magical monsters or very high strength monsters, a low damage roll can result some of the time.

Speed. A speed of 1.0 means it acts every tick, a speed of 0.1 means it acts every 10 ticks.

gives monsters a modifying to find hidden/invisible creatures.

If the creature can cast spells, this is how many spell points are regenerated each move.

Monsters regenerate this many hit points each move. This is each time the monster has a move (some for Pow). So two monsters with the same Con can regenerate at different rates if their speeds are different.

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.

Number of spell points monster starts with

Maximum spellpoints for monsters

set flying to 1 if this can fly.

Very powerful, use carefully

Creatures with this value set to 1 will dissipate when they attack (like ghosts). They dissipate on the first hit, whether it does any damage or not.

What objects the creature can use. Note that this has largely been replaced with the body location information (see further down). The ones that should in general be used are can_use_shield, can_use_weapon, and can_use_bow. the others are likely to be obsoleted.

e.g.

• can_use_scroll 1
• can_use_skill 1
• can_use_wand 1
• can_use_rod 1
• can_cast_spell 1
• can_use_bow 1
• can_use_armour 1
• can_use_weapon 1
• can_use_ring 1

The amount of resistance the object has to certain attack types or environmental effects. Use negative numbers to make objects more vulnerable to the effects.

e.g

• resist_fire 60
• resist_cold -30

The fields resist_*, armour, wc and dam can be set in map files to customize monsters. However, if that monster can be equipped with items, and actually equips some, these values will get reset back to those in the clone archetype (normal values.) Thus, if you want to put a wizard in that does dam 50, make sure can_use_armour, and can_use_weapon are set back to 0. Otherwise, when items are equipped, all the above fields will be reset to standard values.

As of 2006-12-09, this shouldn’t be the case anymore: server will detect modified archetypes, and store its values in a temporary archetype structure to be able to recompute everything.

Generators spawn monsters or other objects. By default, generators are alive and visible and can be destroyed like any other monster.

If set, this object is a generator. Monsters (like mice) can be generators.

If set, the generator will create objects from its inventory. If the inventory holds more than one object, one will be randomly selected from the list each time the generator creates one. If not set, the other_arch object will be used.

If use_content_on_gen is not set, the generator will create copies of the object set in this field.

The generator will spawn objects within this radius of itself. (Within a square of radius*2+1 tiles centered on the generator, to be exact.) If this is not set, the radius defaults to 1, for legacy behavior. Setting it to zero effectively turns off the generator.

If this is set, it limits the number of objects the generator will create at one time. Only objects on the same map are counted. If objects are destroyed or leave the map, the generator will no longer count them and will be able to replace them.

This value is used by the generator for marking and identifying the objects it creates, so it can count them to determine whether generator_max has been met. This field is only used when generator_max is set. If generator_name is not set, the generator defaults to using its name, or if that is not set, to “generator”. If multiple generators on the same map have the same generator_name, they will claim the same monsters. This is a feature, not a bug. It means that you could have four generators in the corners of a room, each named “four generators” and each with a generator_max of 50, and they would create up to 50 total monsters, but in different parts of the room, and possibly from different inventory lists.

An NPC can have any combination of the following programs (flags):

FLAGS: (They are checked in the following order:)

1. sleep (will stand still until woken)
2. scared (will run away)
3. random_movement (move randomly)
4. friendly (will attack enemies of the nearest player)
5. unaggressive (don’t attack until attacked)
6. stand_still (don’t ever move)

sleep + (any) = sleep until woken, then do any of the other things... neutral + random_movement = move randomly around all the time. neutral (alone) = stand still until attacked, then attack and move. stand_still + (any) = do anything except moving

In addition it can have run_away set to which percentage of full hit-points the npc will run away at.

And then there is the NPC features made by Karl Holland (see attack_movement)

Note that scared creatures will become unafraid at some point, so it is typically not useful to set this in maps or in archetypes.

The message structure in a monster may contain:

@match <key>|<key>[...]
  [text]
[...]

This identifies what the monster will say if talked to with a text that matches any keys. They keys are processed as primitive regular expressions, so some characters act as match operators or metacharacters. The asterisk, caret, square braces, and dollar characters are useful to some degree.

An example of usage:

@match hello|hi
Welcome, good friend!
@match bye
Goodbye!
@match sss
Whasssamatter?  You got a lisssp or sssomething?
@match yes
Sssorry, me too.
@match ^no$
You're lucky!
@match *
What did you sssay?

A key containing only ‘*’ will match anything, but it is not handled in the same way that regular expressions are normally handled.

If a message does not contain an ‘@match *’, then the first key that contains an asterisk will be treated as though the key was ‘*’. In the example below, if the player says anything, the NPC will say ‘Nice tune...’ no matter what the player says, even if it does not end with ‘bug’. It will not be possible for the NPC to say ‘Bah, humbug to you!’.

@match hum*
Nice tune...
@match *bug
Bah, humbug to you!

Avoid using ‘*’ except in the form ‘@match *’. If the above conversation were amended to also contain a ‘@match *’, neither the ‘hum*’ nor the ‘*bug’ keys would work.

In fact, ‘*’ is not needed as used in the above examples since ‘@match sss’ operates the same way as ‘@match *sss*’ would be expected to operate in a regular expression. Because of this, be especially careful with short word matches like yes/no answers to questions. ‘@match yes’ triggers when the player enters any word with ‘yes’ in it! If a conversation contains the word ‘yesterday’ or ‘nobody’, the player might type one of these words and the NPC might think they said ‘yes’ or ‘no’.

If you want to prevent a match string from matching partial words, use the ‘^’ and ‘$’ metacharacters to bound the word. In the first example, the NPC only responds when the player says ‘no’, and not when the player says any other word that contains ‘no’.

Keys need not contain case variations even though old maps often did. For example, ‘@match hello’ works just as well as the more verbose versions like ‘@match Hello|hello’ and ‘@match “[Hh]ello’. The matches are done after both the match list and the player text are converted to lowercase.

The square braces may be used to construct special matches. For example, a key of ‘[jy]ello’ would match ‘jello’ or even ‘yellow’.

As a special case, if the line just after match is ‘quest xxx’, then the NPC will only display the text (without the quote line) if the player is currently doing indicated quest. See also ‘quests’ document.

Obviously this feature can be expanded extensively, so expect it to evolve till the next version.

You might not want to put messages into archetype creatures, this feature is more for making special NPCs for maps. However, certain generic messages in archetypes might add to the general game ambiance a bit (by default: dogs would say “arf arf” guards would say “move along”...) - tm

See also: CFDialog

The name in parentheses after a flag description is the name as it should be used in the archetype file. For example: editable field (editable)

If no ‘name’ field is specified in the object, it will use the name from the ‘Object’ field.

The ‘name_pl’ field is the plural name for the object. This only needs to be set if there is the potential for the object to merge with others - for example, there is no reason for name_pl to be set for floors, buildings, etc, as they can not merge with other objects. Only objects that can be picked up really need a name_pl value.

If name_pl is not set, this name defaults to the object→name value, which was either explicitly set or determined from the Object field.

These name values are what the player sees for the name. As the player sees it, the name may have the title appended to it, and may also have other per type specific information added in (spell contained within the spellbook for example).

Specified in defines.h, the type field determines how an item operates/what it does.

A new type only needs to be added for a new archetype if it is actually used in some part of the program. Addition of new types is generally a rare event. For example, if adding a new monster, there is no need to add a new type in defines.h if the crossfire-server never checks the type element in the object structure for that new type.

Most types are set for items that are applied, items that have special properties.

You should look at the include/defines.h file for the latest type information. When making a map, you should almost never change the type field of an object - instead, start with an object of an appropriate type, then change the fields of the object to appear as you want it to.

See object_types for a wiki version of the defines.h type definitions.

Subtypes are related to types, in that it narrows down the scope of the type of object. For example, the type may be the value for skill, with subtype being the different skill it uses. Or for spell objects, subtype could be the spell identifier.

Subtype is a new field as of April 2003. It’s use needs to be extended. As example of this is with all equipment items - they should get moved to be of type ‘equipment’, with subtype specifying exactly what it does (ring, helm, armor, etc).

Note that the meaning of the subtype is specific to the type itself - they are not unique across all types. For example, for type equipment, subtype 1 might be a helm. But for type skills, subtype 1 might be smithery. One should not rely on subtype to convey any meaningful information unless the type of the object is known or also examined.

The question may then be asked - when making a new arch, when is a new type needed as opposed to a new subtype?

When to add a new type:

1. If code to support applying the object is completely different than what exists in apply.c (eg, not reusing existing functions), or
2. If code to support movement of the type does not reuse existing functions (server/time.c)

When to make a new subtype:

1. New behavior is _close_ to that of an existing type, but is slightly different (eg, teleporters that don’t work on players), or
2. It is necessary to differentiate between objects of the same type. Eg, addition of a new skill adds a new subtype, not a new type.

When unsure, drop a mail to the crossfire developers list.

If there is a header file that contains all the other information related to the object type, the subtype should be defined there. Otherwise, subtypes should be defined in define.h. The subtype definitions should include be prefixed by what they are a subtype for. Eg, SKILL_SMITHERY, SKILL_JEWELER, etc, and not just SMITHERY and JEWELER. It is acceptable to abbreviate the prefix if it is very long.

Client type information in public information communicated to the client. Client type differs from the type in several ways:

1. It is more specific than the type information.
2. The numbers used for client type are more logically grouped (all armor related client_types are in the same range)
3. client type info does not have a functional component in the server - it only conveys information - the server does not determine what an object may or may not do based on this. At current time, the server does not even look at the client_type for any information.
4. The client_type can be used to hide the real type of an item. Eg, items of client_type poison should never be sent - client_type should instead by booze so difficult for the client to know what the item really is. similarly, special objects used in quests which appear as something else (eg, a key appearing as a shovel) can use the client type to have the type shown as the same category that shovels would be in.

The client_type list below has large gaps - this is to allow future items to be grouped with items of similar type (Eg, if a new weapon type, say two-handed is added, it should be grouped with the weapons and not put at the end of the table). The entire point of the client_type information is to group the items together.

In the list below, the number in parentheses corresponds to the number in define.h file. At the top of each group of items, the range is given. It is intentional in most cases to leave the first entry of a range blank - this gives room to place really important items of a type at the top. Note that only items the player may be able to pick up or apply actually need types.

Note in most cases, the artifact type items are at the top of a group listing. This is done for artifact items that already have a different face/name, such that the player already knows they are special anyways.

Editable sole meaning is for Crossedit. Crossedit uses editable to determine what menu(s) the item should appear in. Crossfire does not use it at all.

The following table/values determine what menus the archetype will appear in. When looking at this table to determine what the value of editable should be, it is 2^(num-1). That is to say if you want it to appear in the ‘shop’ menu, it would be 2^6 and not 2^7. By default, objects default to editable 1 - that is to say, they become monsters.

Asterisk(*) marks groups that are really editable.

An archetype can belong to several editable families, by adding the values together. For example, a value of 544 (512+32) would show up in both the special and walls menu.

This section will briefly try to explain how all the animation values (anim_speed,last_anim, FLAG_IS_TURNING and FLAG_ANIMATE work together.)

In the archetype specification, there is a anim/mina sequence which lists faces are used for animations. An example for the big dragon follows:

anim
dragon.171
dragon.172
dragon.173
dragon.172
dragon.131
dragon.132
dragon.133
dragon.132
mina

Anything that is animated must have such a sequence.

FLAG_ANIMATE (anim, mina)is used to inform crossfire that this object should be constantly animated. A case where an anim section as above is used but FLAG_ANIMATE is not set is for arrows and other objects in which the anim field is instead used to determine what face to draw for different facings of the object.

facings is used in conjunction with FLAG_ANIMATE. This is a states the number of facing the objects has (2, 4, or 8 - 1 is the default). The number of faces in the anim/mina sequence must be a multiple of num facings..

here is an example of using animation and facings:

anim
facings 2
fred.131
fred.132
fred.171
fred.172
mina

The facings go clockwise (1 north (up), 3 east (right), 5 south (down), etc).

If there are fewer than 8 facings (which is typical), the same rotational order is kept. So with only 2 facings, the first half in the group will be used when the creature is pointing to the right, second half to the left.

anim_speed is used to determine how often the object is animated. If anim_speed is 0, then the object is animated anytime it gets an action. If anim_speed is nonzero, then every anim_speed ticks, the object is animated (irregardless of how fast the item is) last_anim is used internally only to determine how many ticks have passed since the item was last animated. anim_speed is useful for objects that otherwise move very slowly but which need to be animated more often. Note: If anim_speed is used, the object must still have a nonzero speed for it to work.

In terms of frequency of animations, 1/anim_speed = object speed. Thus if an object has speed of 0.2, its anim_speed is effectively 5.

The objects material affects how saving throws against an object affect it. Thus, if paper is hit by fire, it tends to burn up, while iron does not. You can look in common/living.c to see the exact values. Note that if the material type is 0 (no material) or is Adamantite, the object can not be harmed in any way.

An object can have multiple material types by adding these values together.

item_power measures how powerful and item is. This information is only relevant for items that are equipped - one time use items, monsters, walls, floors, do not use this.

When a player tries to equip something, the code goes through all the objects the player currently has equipped and sums up their item_power. The item_power of the object the player is trying to equip is also added. If this total exceeds the characters level, he is not allowed to equip the item.

In simple terms, the sum of all the players equip items item_power must be less than the characters level.

Powerful items should have a higher item_power value. This basically acts as a way to balance the items. It also prevents gifts from high level characters to newbies from being very useful - the item_power may prevent the low level character from equipping this items.

For items automatically generated by the treasure code, the following formula is used:

An enchantment is:

• each plus an item has.
• each point an item increases an ability.
• each 20% protection an item gives (rounded normally, eg 0-9 counts as nothing, 10-29 counts as one, etc)
• each attacktype a weapon has.
• spell path adjustments ( denied paths -2 )

These properties have the following enchantment value

• lifesaving 5
• reflect spells 3
• reflect missiles 2
• stealth 1
• xray vison 2
• see in dark 1
• invisibility 1
• slay 2

This same formula can be used for custom objects to figure out their item power.

While the item_power field in the object structure is signed, in general, there should not be objects with a negative item power. However, negative effects an item has may reduce the item power. Eg, a ‘sword +4 (str +2)(wis -3)’ would really be 3 enchantments.

add settings explanation, ensure information is correct :)

The body locations information determines where the item is equipped onto the character. If the character does not have the slot available, they are prevented from equipping the item.

Some races may have a value of 0 for some locations, this denotes that they can not use that particular item (just won’t fit on them).

For monsters/players, the body location information is positive values - this denotes how many locations they have for the different slots.

For items, the body location is negative, this denotes the spaces it uses up. Note that if multiple locations are set in an item, all of those spaces must be available to wear it (it is an AND operation, not an OR). Thus something that has body_neck -1 and body_head -1 means that both the head an neck must be available.

Currently defined list of locations:

- Add information for legs

Using this information is quite easy - for objects, just add the appropriate body_.. with a negative value. For monsters, put those in with a positive value. If a monster has a location to use an object, it is presumed in the code that the monster should pick up/equip objects into that location. Thus, setting these for monsters may not really match what they have, eg, kobolds have arms, but it is still set to 0 so that they won’t equip things. The above information largely replaces the CAN_USE information.

Note that the unqualified names above only refer to human locations. New locations for dragons or other creatures can easily be added.

The steps for adding a body location is as follows:

1. Update the table above for documentation purposes.
2. Update the NUM_BODY_LOCATIONS in include/object.h.
3. Update the body_locations structure in common/item.c. Be sure to read the comments above the structure.
4. recompile
5. create some items that use these new locations.

Note that most the code itself sees all this as abstract - it doesn’t know what goes in what location, or even what each location is called. However, a few bits do care - the skill stuff checks to see if you have any arms free - thus, BODY_ARMS is defined so we know if the player does or does not. The alternative to this would be to have the skill stuff do a strcmp, but then we are defining the name - easier to just presume that the location won’t change in the body_locations table - there is no reason that it should.

All objects have strength, intelligence, wisdom, dexterity, constitution, charisma, experience, and spell points. However, how each is used varies for different objects. Here is a PARTIAL rundown:

For rings, str, int, wis, dex, con and cha are modifiers to the users abilities.

For treasures (chests, random_???), hp is the number of items that should be generated. A chest with hp of 5 will generate 5 treasures, a random_scroll space with hp of 5 will generate 5 random scroll types (of which, each scroll type may number more than one - see the treasures file for more information.)

For shop floors and treasures, exp is the difficulty to use for creating the treasure. If exp is 0 (which it is by default), then the map difficulty is used instead.

For armour, last_sp (ARMOR_SPEED) is the maximum speed that the character can have while wearing that armor.

For armour, last_heal determines the penalty for spell point regeneration.

For exits:

• slaying = The map which the exit leads to.
• hp, sp = (x,y) of the destination on the new map.

Everything that can be applied, including items, exits, handles, and thus can have a ‘race_restriction’ key. The value should be set to a : delimited list of races that will be able to use/apply/open this item. The list is in the form:

    :race1:race2:...:racen:

with leading and trailing :.

Note that that this only applies to players - monsters can always apply everything. Also, Dungeon Masters are immune.

Lore is a free form text field similar to the msg bug. Its syntax is

lore .. .. endlore

while msg’s meaning is dependent on the object, lore is consistent - it should contain background information on the object, or other somewhat general details about the object. It will be put into books, possibly used by npc’s and other places where general knowledge should be presented.

The movement types (MOVE_..) is a bitmask that determines which method of locomotion the object is using, and is also used to determine what types of movement the space blocks. From define.h:

#define MOVE_WALK       0x1     /* Object walks */
#define MOVE_FLY_LOW    0x2     /* Low flying object */
#define MOVE_FLY_HIGH   0x4     /* High flying object */
#define MOVE_FLYING	0x6	/* combo of fly_low and fly_high for easier checking */
#define MOVE_SWIM       0x8     /* Swimming object */
#define MOVE_BOAT	0x10	/* Boats/sailing */
#define MOVE_ALL        0x1f    /* Mask of all movement types */

MOVE_ALL may change in the future - it is mask for all movement types - used for ‘no_pass’ - it sets move_block to MOVE_ALL, other places that check for all movement types may also use this value.

It is possible to use string names instead of the numeric bitmask in the move_fields below. It is strongly encouraged that the string names be used for improved readability. In addition, using string names, especially ‘all’, will result in easier maintainability in the future. For example, if you specify ‘move_block 31’ right now, that is equivalent of all. However, if new move types are added, using a numeric option will not block the new movement types, where if ‘move_block all’ was used, it continue to block everything.

The string names are same as the MOVE_ defines, but with the MOVE_ portion removed, eg, ‘walk’, ‘fly_low’, ‘fly_high’, etc. Multiple types can be listed, separated by a space. In addition, a - (minus) can precede the name, which means to negate that type. These are all equivalent:

move_block 6
move_block fly_low fly_low
move_block flying			(special symbolic name)
move_block all -swim -walk -boat

Note the order when using the -(negation) is important - the string is parsed left to right. This is not equivalent to the above:

move_block -swim -walk -boat all

Because it will clear the swim, walk and boat flags, and then set the flags to all.

Also, using only negation is not allowed - you can not do:

move_block -walk

To indicate you want to remove only the walk blocking from the archetype - you must include a positive indicator.

For all practical purposes, using negation only makes sense if using the keyword ‘all’. However, if more movement types are added, with symbolic names that include several movement types (eg, MOVE_LAND), using the negation with those names may make sense.

Be aware that when the field is saved out, it may not be saved exactly as it was specified in the load file. This is because the server converts the string to an int at load time, then converts it back to a string.

Bitmask of above values which determines what form of movement this object uses. For objects equipped by player/monster, move_type grants that movement.

Note that move_type of MOVE_FLY (0×2) replaces FLAG_FLYING.

In general, creatures will only have 1 movement type active at a time.

Represents what movement types are unable to pass this space. If the creature has multiple movement types, they may still be able to pass the space. For example, a player has MOVE_WALK | MOVE_FLY. He tries to move onto a space that blocks MOVE_WALK - not a problem, a he just flies over.

This overrides move_block - basically, this allows movement of the specific type on the space, regardless of move_block of other objects on the space. This is most useful to set on objects that should temporary change the characteristics of the space.

These bitmasks represents for what movement types this object is activated on/off. Replaces the walk/fly_on/off values

Like move_block, but represents what movement types are slowed on this space. Note that it is not possible to specify different penalties for different movement types in the same object. However, multiple objects with different move_slow values (and penalties) can be put on the same space. This replaced FLAG_SLOW_MOVE, which is converted to only slow down walking movement.

How much the player is slowed down.

This value is a float (before it was an int converted to a float at load time). It is basically how much slower (percentage wise) the player moves through this terrain. A value of 0 is basically a non operation. A value of 0.5 means it takes 50% longer to move through the space. The old values were all positive ints. Basically, it effectively was how many ticks the player is slowed down by.

Certain terrain has skills which reduce the slow penalty (woodsmen in forest for example). As of this writing, the penalty is reduced to 1/4 of what it would be. Eg, a move_slow_penalty of 1.0 would say it takes twice as long to move through the space. If the player has appropriate skill, it would now only take that player 25% longer to move through the space.

Note 2: The old slow_move is loaded and converted into move_slow_penalty. The old SLOW_PENALTY and SET_SLOW_PENALTY macros divided/multiplied the result by 1000, so were basically a non operation. Since it is now just stored as a float, conversion macros are not needed or used.

Not related to this code - noted here since it has the move_ prefix. This is used to track monsters state of the attack_movement variable. It is worth noting that move_type was changed to attack_movement - this matches the name in the archetype, but is a name change in the object field.

If an object has move_block of move_slow and that affects the player movement, the objects message will be printed to the player - thus things like ‘The jungle slows you down’ or ‘The wall is in the way’ will be printed. Various hints can be contained in the messages.

This change of logic has resulted in the following fields no longer being used:

• FLAG_WALK_ON → move_on
• FLAG_NO_PASS → move_block
• FLAG_SLOW_MOVE → move_slow
• FLAG_FLYING → move_type
• FLAG_WALK_OFF → move_off
• FLAG_FLY_ON → move_on
• FLAG_FLY_OFF → move_off
• FLAG_PASS_THRU → was unused, would be move_type
• FLAG_CAN_PASS_THRU → was unused, would be move_type

Player can only pick up items if MOVE_WALK is set (this may need to be expanded down the road). Basic idea is that if you are flying, can’t reach the ground, if swimming, don’t really have any free hands to grab anything.

Those fields are kind of used by all objects, but aren’t really in the previous parts.

• death_animation (key/value): should point to a valid archetype name that will be inserted in the map when the object dies. It should probably be a one-time animation (is_used_up 1).

see doc/map-technical for this information.

(re-done code by Mark Wedel)

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. Meaning of the fields:

• level: To re-consecrate an altar, the players skill 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.
• other_arch: The god that this altar belongs to. This replaces the title field that used to be used.

by Peter Mardahl

The following describes some things about the archetype and implementation for diseases.

Explanations:

• * means this # should be negative to cause adverse effect.
• + means that this effect is modulated in spells by ldur
• % means that this effect is modulated in spells by ldam
• attacktype is the attacktype used by the disease to smite “dam” damage with.
• wc/127 is the chance of someone in range catching it.
• magic is the range at which infection may occur. If negative, this is not level dependent.
• Stats are stat modifications. These should typically be negative.
• maxhp is how long the disease will persist if the host dies and “drops” it, in “disease moves”, i.e., moves of the disease. If negative, permanent.
• value is the counter for maxhp, it starts at maxhp and drops...
• dam: if positive, it is straight damage. if negative, a %-age or victim’s hp.
• maxgrace how long in “disease moves” the disease lasts in the host, if negative, permanent until cured.
• food: if negative, disease is permanent. Otherwise, decreases at <speed>, disease goes away at food=0, set to “maxgrace” on infection.
• speed is the speed of the disease, how fast “disease moves” occur.
• last_sp is the lethargy imposed on the player by the disease. A lethargy of “1” reduces the players speed to 1% of its normal value.
• maxsp how much mana is sapped per “disease move”. if negative, a %-age is taken.
• ac: every “disease move” the severity of the symptoms are increased by ac/100. Therefore severity = 1 + (accumulated_progression)/100
• last_eat increases food usage if negative.
• last_grace: reduction in the diseases’ contagiousness every time it infects someone new. This limits how many generations a disease can propagate.

Missile weapons (type BOW) can be used to shoot missiles (type ARROW). The most common weapons are bows and crossbows but other weapons are also easy to implement (e.g. a sling). The following variables have the same meaning for both weapons and bullets:

These are used only for arrows:

These are for bows:

The other variables has their normal meanings.

by Peterm

A creator is an object which creates another object when it is triggered. The daughter object can be anything. (yet another way other than runes to create surprise monsters, though runes are better for that, they’re smarter at placing monsters)

You’ve seen a creator demonstrated if you’ve solved the Tower of Demonology: when you summon a demon you also get some firetrails

Creator object: an object which creates other objects. It is usually invisible.

by Peterm

Player movers are objects which move objects above them. These objects must be alive. They are directional, so players can be made to move in a pattern, and so can monsters.

Motion is involuntary. Additionally, players or monsters can be paralyzed so that they MUST move