[Crossfire-wiki] [Crossfire DokuWiki] page changed: dev:objects

[no-reply_wiki at metalforge.org]

A page in your DokuWiki was added or changed. Here are the details:

Date        : 2007/12/27 13:30
User        : kbulgrien
Edit Summary: Minor archetype related edits and new link for object types.

@@ -4,19 +4,20 @@
  
  FIXME rename to ''archetype''? merge info with [[dev:object fields]]. document all ''type'' and ''subtype''. fix & check everything
  
  ======  How to create new archetypes and bitmaps ======
-   - Determine if you really need a new archetype.  Archetypes are only needed if you are adding new images, or the archetype you are creating will be of general interest.  Don't make a new arch if all you really need to do     is customize an existing archetype.
-   - Figure out which directory/category the object will belong to.  This will determine the appropriate location for it inside the 'arch' directory.  For objects with many animations or that are very large, you may want to make a new subdirectory.
-   - Create a bitmap.  It must be dividable by 32 in both height and width. The file format should be .PNG 256 colour and use transparency.
-   - create additional bitmaps if you want animation or directional facing.
-   - split the bitmaps up into 32x32 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. (you can use the script "splitxbm" which is included below).
-   - Create an archetype entry.  The file should be called object.arc, where object is whatever the new object is.     This is by far the most complicated step.  First read "crossfire.doc" for an introduction on how to create archetypes. 
-     * Look at other similarly archetypes to see how they have been done.
-     * If you only made one 32x32 bitmap, you will only need one archetype, but if you made a larger bitmap which is cut down to several 32x32 bitmaps, you will need to use "linked" archetypes.  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 these multipart objects, in most cases, only the values in the head portion are used (eg, hp, damage, etc for monsters).
+ 
+   - 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.
+   - 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.
+   - Create a bitmap.  It must be divisible by 32 in both height and width. The file format should be .PNG 256 colour with transparency.
+   - Create additional bitmaps if you want animation or directional facing.
+   - Split the bitmaps up into 32x32 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).
+   - 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 32x32 bitmap is created, only one archetype is needed, but if a larger bitmap is made which is cut down to several 32x32 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.
-   - If your archetype is a creature or NPC you might want to give it abilities such as firebreathing or magical attacks.  You put these abilities into the treasures file in the appropriate entry as invisible objects. This is also how you can give inventory like bows or swords as well.  Look at the other entries in the treasures file for the format. Note that if an existing entry in the treasures file does what you want, use it for your new archetype.  There is no requirement that each archetype has a unique treasure list.
+   - 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.
  
  ===== What is an archetype and what is an object? =====
  
  Objects are directly derived from archetypes.  Everything the player sees in the game is an object.  The player never deals with archetypes.
@@ -169,9 +170,8 @@
  
  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.
- 
  
  
  ===== Using other objects (will_apply) =====
  
@@ -194,10 +194,9 @@
  
  Treasure lists are also used to give spell and skill abilities to creatures.
  
  
- 
- ===== Usage of certain flags for monsters =====
+ =====Monster Flag Usage=====
  
  ==== Damage (dam) ====
  
  Damage determines the amount of damage the creature does.  The form this
@@ -455,46 +454,46 @@
  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).
- 
- 
  
  
  ===== Types (type) & Subtypes (subtype) =====
  
- Specified in defines.h.  A type determines how an item operates/what it does. A type only needs to be added for a new archetype if in some area of the program, it is actually used.  Addition of new types is generally a rare event.
+ Specified in defines.h, the type field determines how an item operates/what it does.
  
- For example, if adding a new monster, there is no need to add a new type in defines.h if crossfire never checks the type element in the object structure for that new type.
+ 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.  Note that within maps, you should almost never change the type field of an object - instead, you should start with an object of the appropriate type and change the fields of the object to appear as you want it.
+ 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 [[dev: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, how do I know if I need a new type, or if I should be the subtype of an existing type.
+ The question may then be asked - when making a new arch, when is a new type is needed as opposed to a new subtype?
  
  When to add a new type:
    - If code to support applying the object is completely different than what exists in apply.c (eg, not reusing existing functions), or
    - If code to support movement of the type does not reuse existing functions (server/time.c)
  
  When to make a new subtype:
-   - Your behaviour is _close_ to that of an existing type, but you want it to be slightly different (eg, teleporters that don't work on players), or
-   - You need to be able to differentiate between objects of the same type. Eg, adding a new skill would add a new subtype, not a new type.
+   - New behavior is _close_ to that of an existing type, but is slightly different (eg, teleporters that don't work on players), or
+   - 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.
  
- If your not sure, drop a mail to the crossfire developers list.
+ 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 Types (client_type) =====
  
- Client type information in public information communicated to the client. Client type differes from the type in several ways:
+ Client type information in public information communicated to the client. Client type differs from the type in several ways:
  
    - It is more specific than the type information.
    - The numbers used for client type are more logically grouped (all armor related client_types are in the same range)
    - 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.


IP-Address  : 70.254.39.97
Old Revision: http://wiki.metalforge.net/doku.php/dev:objects?rev=1198121966
New Revision: http://wiki.metalforge.net/doku.php/dev:objects

-- 
This mail was generated by DokuWiki at
http://wiki.metalforge.net/