[ViewVC] Diff of: cvs/deliantra/server/doc/Developers/objects

Comparing deliantra/server/doc/Developers/objects (file contents):
Revision 1.1.1.1 by root, Fri Feb 3 07:12:32 2006 UTC vs.
Revision 1.1.1.2 by elmex, Wed Feb 22 18:01:46 2006 UTC

…		…
45	K. Mood Floors	45	K. Mood Floors
46	L. Altars, Triggers, Detectors and other connected items	46	L. Altars, Triggers, Detectors and other connected items
47	M. Signs	47	M. Signs
48	N. POISONOUS BOOZ	48	N. POISONOUS BOOZ
49	O. Duplicators	49	O. Duplicators
		50	P. Transports
50		51
51	5. Flags & specifications for objects	52	5. Flags & specifications for objects
52		53
53	6. TREASURES	54	6. TREASURES
54		55
…		…
1090	#define MOVE_WALK 0x1 /* Object walks */	1091	#define MOVE_WALK 0x1 /* Object walks */
1091	#define MOVE_FLY_LOW 0x2 /* Low flying object */	1092	#define MOVE_FLY_LOW 0x2 /* Low flying object */
1092	#define MOVE_FLY_HIGH 0x4 /* High flying object */	1093	#define MOVE_FLY_HIGH 0x4 /* High flying object */
1093	#define MOVE_FLYING 0x6 /* combo of fly_low and fly_high for easier checking */	1094	#define MOVE_FLYING 0x6 /* combo of fly_low and fly_high for easier checking */
1094	#define MOVE_SWIM 0x8 /* Swimming object */	1095	#define MOVE_SWIM 0x8 /* Swimming object */
		1096	#define MOVE_BOAT 0x10 /* Boats/sailing */
1095	#define MOVE_ALL 0xf; /* Mask of all movement types */	1097	#define MOVE_ALL 0x1f /* Mask of all movement types */
1096		1098
1097	MOVE_ALL may change in the future - it is mask for all movement types -	1099	MOVE_ALL may change in the future - it is mask for all movement types -
1098	used for 'no_pass' - it sets move_block to MOVE_ALL, other places that	1100	used for 'no_pass' - it sets move_block to MOVE_ALL, other places that
1099	check for all movement types may also use this value.	1101	check for all movement types may also use this value.
1100		1102
		1103	It is possible to use string names instead of the numeric bitmask in
		1104	the move_fields below. It is strongly encouraged that the string names be
		1105	used for improved readability. In addition, using string names, especially
		1106	'all', will result in easier maintability in the future. For example, if you
		1107	specify 'move_block 15' right now, that is equivalant of all. However, if new
		1108	move types are added, using a numeric option will not block the new movement
		1109	types, where if 'move_block all' was used, it continue to block everything.
		1110
		1111	The string names are same as the MOVE_ defines, but with the MOVE_ portion
		1112	removed, eg, 'walk', 'fly_low', 'fly_high', etc. Multiple types can be
		1113	listed, seperated by a space. In addition, a - (minus) can precede the name,
		1114	which means to negate that type. These are all equivalant:
		1115
		1116	move_block 6
		1117	move_block fly_low fly_low
		1118	move_block flying (special symbolic name)
		1119	move_block all -swim -walk
		1120
		1121	Note the order when using the -(negation) is important - the string is parsed
		1122	left to right. This is not equivalant to the above:
		1123
		1124	move_block -swim -walk all
		1125
		1126	Because it will clear the swim and walk flags, and then set the flags to all.
		1127
		1128	Also, using only negation is not allowed - you can not do:
		1129
		1130	move_block -walk
		1131
		1132	To indicate you want to remove only the walk blocking from the archetype -
		1133	you must include a positive indicator.
		1134
		1135	For all practical purposes, using negation only makes sense if using the
		1136	keyword 'all'. However, if more movement types are added, with symbolic names
		1137	that include several movement types (eg, MOVE_LAND), using the negation with
		1138	those names may make sense.
		1139
		1140	Be aware that when the field is saved out, it may not be saved exactly as it
		1141	was specified in the load file. This is because the server converts the
		1142	string to an int at load time, then converts it back to a string.
		1143
		1144	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1101	The fields in the object themselves:	1145	The fields in the object themselves:
1102		1146
1103	move_type: Bitmask of above values which determines what form of movement	1147	move_type: Bitmask of above values which determines what form of movement
1104	this object uses. For objects equipped by player/monster, move_type grants	1148	this object uses. For objects equipped by player/monster, move_type grants
1105	that movement.	1149	that movement.
…		…
1111	move_block: Represents what movement types are unable to pass this space.	1155	move_block: Represents what movement types are unable to pass this space.
1112	If the creature has multiple movement types, they may still be able	1156	If the creature has multiple movement types, they may still be able
1113	to pass the space. For example, a player has MOVE_WALK \| MOVE_FLY.	1157	to pass the space. For example, a player has MOVE_WALK \| MOVE_FLY.
1114	He tries to move onto a space that blocks MOVE_WALK - not a problem,	1158	He tries to move onto a space that blocks MOVE_WALK - not a problem,
1115	a he just flies over.	1159	a he just flies over.
		1160
		1161	move_allow: This overrides move_block - basically, this allows movement
		1162	of the specific type on the space, regardless of move_block of other
		1163	objects on the space. This is most useful to set on objects that
		1164	should temporary change the characteristics of the space.
