--- deliantra/server/doc/Developers/objects 2006/02/03 07:12:32 1.1.1.1 +++ deliantra/server/doc/Developers/objects 2006/02/22 18:01:46 1.1.1.2 @@ -47,6 +47,7 @@ M. Signs N. POISONOUS BOOZ O. Duplicators + P. Transports 5. Flags & specifications for objects @@ -1092,12 +1093,55 @@ #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_ALL 0xf; /* Mask of all movement types */ +#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 maintability in the future. For example, if you +specify 'move_block 15' right now, that is equivalant 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, seperated by a space. In addition, a - (minus) can precede the name, +which means to negate that type. These are all equivalant: + +move_block 6 +move_block fly_low fly_low +move_block flying (special symbolic name) +move_block all -swim -walk + +Note the order when using the -(negation) is important - the string is parsed +left to right. This is not equivalant to the above: + +move_block -swim -walk all + +Because it will clear the swim and walk 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. + +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The fields in the object themselves: move_type: Bitmask of above values which determines what form of movement @@ -1114,6 +1158,11 @@ He tries to move onto a space that blocks MOVE_WALK - not a problem, a he just flies over. +move_allow: 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. + move_on/move_off: Take bitmasks - represents for what movement types this object is activated on. Replaces the walk/fly_on/off values @@ -1730,6 +1779,93 @@ unaffected. If the lever it is connected to is not pulled, it is also unaffected. +P. Transports: +============== + +Tranports are objects that help the player move. These should not be confused +with EXITS, which instaneously transport a player from one map to another. + +Instead, tranports may let the player move faster, give them move types they +don't have, etc. A simple example of this would a horse. It doesn't let the +player move anyplace he normally couldn't go, but lets him get there faster. +Ships would be another case - the player normally can't move accross water, +but with a ship, he can. + +Meaning of various object attributes (KV means the value is stored in the +key/value list, and thus the get_ob_key_value() and set_ob_key_value() +routines need to be used. + +move_type The move type this object has. +move_allow Normal meanings - useful for things like boats so people + can actually get on the boat. +speed How fast the object moves +weight_limit How much this object can carry. +weight_speed_ratio (KV) + This value is taken as a percentage which is multiplied + against against the weight this object is carrying (the + player) - this is then divided by weight_limit to determine + the effective loading to determine effective object speed, eg: + + speed = base_speed - (base_speed * pl->weight * + weight_speed_ratio) / (weight_limit * 100) + + Thus, if weight_factor is 0, this object will move the same + speed no matter how loaded it is. If it is 100, then + if the transport is fully loaded, it moves at a crawl. + In a sense, this somewhat mimics the player movement + speed. Large transports, like boats, should likely be + largely unaffected by weight (maybe have this value at + 10), where something like a horse would have a relatively high + value. + +base_speed(KV) This is only needed if weight_speed_ratio is set - it is used + to know what the base speed to use in the calculation (since + speed is getting clobbered). If this is not set and + weight_speed_ratio is set, the archetypes speed will be used. + +passenger_limit(KV) + How many players this transport can hold. Thus, boats can + transport a party (this being set to 6) while horses could + only transport a single person. If this is not set, a default + of 1 will be used. + +face_full + It may be desirable to have different faces to denote what + the tranport looks like if someone is on it vs not (mounted + horse vs just a horse). This is used to denote what it will + look like when loaded. If the tranport becomes empty, it will + fall back to the archetype face. + +anim_full Like face_full above, but for animated objects. + +Usage/implementation details: +To activate a transport, the player will apply it just like any other object. +When this is done, the pl->contr->transport will point to the transport. +If the player is the first to board it, then transport->contr will point to the +player. The player is placed into the inventory of the transport. + +When on the transport, the player will see other objects on the transport. +When the player issues a map command, if they are the 'captain', the +tranport moves as directed. If not, the move command is ignored. Note +that players on the transport can issue other commands (say, cast, etc). + +Some special handling is done relating the player and transport speed so that +transport speed is used. IF the transport doesn't have speed to move, +the move command is ignored. The player speed_left is set to -0.01 when +on the transport - in this way, the player will get actions and not limit +transport speed. + +When aboard a transport, the player will be in the inventory of the transport. +The player can see other objects in the transport. If the player drops an +item, it is placed into the transport inventory, and not the map. + +When hit_map() hits the transport, we examine look for all players in the +transport and damage them as appropriate. Note that items are not +damaged. + +As of this writing, transports are non living creatures, and thus can't +be damaged. + ******************************************************************************* 5. Flags & specifications: (usage: flag value) ******************************************************************************