1116		1165
1117	move_on/move_off: Take bitmasks - represents for what movement types	1166	move_on/move_off: Take bitmasks - represents for what movement types
1118	this object is activated on. Replaces the walk/fly_on/off values	1167	this object is activated on. Replaces the walk/fly_on/off values
1119		1168
1120	move_slow: Like move_block, but represents what movement types are slowed	1169	move_slow: Like move_block, but represents what movement types are slowed
…		…
1727		1776
1728	Where 5 is connected to a lever. When the lever is pulled, if a sword object	1777	Where 5 is connected to a lever. When the lever is pulled, if a sword object
1729	is on top, its number is doubled. If there is anything else on top, it is	1778	is on top, its number is doubled. If there is anything else on top, it is
1730	unaffected. If the lever it is connected to is not pulled, it is also	1779	unaffected. If the lever it is connected to is not pulled, it is also
1731	unaffected.	1780	unaffected.
		1781
		1782	P. Transports:
		1783	==============
		1784
		1785	Tranports are objects that help the player move. These should not be confused
		1786	with EXITS, which instaneously transport a player from one map to another.
		1787
		1788	Instead, tranports may let the player move faster, give them move types they
		1789	don't have, etc. A simple example of this would a horse. It doesn't let the
		1790	player move anyplace he normally couldn't go, but lets him get there faster.
		1791	Ships would be another case - the player normally can't move accross water,
		1792	but with a ship, he can.
		1793
		1794	Meaning of various object attributes (KV means the value is stored in the
		1795	key/value list, and thus the get_ob_key_value() and set_ob_key_value()
		1796	routines need to be used.
		1797
		1798	move_type The move type this object has.
		1799	move_allow Normal meanings - useful for things like boats so people
		1800	can actually get on the boat.
		1801	speed How fast the object moves
		1802	weight_limit How much this object can carry.
		1803	weight_speed_ratio (KV)
		1804	This value is taken as a percentage which is multiplied
		1805	against against the weight this object is carrying (the
		1806	player) - this is then divided by weight_limit to determine
		1807	the effective loading to determine effective object speed, eg:
		1808
		1809	speed = base_speed - (base_speed * pl->weight *
		1810	weight_speed_ratio) / (weight_limit * 100)
		1811
		1812	Thus, if weight_factor is 0, this object will move the same
		1813	speed no matter how loaded it is. If it is 100, then
		1814	if the transport is fully loaded, it moves at a crawl.
		1815	In a sense, this somewhat mimics the player movement
		1816	speed. Large transports, like boats, should likely be
		1817	largely unaffected by weight (maybe have this value at
		1818	10), where something like a horse would have a relatively high
		1819	value.
		1820
		1821	base_speed(KV) This is only needed if weight_speed_ratio is set - it is used
		1822	to know what the base speed to use in the calculation (since
		1823	speed is getting clobbered). If this is not set and
		1824	weight_speed_ratio is set, the archetypes speed will be used.
		1825
		1826	passenger_limit(KV)
		1827	How many players this transport can hold. Thus, boats can
		1828	transport a party (this being set to 6) while horses could
		1829	only transport a single person. If this is not set, a default
		1830	of 1 will be used.
		1831
		1832	face_full
		1833	It may be desirable to have different faces to denote what
		1834	the tranport looks like if someone is on it vs not (mounted
		1835	horse vs just a horse). This is used to denote what it will
		1836	look like when loaded. If the tranport becomes empty, it will
		1837	fall back to the archetype face.
		1838
		1839	anim_full Like face_full above, but for animated objects.
		1840
		1841	Usage/implementation details:
		1842	To activate a transport, the player will apply it just like any other object.
		1843	When this is done, the pl->contr->transport will point to the transport.
		1844	If the player is the first to board it, then transport->contr will point to the
		1845	player. The player is placed into the inventory of the transport.
		1846
		1847	When on the transport, the player will see other objects on the transport.
		1848	When the player issues a map command, if they are the 'captain', the
		1849	tranport moves as directed. If not, the move command is ignored. Note
		1850	that players on the transport can issue other commands (say, cast, etc).
		1851
		1852	Some special handling is done relating the player and transport speed so that
		1853	transport speed is used. IF the transport doesn't have speed to move,
		1854	the move command is ignored. The player speed_left is set to -0.01 when
		1855	on the transport - in this way, the player will get actions and not limit
		1856	transport speed.
		1857
		1858	When aboard a transport, the player will be in the inventory of the transport.
		1859	The player can see other objects in the transport. If the player drops an
		1860	item, it is placed into the transport inventory, and not the map.
		1861
		1862	When hit_map() hits the transport, we examine look for all players in the
		1863	transport and damage them as appropriate. Note that items are not
		1864	damaged.
		1865
		1866	As of this writing, transports are non living creatures, and thus can't
		1867	be damaged.
1732		1868
1733	*******************************************************************************	1869	*******************************************************************************
1734	5. Flags & specifications: (usage: flag value)	1870	5. Flags & specifications: (usage: flag value)
1735	******************************************************************************	1871	******************************************************************************
1736	Note: the flags are case sensitive.	1872	Note: the flags are case sensitive.

Diff Legend

-–
+Removed lines
-+
+Added lines
-<
+Changed lines
->
+Changed lines

Comparing deliantra/server/doc/Developers/objects (file contents): Revision 1.1.1.1 by root, Fri Feb 3 07:12:32 2006 UTC vs. Revision 1.1.1.2 by elmex, Wed Feb 22 18:01:46 2006 UTC

Diff Legend

Comparing deliantra/server/doc/Developers/objects (file contents):
Revision 1.1.1.1 by root, Fri Feb 3 07:12:32 2006 UTC vs.
Revision 1.1.1.2 by elmex, Wed Feb 22 18:01:46 2006 UTC