1 |
|
2 |
|
3 |
This files so far only concernes how to make archetypes,treasure and NPC's |
4 |
|
5 |
Sections: |
6 |
|
7 |
1. How to create new Archetypes and Bitmaps |
8 |
|
9 |
2 Things that are alive (monsters, npcs) |
10 |
A. Attack Types (attacktytpe) |
11 |
B. Immunity (immune) (protected) (vulnerable) |
12 |
C. NPC Movement (attack_movement) |
13 |
D. Picking up other items (pick_up) |
14 |
E. Using other objects (will_apply) |
15 |
F. Treasure lists (randomitems) |
16 |
G. Usage of certain flags for monsters |
17 |
H. NPC's and their life - behaviours |
18 |
I. NPC's Speak out - messages |
19 |
|
20 |
3. Objects in general |
21 |
A. Names (name, name_pl) |
22 |
B. Types (type) & Subtypes (subtype) |
23 |
C. Client Types (client_type) |
24 |
D. editable field (editable) |
25 |
E. Animations (anim - mina) (facings) |
26 |
F. Material types (material) |
27 |
G. Item Power (item_power) |
28 |
H. Body Location |
29 |
I. Meaning of certain attributes for certain items: |
30 |
J. Lore |
31 |
K. Movement types |
32 |
|
33 |
4. SPECIAL OBJECTS |
34 |
|
35 |
A. MAPS |
36 |
B. HOLY_ALTARS |
37 |
C. DISEASES |
38 |
D. CONVERTERS |
39 |
E. BOWS & ARROWS -missile weapons |
40 |
F. Creators -object creating objects |
41 |
G. Player Movers |
42 |
H. Directors |
43 |
I. Magical Walls -walls that cast spells |
44 |
J. Containers |
45 |
K. Mood Floors |
46 |
L. Altars, Triggers, Detectors and other connected items |
47 |
M. Signs |
48 |
N. POISONOUS BOOZ |
49 |
O. Duplicators |
50 |
|
51 |
5. Flags & specifications for objects |
52 |
|
53 |
6. TREASURES |
54 |
|
55 |
7. Misc change description |
56 |
|
57 |
8. How to Add new values |
58 |
|
59 |
9. Programming notes |
60 |
|
61 |
******************************************************************************* |
62 |
1. HOW TO CREATE NEW ARCHETYPES AND BITMAPS: |
63 |
******************************************************************************** |
64 |
0) Determine if you really need a new archetype. Archetypes are only needed |
65 |
if you are adding new images, or the archetype you are creating will be |
66 |
of general interest. Don't make a new arch if all you really need to do |
67 |
is customize an existing archetype. |
68 |
1) Figure out which directory/category the object will belong to. This |
69 |
will determine the appropriate location for it inside the 'arch' |
70 |
directory. For objects with many animations or that are very large, |
71 |
you may want to make a new subdirectory. |
72 |
2) Create a bitmap. It must be dividable by 32 in both height and width. |
73 |
The file format should be .PNG 256 colour and use transparancy. |
74 |
3) create additional bitmaps if you want animation or directional facing. |
75 |
4) split the bitmaps up into 32x32 bitmaps and named according to the |
76 |
naming.doc conventions in the arch tar package. Note, this |
77 |
is not really necessary at current time - non splitted images should |
78 |
work properly, but some older clients may have problems with it. |
79 |
(you can use the script "splitxbm" which is included below). |
80 |
5) Create an archetype entry. The file should be called |
81 |
object.arc, where object is whatever the new object is. |
82 |
This is by far the most complicated step. First read "crossfire.doc" for |
83 |
an introduction on how to create archetypes. |
84 |
Look at other similary archetypes to see how they have been done. |
85 |
If you only made one 32x32 bitmap, you will only need one archetype, but |
86 |
if you made a larger bitmap which is cut down to several 32x32 bitmaps, |
87 |
you will need to use "linked" archetypes. To create a linked archetype, |
88 |
add a 'More' line filed by the next piece. The X and Y coordinates in |
89 |
this next piece determine the offset from the head (first) object. |
90 |
When making multipart objects, they should be rectangular. Non rectangular |
91 |
may work, but has not been tested. |
92 |
|
93 |
Note that for these multipart objects, in most cases, only the values |
94 |
in the head portion are used (eg, hp, damage, etc for monsters). |
95 |
|
96 |
See the section later in this document about animations. |
97 |
|
98 |
6) If your archetype is a creature or NPC you might want to give it |
99 |
abilities such as firebreathing or magical attacks. You put these |
100 |
abilities into the treasures file in the appropriate entry as invisible |
101 |
objects. This is also how you can give inventory like bows or swords |
102 |
as well. Look at the other entries in the treasures file for the format. |
103 |
Note that if an existing entry in the treasures file does what you |
104 |
want, use it for your new archetype. There is no requirement that |
105 |
each archetype has a unique treasure list. |
106 |
|
107 |
------------------------------------------------------------------------------ |
108 |
What is an archetype and what is an object? |
109 |
|
110 |
Objects are directly derived from archetypes. Everything the player |
111 |
sees in the game is an object. The player never deals with archetypes. |
112 |
|
113 |
Archetypes are the master objects. All objects have an archetype that they |
114 |
are derived from. When an object is created, the archetype is used for |
115 |
all the default values in the object. When an object is saved, the code |
116 |
looks at the differences between the archetype and the object it is saving, |
117 |
and only changes the different values. |
118 |
|
119 |
Archetypes are the entries in the 'arch' directory. The fields for |
120 |
archetypes and objects are generally the same. |
121 |
|
122 |
Note that by using this archetype model, it means an archetype can get |
123 |
updated and all objects that are derived from it will get updated - |
124 |
this is very useful when new fields are added - the archetypes can get |
125 |
updated, and all objects in maps, player save files, wherever, get |
126 |
this new value. |
127 |
|
128 |
******************************************************************************* |
129 |
2. Things that are alive |
130 |
******************************************************************************* |
131 |
|
132 |
The name in parantheses after a flag description is the name as it should be |
133 |
used in the archetype file. For example: Attack type (attacktype) |
134 |
|
135 |
|
136 |
A. Attack Types (attacktype) |
137 |
=============== |
138 |
|
139 |
|
140 |
Attack types bit description |
141 |
|
142 |
Physical 1 Basic attacktype. |
143 |
Magic 2 All magic spells, but not prayers |
144 |
Fire 4 Can ignite objects |
145 |
Electricity 8 Can also ignite objects |
146 |
Cold 16 Can freeze objects into ice cubes |
147 |
Confusion 32 Movement/attack directions become random |
148 |
Acid 64 Random equipped item gets -1 to magic attribute |
149 |
Drain 128 Victim loses 2% exp, attacker gains half of that |
150 |
Weaponmagic 256 Direct damage: Special, use with care |
151 |
Ghosthit 512 Attacker dissolves (obsolete) |
152 |
Poison 1024 Some damage each turn thereafter |
153 |
Slow 2048 Speed is reduced |
154 |
Paralyze 4096 Speed is reduced to zero |
155 |
Turn undead 8192 Like Fear, but for undead only |
156 |
Fear 16384 Like Turn Undead, but for living only |
157 |
Cancellation 32768 Removes magic (+/-) from items |
158 |
Depletion 65536 Lose one point from one stat (can be restored) |
159 |
Death 131072 Chance of instant death, otherwise nothing |
160 |
Chaos 262144 None by itself, uses random other types |
161 |
Counterspell 524288 Cancels magic spells |
162 |
Godpower 1048576 Adds relevant god's attacktype |
163 |
Holy Word 2097152 Enemies: X5, Undead: X1 -unless friends, others: none |
164 |
Blind 4194304 Blinds victim |
165 |
|
166 |
Note that one archetype can have multiple attack types by adding |
167 |
these values together. Thus, something with an attacktype of 65 |
168 |
would attack with both acid and physical. |
169 |
|
170 |
B. Resistances |
171 |
=========== |
172 |
|
173 |
Creatures can have various resistances. If a creature has a resistance |
174 |
value for a particular attacktype of 100, it is said to be immune |
175 |
to that attacktype. The amount of resistance directly reduces |
176 |
damage. A creature that has 25% resistance to fire only takes 75% |
177 |
of the damage. A creature 99% resistant only takes 1% of the damage. |
178 |
|
179 |
A few notes: If a creature/object is immune to magic, then it will be |
180 |
immune to all damage from that attack, even if that attack type contains |
181 |
more than just magic. |
182 |
|
183 |
Otherwise, a creature needs to be immune to all attack types in order |
184 |
to take no damage (thus, a creature that is immune to physical, but |
185 |
getting hit by a weapon that does physical and fire would take normal |
186 |
damage). The attack code goes through all the attacktypes, and |
187 |
calculates the damage that each will cause. It uses the highest damage |
188 |
total that any of these attacktypes will use. |
189 |
|
190 |
For attacktypes that don't deal phyiscal damage but instead effect |
191 |
the creature in some way (drain, slow, paralyze, etc), the resistance |
192 |
in general reduces the effect (duration, amount drained, etc). |
193 |
|
194 |
C. NPC Movement (attack_movement) |
195 |
=============== |
196 |
|
197 |
Set the variable attack_movement to one of the below (cut from define.h): |
198 |
/******************************************************************************/ |
199 |
/* Monster Movements added by kholland@sunlab.cit.cornell.edu */ |
200 |
/******************************************************************************/ |
201 |
/* if your monsters start acting wierd, mail me */ |
202 |
/******************************************************************************/ |
203 |
/* the following definitions are for the attack_movement variable in monsters */ |
204 |
/* if the attack_variable movement is left out of the monster archetype, or is*/ |
205 |
/* set to zero */ |
206 |
/* the standard mode of movement from previous versions of crossfire will be */ |
207 |
/* used. the upper four bits of movement data are not in effect when the monst*/ |
208 |
/* er has an enemy. these should only be used for non agressive monsters. */ |
209 |
/* to program a monsters movement add the attack movement numbers to the movem*/ |
210 |
/* ment numbers example a monster that moves in a circle until attacked and */ |
211 |
/* then attacks from a distance: */ |
212 |
/* CIRCLE1 = 32 */ |
213 |
/* + DISTATT = 1 */ |
214 |
/* ------------------- */ |
215 |
/* attack_movement = 33 */ |
216 |
/******************************************************************************/ |
217 |
#define DISTATT 1 /* move toward a player if far, but mantain some space, */ |
218 |
/* attack from a distance - good for missile users only */ |
219 |
#define RUNATT 2 /* run but attack if player catches up to object */ |
220 |
#define HITRUN 3 /* run to then hit player then run away cyclicly */ |
221 |
#define WAITATT 4 /* wait for player to approach then hit, move if hit */ |
222 |
#define RUSH 5 /* Rush toward player blindly, similiar to dumb monster */ |
223 |
#define ALLRUN 6 /* always run never attack good for sim. of weak player */ |
224 |
#define DISTHIT 7 /* attack from a distance if hit as recommended by Frank */ |
225 |
#define WAIT2 8 /* monster does not try to move towards player if far */ |
226 |
/* maintains comfortable distance */ |
227 |
#define PETMOVE 16 /* if the upper four bits of attack_movement */ |
228 |
/* are set to this number, the monster follows a player */ |
229 |
/* until the owner calls it back or off */ |
230 |
/* player followed denoted by 0b->owner */ |
231 |
/* the monster will try to attack whatever the player is */ |
232 |
/* attacking, and will continue to do so until the owner */ |
233 |
/* calls off the monster - a key command will be */ |
234 |
/* inserted to do so */ |
235 |
#define CIRCLE1 32 /* if the upper four bits of attack_movement */ |
236 |
/* are set to this number, the monster will move in a */ |
237 |
/* circle until it is attacked, or the enemy field is */ |
238 |
/* set, this is good for non-aggressive monsters and NPC */ |
239 |
#define CIRCLE2 48 /* same as above but a larger circle is used */ |
240 |
#define PACEH 64 /* The Monster will pace back and forth until attacked */ |
241 |
/* this is HORIZONTAL movement */ |
242 |
#define PACEH2 80 /* the monster will pace as above but the length of the */ |
243 |
/* pace area is longer and the monster stops before */ |
244 |
/* changing directions */ |
245 |
/* this is HORIZONTAL movement */ |
246 |
#define RANDO 96 /* the monster will go in a random direction until */ |
247 |
/* it is stopped by an obstacle, then it chooses another */ |
248 |
/* direction. */ |
249 |
#define RANDO2 112 /* constantly move in a different random direction */ |
250 |
#define PACEV 128 /* The Monster will pace back and forth until attacked */ |
251 |
/* this is VERTICAL movement */ |
252 |
#define PACEV2 144 /* the monster will pace as above but the length of the */ |
253 |
/* pace area is longer and the monster stops before */ |
254 |
/* changing directions */ |
255 |
/* this is VERTICAL movement */ |
256 |
#define LO4 15 /* bitmasks for upper and lower 4 bits from 8 bit fields */ |
257 |
#define HI4 240 |
258 |
|
259 |
|
260 |
D.Picking up other items (pick_up) |
261 |
======================== |
262 |
|
263 |
Pick Up specifiers (defined with pick_up) |
264 |
|
265 |
Nothing 1 |
266 |
Wealth 2 |
267 |
Food 4 |
268 |
Weapon 8 |
269 |
Armour 16 |
270 |
All but those defined 32 |
271 |
All 64 |
272 |
|
273 |
Note also that if can_use_armor, can_use_weapon, can_use_ring, |
274 |
can_use_wand, can_cast_spell, can_use_bow are set, then the creature |
275 |
will pick up the matching items even if the pick_up element is not |
276 |
set to pick up those items. |
277 |
|
278 |
This only applies to monsters. The player pickup method is much different. |
279 |
|
280 |
|
281 |
E. Using other objects (will_apply) |
282 |
====================== |
283 |
|
284 |
specifiers will apply this |
285 |
1 Handles |
286 |
2 Treasure (chests) |
287 |
4 Earthwall (tear down) |
288 |
8 Door (open) */ |
289 |
|
290 |
|
291 |
F. Treasure lists (randomitems) |
292 |
================= |
293 |
|
294 |
This determines what treasurelist to use for generating the objects |
295 |
treasures. For archetypes, the default is none, but for other objects |
296 |
(like those loaded in maps), it will use the same treasure list as |
297 |
the archetype it descends from unless otherwise specified. In the case |
298 |
of objects, "none" can be be used to make no items generated. |
299 |
|
300 |
The format of treasurelists is detailed further down in this file. |
301 |
|
302 |
Treasure lists are also used to give spell and skill abilities to creatures. |
303 |
|
304 |
|
305 |
|
306 |
G. Usage of certain flags for monsters |
307 |
====================================== |
308 |
|
309 |
Damage (dam) |
310 |
====== |
311 |
Damage determines the amount of damage the creature does. The form this |
312 |
damage takes it determined by the attacktype the creature has. |
313 |
|
314 |
When determining damage, a number between 1 and the damage value is |
315 |
rolled. Thus, even if you have a +6 damage bonus from strength, magic |
316 |
weapons, etc, a value of 1 could still be generated. Thus, even with very |
317 |
high magical monsters or very high strength monsters, a low damage roll can |
318 |
result some of the time. |
319 |
|
320 |
Speed (speed) |
321 |
===== |
322 |
Speed. A speed of 1.0 means it acts every tick, a speed of 0.1 |
323 |
means it acts every 10 ticks. |
324 |
|
325 |
level (level) |
326 |
===== |
327 |
|
328 |
Int (int) |
329 |
=== |
330 |
gives monsters a modifying to find hidden/invisible creatures. |
331 |
|
332 |
Pow (pow) |
333 |
=== |
334 |
If the creature can cast spells, this is how many spell points |
335 |
are regenerated each move. |
336 |
|
337 |
Con (con) |
338 |
=== |
339 |
Monsters regenerate this many hit points each move. This is each |
340 |
time the monster has a move (some for Pow). So two monsters with the |
341 |
same Con can regenerate at different rates if their speeds are different. |
342 |
|
343 |
Wis (wis) |
344 |
=== |
345 |
Determines how close a player needs to be before the creature wakes |
346 |
up. This is done as a square, for reasons of speed. Thus, if the wisdom is |
347 |
11, any player that moves within the 11x11 square of the monster will wake |
348 |
the monster up. If the player has stealth, the size of this square is |
349 |
reduced in half plus 1. |
350 |
|
351 |
Spell points (sp) |
352 |
============ |
353 |
Number of spell points monster starts with |
354 |
|
355 |
maxsp (maxsp) |
356 |
===== |
357 |
Maximum spellpoints for monsters |
358 |
|
359 |
flying (flying) |
360 |
====== |
361 |
set flying to 1 if this can fly. |
362 |
|
363 |
See Invisible (see_invisible) |
364 |
============= |
365 |
|
366 |
See in the dark (can_see_in_dark) |
367 |
=============== |
368 |
|
369 |
Spell reflection (reflect_spell) |
370 |
================ |
371 |
Very powerful, use carefully |
372 |
|
373 |
Pass through (can_pass_thru) |
374 |
============ |
375 |
|
376 |
Kamakaze attacks (one_hit) |
377 |
================ |
378 |
set to 1 if this creature disapates on attacking (like ghosts) |
379 |
|
380 |
Morale (run_away) |
381 |
====== |
382 |
|
383 |
Use objects (can_use) |
384 |
=========== |
385 |
What objects the creature can use. Note that this has largely been |
386 |
replaced with the body location information (see further down). |
387 |
The ones that should in general be used are can_use_shield, can_use_weapon, |
388 |
and can_use_bow. the others are likely to be obsoleted. |
389 |
|
390 |
e.g. |
391 |
|
392 |
can_use_scroll 1 |
393 |
can_use_skill 1 |
394 |
can_use_wand 1 |
395 |
can_use_rod 1 |
396 |
can_cast_spell 1 |
397 |
can_use_bow 1 |
398 |
can_use_armour 1 |
399 |
can_use_weapon 1 |
400 |
can_use_ring 1 |
401 |
|
402 |
Resistances (resist_x) |
403 |
=========== |
404 |
The amount of resistance the object has to certain attack types or |
405 |
environmental effects. Use negative numbers to make onjects more vunerable to |
406 |
the effects. |
407 |
|
408 |
e.g |
409 |
resist_fire 60 |
410 |
resist_cold -30 |
411 |
|
412 |
|
413 |
|
414 |
---------------------------- |
415 |
SPECIAL NOTE (IMPORTANT!!!): |
416 |
----------------------------- |
417 |
The fields resist_*, armour, wc and dam can be |
418 |
set in map files to customize monsters. However, if that monster can |
419 |
be equipped with items, and actually equips some, these values will |
420 |
get reset back to those in the clone archetype (normal values.) Thus, |
421 |
if you want to put a wizard in that does dam 50, make sure can_use_armour, |
422 |
and can_use_weapon are set back to 0. Otherwise, when items are equipped, |
423 |
all the above fields will be reset to standard values. |
424 |
|
425 |
|
426 |
|
427 |
H. Generators and creature spawning (generate) (other_arch) (use_content_on_gen) |
428 |
=================================== |
429 |
|
430 |
There are 2 types of generators in crossfire since september 2003. |
431 |
both are identified as generators by setting the flag "generate" to 1. |
432 |
For the first type (the classical one) use "other_arch" to specify |
433 |
archetype of object to be spawned. |
434 |
The second type allow more fine tuning on what to generate. To activate |
435 |
second type, set the flag "use_content_on_gen" to 1. Then each |
436 |
time something must be generated, it will be a copy of a randomly |
437 |
choosen item in the generator's inventory. |
438 |
|
439 |
|
440 |
H. NPC's and their life: |
441 |
======================= |
442 |
|
443 |
An NPC can have any combination of the following programs (flags): |
444 |
|
445 |
FLAGS: (They are checked in the following order:) |
446 |
- sleep (will stand still until woken) |
447 |
- scared (will run away) |
448 |
- random_movement (move randomly) |
449 |
- friendly (will attack enemies of the nearest player) |
450 |
- unaggressive (don't attack until attacked) |
451 |
- stand_still (don't ever move) |
452 |
|
453 |
sleep + (any) = sleep until woken, then do any of the other things... |
454 |
neutral + random_movement = move randomly around all the time. |
455 |
neutral (alone) = stand still until attacked, then attack and move. |
456 |
stand_still + (any) = do anything except moveing |
457 |
|
458 |
In addition it can have run_away set to which percentage of full |
459 |
hit-points the npc will run away at. |
460 |
|
461 |
And then there is the NPC features made by Karl Holland (see attack_movement) |
462 |
|
463 |
Note that scared creatures will become unscared at some point, so it |
464 |
is typically not useful to set this in maps or in archetypes. |
465 |
|
466 |
I. NPC's Speak out |
467 |
================== |
468 |
|
469 |
The message structure in a monster can contain: |
470 |
@match <key>|<key>[...] |
471 |
[text] |
472 |
[...] |
473 |
|
474 |
|
475 |
This identifies what the monster will say if talked to with a text |
476 |
which matches any keys. |
477 |
A key contaning '*' will match anything. |
478 |
|
479 |
An example of usage: |
480 |
@match hello|hi |
481 |
Welcome, good friend! |
482 |
@match bye |
483 |
Goodbye! |
484 |
@match * |
485 |
What did you say? |
486 |
|
487 |
|
488 |
As a special case, if the line just after match is 'quest xxx', then |
489 |
the NPC will only display the text (without the quote line) if the player |
490 |
is currently doing indicated quest. See also 'quests' document. |
491 |
|
492 |
Obviously this feature can be expanded extensively, so expect it |
493 |
to evolve till the next version. |
494 |
|
495 |
You might not want to put messages into archetype creatures, this feature is |
496 |
more for making special npcs for maps. However, certain generic messages in |
497 |
archetypes might add to the general game ambiance a bit (by default: dogs |
498 |
would say "arf arf" guards would say "move along"...) - tm |
499 |
|
500 |
****************************************************************************** |
501 |
3. Objects in general |
502 |
****************************************************************************** |
503 |
|
504 |
The name in parantheses after a flag description is the name as it should be |
505 |
used in the archetype file. For example: editable field (editable) |
506 |
|
507 |
A. Names (name, name_pl) |
508 |
======================== |
509 |
|
510 |
If no 'name' field is specified in the object, it will use the name from |
511 |
the 'Object' field. |
512 |
|
513 |
The 'name_pl' field is the plural name for the object. This only needs |
514 |
to be set if there is the potential for the object to merge with others - |
515 |
for example, there is no reason for name_pl to be set for floors, buildings, |
516 |
etc, as they can not merge with other objects. Only objects that can |
517 |
be picked up really need a name_pl value. |
518 |
|
519 |
If name_pl is not set, this name defaults to the object->name value, |
520 |
which was either explicitly set or determined from the Object field. |
521 |
|
522 |
These name values are what the player sees for the name. As the player |
523 |
sees it, the name may have the title appended to it, and may also |
524 |
have other per type specific information added in (spell contained |
525 |
within the spellbook for example). |
526 |
|
527 |
|
528 |
|
529 |
B. Types (type) & Subtypes (subtype) |
530 |
==================================== |
531 |
|
532 |
Specified in defines.h. A type determines how an item operates/what it does. |
533 |
A type only needs to be added for a new archetype if in some area of the |
534 |
program, it is actually used. Addition of new types is generally |
535 |
a rare event. |
536 |
|
537 |
For example, if adding a new monster, there is no need to add a new type |
538 |
in defines.h if crossfire never checks the type element in the object |
539 |
structure for that new type. |
540 |
|
541 |
Most types are set for items that are applied, items that have special |
542 |
properties. |
543 |
|
544 |
You should look at the include/defines.h file for the latest type |
545 |
information. Note that within maps, you should almost never change |
546 |
the type field of an object - instead, you should start with an |
547 |
object of the appropriate type and change the fields of the object |
548 |
to appear as you want it. |
549 |
|
550 |
Subtypes are related to types, in that it narrows down the scope of the |
551 |
type of object. For example, the type may be the value for skill, |
552 |
with subtype being the different skill it uses. Or for spell objects, |
553 |
subtype could be the spell identifier. |
554 |
|
555 |
Subtype is a new field as of April 2003. It's use needs to be extended. |
556 |
As example of this is with all equipment items - they should get moved |
557 |
to be of type 'equipment', with subtype specifying exactly what it does |
558 |
(ring, helm, armor, etc). |
559 |
|
560 |
Note that the meaning of the subtype is specific to the type itself - they are |
561 |
not unique across all types. For example, for type equipment, subtype 1 might |
562 |
be a helm. But for type skills, subtype 1 might be smithery. One should not |
563 |
rely on subtype to convey any meaningful information unless the type of the |
564 |
object is known or also examined. |
565 |
|
566 |
The question may then be asked - when making a new arch, how do I know |
567 |
if I need a new type, or if I should be the subtype of an existing type. |
568 |
|
569 |
When to add a new type: |
570 |
1) If code to support applying the object is completely different than |
571 |
what exists in apply.c (eg, not reusing existing functions), or |
572 |
2) If code to support movement of the type does not reuse existing |
573 |
functions (server/time.c) |
574 |
|
575 |
When to make a new subtype: |
576 |
1) Your behaviour is _close_ to that of an existing type, but you want it |
577 |
to be slightly different (eg, teleporters that don't work on players), or |
578 |
2) You need to be able to differentiate between objects of the same type. |
579 |
Eg, adding a new skill would add a new subtype, not a new type. |
580 |
|
581 |
If your not sure, drop a mail to the crossfire developers list. |
582 |
|
583 |
If there is a header file that contains all the other information related to |
584 |
the object type, the subtype should be defined there. Otherwise, subtypes |
585 |
should be defined in define.h. The subtype definitions should include be |
586 |
prefixed by what they are a subtype for. Eg, SKILL_SMITHERY, SKILL_JEWELER, |
587 |
etc, and not just SMITHERY and JEWELER. It is acceptable to abbreviate the |
588 |
prefix if it is very long. |
589 |
|
590 |
|
591 |
C. Client Types (client_type) |
592 |
============================== |
593 |
|
594 |
client type information in public information communicated to the client. |
595 |
Client type differes from the type in several ways: |
596 |
|
597 |
1) It is more specific than the type information. |
598 |
2) The numbers used for client type are more logically grouped (all armor |
599 |
related client_types are in the same range) |
600 |
3) client type info does not have a functional component in the server - it |
601 |
only conveys information - the server does not determine what an object |
602 |
may or may not do based on this. At current time, the server does not |
603 |
even look at the client_type for any information. |
604 |
4) The client_type can be used to hide the real type of an item. Eg, |
605 |
items of client_type poison should never be sent - client_type should |
606 |
instead by booze so difficult for the client to know what the item |
607 |
really is. similarly, special objects used in quests which appear |
608 |
as something else (eg, a key appearing as a shovel) can use the |
609 |
client type to have the type shown as the same category that |
610 |
shovels would be in. |
611 |
|
612 |
The client_type list below has large gaps - this is to allow future items |
613 |
to be grouped with items of similar type (Eg, if a new weapon type, |
614 |
say two-handed is added, it should be grouped with the weapons and not |
615 |
put at the end of the table). The entire point of the client_type information |
616 |
is to group the items together. |
617 |
|
618 |
In the list below, the number in parenthese corresponds to the number in |
619 |
define.h file. At the top of each group of items, the range is given. It is |
620 |
intentional in most cases to leave the first entry of a range blank - this |
621 |
gives room to place really important items of a type at the top. Note that |
622 |
only items the player may be able to pick up or apply actually need types. |
623 |
|
624 |
Note in most cases, the artifact type items are at the top of a group listing. |
625 |
This is done for artifact items that already have a different face/name, |
626 |
such that the player already knows they are special anyways. |
627 |
|
628 |
client_type |
629 |
Client Type Notes |
630 |
1-49 Specials - items that should be very noticable to the player. |
631 |
1 bomb (47) |
632 |
41 power crystal (156) |
633 |
|
634 |
50-99 Containers - put near top to make things easier for the player. |
635 |
51 container (122) |
636 |
51 big containers - chests, sacks, etc. |
637 |
55 small containers (pouches) |
638 |
60 specialized containers (quivers, key rings) |
639 |
|
640 |
100-149 hand held weapons |
641 |
100 Artifact weapons (15) |
642 |
101 edged weapons (sword, scimitar, etc) |
643 |
106 axes |
644 |
121 clubs |
645 |
126 hammers |
646 |
129 maces |
647 |
136 pole arms |
648 |
141 chained weapons |
649 |
145 oddball weapons (magnify glass, stake, taifu, shovel, etc) |
650 |
|
651 |
150-199 Ranged weapons & ammo: |
652 |
150 artifact bows (14) |
653 |
151 bow (14) |
654 |
159 arrow (13) Group ammo with firing type |
655 |
161 crossbow |
656 |
165 bolts |
657 |
|
658 |
250-399 Armor, shields, helms, etc. Give each subtype a group |
659 |
of 10 entries to further subdivide into. This is basically all |
660 |
equipable items not in another group. |
661 |
|
662 |
250-259 Bodywear (mails - 16) - ordered roughly in order of value |
663 |
250 Artifact/special |
664 |
251 Dragonmail - enough of these to warrant their own type |
665 |
252 plate mails |
666 |
253 chain mail, scale mail, & ring mail |
667 |
254 leather armor |
668 |
255 dress |
669 |
256 robes & tunics |
670 |
257 aprons |
671 |
|
672 |
260-269 Shields |
673 |
260 artifact shields (33) |
674 |
261 Shields (33) |
675 |
|
676 |
270-279 Headwear (34) |
677 |
270 artifact helmets (34) |
678 |
271 Helmets (34) |
679 |
272 turbans (34) |
680 |
273 wigs (34) |
681 |
275 eyeglasses (34) |
682 |
|
683 |
280 artifact cloaks (87) |
684 |
281 cloaks (87) |
685 |
|
686 |
290 artifact boots (99) |
687 |
291 boots (99) |
688 |
|
689 |
300 artifact gloves (100) |
690 |
301 gloves (100) |
691 |
305 gauntlets (100) |
692 |
|
693 |
310 artifact bracers (104) - god given |
694 |
311 bracers (104) |
695 |
|
696 |
321 girdle (113) |
697 |
381 amulets (39) |
698 |
390 artifact rings (70) |
699 |
391 rings (70) |
700 |
|
701 |
450-459 Skill objects - these are items that give you a skill, eg |
702 |
lockpicks, talismens, etc. |
703 |
451 skill (43) |
704 |
461 trap parts (76) |
705 |
|
706 |
600-649 Food & alchemy related items. Flesh items double as both |
707 |
eatabls and used in alchemy. Thus, we include the |
708 |
inorganic items here so that most all the alchemy stuff |
709 |
is located in the same general place in the inventory. |
710 |
601 Food (6) |
711 |
611 Poison (7) |
712 |
611 drink (54) |
713 |
620 Flesh item (72) |
714 |
622 corpse (157) Used for raise dead spells |
715 |
624 flesh items, quasi food - dragon steak |
716 |
625 flesh item - heads, eyes, tongues, teeth (72) |
717 |
626 flesh item - legs, arms, hands, feet, fingers, etc. |
718 |
627 flesh item - misc - ichors, scales, hearts, livers, skin (72) |
719 |
628 flesh items - dusts |
720 |
641 inorganic - raw (73) |
721 |
642 inoranic - refined (true lead, mercury, etc) |
722 |
|
723 |
650-699 Single use spell casting items (scrolls, potions, balms) |
724 |
651 potion (5) |
725 |
652 balms, dusts (5) |
726 |
653 figurines (5) |
727 |
661 scroll (111) |
728 |
|
729 |
700-749 Ranged spell casting items |
730 |
701 rod heavy (3) |
731 |
701 rod light (3) |
732 |
711 wand (109) |
733 |
712 staff |
734 |
721 horn (35) |
735 |
|
736 |
800-849 Keys |
737 |
801 normal key (24) |
738 |
810 special key (21) (archetype) |
739 |
811-839 special keys that maps can override the value into. In this |
740 |
way, all the special keys for a dungeon can be given the same |
741 |
client type so they group together. Note that the map needs |
742 |
to be modified to change the client_type of the keys to do this. |
743 |
|
744 |
1000-1049 Readables |
745 |
1001 mage Spellbook (85) |
746 |
1002 cleric spellbooks (85) |
747 |
1011 Armor improver (123) |
748 |
1016 weapon improver (124) |
749 |
1021 Skill scroll (130) |
750 |
1041 Books & scrolls - information type objects (8) |
751 |
|
752 |
1100-1149 Light emitting objects & lightables |
753 |
1101 lighter (75) |
754 |
1102 torch |
755 |
1103 colored torches |
756 |
|
757 |
2000-2049 Valuables - only real value is monetay |
758 |
2001 money (36) |
759 |
2005 gold nuggets |
760 |
2011 gems (60) - this could be divided into more subtypes - probably better |
761 |
for artifact gems to have a different type than worry about sorting |
762 |
ruby, diamond, emerald, etc. |
763 |
2030 Jewelery (60) - chalice, crystball |
764 |
|
765 |
|
766 |
8000-8999 Misc - items of no specific use or can not easily be sorted. |
767 |
8001 clock (9) |
768 |
8002 furniture (15) - These can be used as weapons, but probably |
769 |
shouldn't be. |
770 |
8003 ten kilo |
771 |
8006 bagpipe (24) - this is type key, probably shouldn't make it that obvious |
772 |
8011 gravestone (38) |
773 |
8012 boulders |
774 |
8013 pillars |
775 |
8015 flowers |
776 |
8020 ice cubes |
777 |
8021 transforming items |
778 |
|
779 |
25000-25999 Non-inventory items, stuff stuck to the floor, that can be applied. |
780 |
25011 Town portal (66) |
781 |
25012 Exits, doors, buildings - much more mundane exits (66) |
782 |
Note to arch writers; only need to set the client_type on |
783 |
the head (this is the case for all other properties as |
784 |
well). |
785 |
25021 Ordinary signs (98), Shop Inventory (150) |
786 |
25031 Imperial Post Office postboxes |
787 |
25041 Slot machines |
788 |
25042 Trigger (27), levers (93) |
789 |
25091 Bed to reality (106) |
790 |
|
791 |
D. editable field (editable) |
792 |
============================= |
793 |
|
794 |
Editable sole meaning is for crossedit. Crossedit uses editable to determine |
795 |
what menu(s) the item should appear in. Crossfire does not use it at all. |
796 |
|
797 |
The following table/values determine what menus the archetype will appear |
798 |
in. When looking at this table to determine what the value of editable |
799 |
should be, it is 2^(num-1). That is to say if you want it to appear in the |
800 |
'shop' menu, it would be 2^6 and not 2^7. By default, objects default |
801 |
to editable 1 - that is to say, they become monsters. |
802 |
|
803 |
Asterisk(*) marks groups that are really editable. |
804 |
|
805 |
0 (0) None - Internal archetypes (spells, abilities, |
806 |
map, etc.) |
807 |
*1 (1) Monsters - all monsters, generators and NPC's |
808 |
*2 (2) Exits - all buildings, towns, teleprorts and other |
809 |
exits |
810 |
*3 (4) Treasures - Normally used maps as treasures |
811 |
*4 (8) Backgrounds - different backgrounds (floors, woods, etc.) |
812 |
*5 (16) Gates and door - everything that can be opened or closed |
813 |
*6 (32) Special - directors, spinners, firewalls |
814 |
*7 (64) Shop - All items needed in shops. |
815 |
*8 (128) Normal objects - sacks, signs, gravestone, furnitures etc. |
816 |
*9 (256) False walls - Walls that C. Animations (anim - mina) (facings)can be destroyed or |
817 |
broken through. |
818 |
10 (512) Walls - different walls, caves, dungeons etc. |
819 |
11 (1024) Equipments - mainly weapons and armours |
820 |
12 (2048) Rest treasures - foods, scrolls, potions, jewels, etc |
821 |
13 (4096) Artifacts - Named weapons, special armors, etc |
822 |
|
823 |
An archetype can belong to several editable families, by adding the values |
824 |
together. For example, a value of 544 (512+32) would show up in both the |
825 |
special and walls menu. |
826 |
|
827 |
|
828 |
E. Animations (anim - mina) (facings) |
829 |
===================================== |
830 |
|
831 |
This section will briefly try to explain how all the animation values |
832 |
(anim_speed,last_anim, FLAG_IS_TURNING and FLAG_ANIMATE work together.) |
833 |
|
834 |
|
835 |
In the archetype specification, there is a anim/mina sequence which lists |
836 |
faces are used for animations. An example for the big dragon follows: |
837 |
|
838 |
anim |
839 |
dragon.171 |
840 |
dragon.172 |
841 |
dragon.173 |
842 |
dragon.172 |
843 |
dragon.131 |
844 |
dragon.132 |
845 |
dragon.133 |
846 |
dragon.132 |
847 |
mina |
848 |
|
849 |
Anything that is animated must have such a sequence. |
850 |
|
851 |
FLAG_ANIMATE (anim, mina)is used to inform crossfire that this object should |
852 |
be constantly animated. A case where an anim section as above is used but |
853 |
FLAG_ANIMATE is not set is for arrows and other objects in which the anim |
854 |
field is instead used to determine what face to draw for different facings of |
855 |
the object. |
856 |
|
857 |
facings is used in conjunctin with FLAG_ANIMATE. This is a states |
858 |
the number of facing the objects has (2, 4, or 8 - 1 is the default). |
859 |
the number of faces in the anim/mina sequence must be a multiple of |
860 |
num facings.. |
861 |
|
862 |
here is an example of using animation and facings: |
863 |
|
864 |
anim |
865 |
facings 2 |
866 |
fred.131 |
867 |
fred.132 |
868 |
fred.171 |
869 |
fred.172 |
870 |
mina |
871 |
|
872 |
The facings go clockwise (1 north (up), 3 east (right), 5 south (down), |
873 |
etc). |
874 |
|
875 |
If there are fewer than 8 facings (which is typical), the same rotational |
876 |
order is kept. So with only 2 facings, the first half in the group will be |
877 |
used when the creature is pointing to the right, second half to the left. |
878 |
|
879 |
|
880 |
anim_speed is used to determine how often the object is animated. IF |
881 |
anim_speed is 0, then the object is animated anytime it gets an action. |
882 |
If anim_speed is nonzero, then every anim_speed ticks, the object is |
883 |
animated (irregardless of how fast the item is) last_anim is used internally |
884 |
only to determine how many ticks have passed since the item was last |
885 |
animated. anim_speed is useful for objects that otherwise move very |
886 |
slowly but which need to be animated more often. Note: If anim_speed |
887 |
is used, the object must still have a nonzero speed for it to work. |
888 |
|
889 |
In terms of frequency of animations, 1/anim_speed = object speed. |
890 |
Thus if an object has speed of 0.2, its anim_speed is effectively 5. |
891 |
|
892 |
|
893 |
|
894 |
F. Material types (material) |
895 |
============================ |
896 |
|
897 |
Material bit |
898 |
|
899 |
Paper 1 |
900 |
Iron 2 |
901 |
Glass 4 |
902 |
Leather 8 |
903 |
Wood 16 |
904 |
Organic 32 |
905 |
Stone 64 |
906 |
Cloth 128 |
907 |
Adamantite 256 |
908 |
|
909 |
The objects material affects how saving throws against an object affect it. |
910 |
Thus, if paper is hit by fire, it tends to burn up, while iron does not. You |
911 |
can look in common/living.c to see the exact values. Note that if the material |
912 |
type is 0 (no material) or is Adamantite, the object can not be harmed in |
913 |
any way. |
914 |
|
915 |
An object can have multiple material types by adding these values together. |
916 |
|
917 |
|
918 |
G. Item Power (item_power) |
919 |
=========================== |
920 |
|
921 |
item_power measures how powerful and item is. This information is only |
922 |
relevant for items that are equipped - one time use items, monsters, |
923 |
walls, floors, do not use this. |
924 |
|
925 |
When a player tries to equip something, the code goes through all the objects |
926 |
the player currently has equipped and sums up their item_power. The |
927 |
item_power of the object the player is trying to equip is also added. If |
928 |
this total exceeds the characters level, he is not allowed to equip the |
929 |
item. |
930 |
|
931 |
In simple terms, the sum of all the players equip items item_power must |
932 |
be less than the characters level. |
933 |
|
934 |
Powerful items should have a higher item_power value. This basically |
935 |
acts as a way to balance the items. It also prevents gifts from high |
936 |
level characters to newbies from being very useful - the item_power may |
937 |
prevent the low level character from equipping this items. |
938 |
|
939 |
For items automatically generated by the treasure code, the following |
940 |
formula is used: |
941 |
|
942 |
# enchantments power |
943 |
0 0 |
944 |
1 0 |
945 |
2 1 |
946 |
3 2 |
947 |
4 3 |
948 |
5 5 |
949 |
6 8 |
950 |
7 11 |
951 |
|
952 |
An enchantment is: |
953 |
Each plus an item has. |
954 |
Each point an item increases an ability. |
955 |
Each 20% protection an item gives (rounded normally, eg 0-9 counts as nothing, |
956 |
10-29 counts as one, etc) |
957 |
Each attacktype a weapon has. |
958 |
Spell path adjustments |
959 |
|
960 |
This same formula can be used for custom objects to figure out their |
961 |
item power. |
962 |
|
963 |
While the item_power field in the object structure is signed, in general, |
964 |
there should not be objects with a negative item power. However, negative |
965 |
effects an item has may reduce the item power. Eg, a |
966 |
'sword +4 (str +2)(wis -3)' would really be 3 enchantments. |
967 |
|
968 |
Note: The enforcement of item power is currently not in use as of this |
969 |
writing (Aug 2002). Further refinement is needed on the power rating |
970 |
for items. However, if you are creating a new magic item, setting |
971 |
an appropriate item_power would save work later on. |
972 |
|
973 |
H. Body Location |
974 |
================== |
975 |
|
976 |
The body locations information determines where the item is equipped onto |
977 |
the character. If the character does not have the slot available, |
978 |
they are prevented from equipping the item. |
979 |
|
980 |
Some races may have a value of 0 for some locations, this denotes that they |
981 |
can not use that particular item (just won't fit on them). |
982 |
|
983 |
For monsters/players, the body location information is positive values - |
984 |
this denotes how many locations they have for the different slots. |
985 |
|
986 |
For items, the body location is negative, this denotes the spaces it |
987 |
uses up. Note that if multiple locations are set in an item, all of those |
988 |
spaces must be available to wear it (it is an AND operation, not an OR). |
989 |
Thus something that has body_neck -1 and body_head -1 means that both the |
990 |
head an neck must be available. |
991 |
|
992 |
Currently defined list of locations: |
993 |
load/save name # for humans What object types use it |
994 |
body_range 1 Rod, horn, wand |
995 |
body_arm 2 bows (2), weapon, shield |
996 |
body_torso 1 armour |
997 |
body_head 1 helmet |
998 |
body_neck 1 amulet |
999 |
body_skill 1 skills (holy symbols, talismen, lockpicks, |
1000 |
writing pens) |
1001 |
body_finger 2 rings |
1002 |
body_shoulder 1 cloak |
1003 |
body_foot 2 boots |
1004 |
body_hand 2 gloves |
1005 |
body_wrist 2 bracers |
1006 |
body_waist 1 girdle |
1007 |
|
1008 |
Using body locations: |
1009 |
Using this information is quite easy - for objects, just add the approprate |
1010 |
body_.. with a negative value. For monsters, put those in with a positive |
1011 |
value. If a monster has a location to use an object, is is presumed in the |
1012 |
code that the monster should pick up/equip objects into that location. |
1013 |
Thus, setting these for monsters may not reall match what they have, |
1014 |
eg, kobolds have arms, but it is still set to 0 so that they won't equip |
1015 |
things. The above information largely replaces the CAN_USE information. |
1016 |
|
1017 |
Note that the unqualified names above only refer to human locations. New |
1018 |
locations for dragons or other creatures can easily be added. |
1019 |
|
1020 |
Adding body locations: |
1021 |
|
1022 |
The steps for adding a body location is as follows: |
1023 |
1) Update the table above for documentation purposes. |
1024 |
2) Update the NUM_BODY_LOCATIONS in include/object.h. |
1025 |
3) Update the body_locations structure in common/item.c. Be sure to read |
1026 |
the comments above the structure. |
1027 |
4) recompile |
1028 |
5) create some items that use these new locations. |
1029 |
|
1030 |
Note that most the code itself sees all this as abstract - it doesn't know |
1031 |
what goes in what location, or even what each location is called. |
1032 |
However, a few bits do care - the skill stuff checks to see if you have |
1033 |
any arms free - thus, BODY_ARMS is defined so we know if the player |
1034 |
does or does not. The alternative to this would be to have the |
1035 |
skill stuff do a strcmp, but then we are defining the name - easier |
1036 |
to just presume that the location won't change in teh body_locations |
1037 |
table - there is no reason that it should. |
1038 |
|
1039 |
I. Meaning of certain attributes for certain items: |
1040 |
==================================================== |
1041 |
|
1042 |
All objects have strength, intelligence, wisdom, dexterity, constitution, |
1043 |
charisma, experience, and spell points. However, how each is used |
1044 |
varies for different objects. Here is a PARTIAL rundown: |
1045 |
|
1046 |
For rings, str, int, wis, dex, con and cha are modifiers to the users |
1047 |
abilities. |
1048 |
|
1049 |
For treasures (chests, random_???), hp is the number of items that |
1050 |
should be generated. A chest with hp of 5 will generate 5 treasures, |
1051 |
a random_scroll space with hp of 5 will generate 5 random scroll types (of |
1052 |
which, each scroll type may number more than one - see the treasures |
1053 |
file for more information.) |
1054 |
|
1055 |
For shop floors and treasures, exp is the difficulty to use for |
1056 |
creating the treasure. If exp is 0 (which it is by default), then the |
1057 |
map difficulty is used instead. |
1058 |
|
1059 |
For armour, last_sp (ARMOR_SPEED) is the maximum speed that the |
1060 |
character can have while wearing that armor. |
1061 |
|
1062 |
For armour, last_heal determines the penalty for spell point regeneration. |
1063 |
|
1064 |
For exits: |
1065 |
slaying = The map which the exit leads to. |
1066 |
hp,sp = (x,y) of the destination on the new map. |
1067 |
|
1068 |
J. Lore |
1069 |
============================================================ |
1070 |
|
1071 |
Lore is a free form text field similiar to the msg bug. Its syntax is |
1072 |
|
1073 |
lore |
1074 |
.. |
1075 |
.. |
1076 |
endlore |
1077 |
|
1078 |
while msg's meaning is dependent on the object, lore is consistent - it |
1079 |
should contain background information on the object, or other somewhat general |
1080 |
details about the object. It will be put into books, possibly used by npc's |
1081 |
and other places where general knowledge should be presented. |
1082 |
|
1083 |
K. MOVEMENT TYPES |
1084 |
============================================================ |
1085 |
|
1086 |
The movement types (MOVE_..) is a bitmask that determines which method |
1087 |
of locomotion the object is using, and is also used to determine what |
1088 |
types of movement the space blocks. From define.h: |
1089 |
|
1090 |
#define MOVE_WALK 0x1 /* Object walks */ |
1091 |
#define MOVE_FLY_LOW 0x2 /* Low flying object */ |
1092 |
#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_SWIM 0x8 /* Swimming object */ |
1095 |
#define MOVE_ALL 0xf; /* Mask of all movement types */ |
1096 |
|
1097 |
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 |
1099 |
check for all movement types may also use this value. |
1100 |
|
1101 |
The fields in the object themselves: |
1102 |
|
1103 |
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 |
1105 |
that movement. |
1106 |
|
1107 |
Note that move_type of MOVE_FLY (0x2) replaces FLAG_FLYING. |
1108 |
|
1109 |
In general, creatures will only have 1 movement type active at a time. |
1110 |
|
1111 |
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 |
1113 |
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, |
1115 |
a he just flies over. |
1116 |
|
1117 |
move_on/move_off: Take bitmasks - represents for what movement types |
1118 |
this object is activated on. Replaces the walk/fly_on/off values |
1119 |
|
1120 |
move_slow: Like move_block, but represents what movement types are slowed |
1121 |
on this space. Note that it is not possible to specifiy different |
1122 |
penalties for different movement types in the same object. However, |
1123 |
multiple objects with different move_slow values (and penalties) can |
1124 |
be put on the same space. This replaced FLAG_SLOW_MOVE, which is |
1125 |
converted to only slow down walking movement |
1126 |
|
1127 |
move_slow_penalty (was slow_move) - how much the player is slowed down. |
1128 |
This value is a float (before it was an int converted to a float |
1129 |
at load time). It is basically how much slower (percentage wise) |
1130 |
the player moves through this terrain. A value of 0 is basically |
1131 |
a non operation. A value of 0.5 means it takes 50% longer to move |
1132 |
through the space. The old values were all positive ints. Basically, |
1133 |
it effectively was how many ticks the player is slowed down by. |
1134 |
|
1135 |
Certain terrain has skills which reduce the slow penalty (woodsmen |
1136 |
in forest for example). As of this writing, the penalty is reduced |
1137 |
to 1/4 of what it would be. Eg, a move_slow_penalty of 1.0 would |
1138 |
say it takes twice as long to move through the space. If the player |
1139 |
has appropriate skill, it would now only take that player 25% |
1140 |
longer to move through the space. |
1141 |
|
1142 |
Note 2: The old slow_move is loaded and converted into move_slow_penalty. |
1143 |
The old SLOW_PENALTY and SET_SLOW_PENALTY macros divided/multiplied |
1144 |
the result by 1000, so were basically a non operation. Since it is now |
1145 |
just stored as a float, conversion macros are not needed or used. |
1146 |
|
1147 |
move_state/move_status: This is unrelated to this movement code - it is |
1148 |
used for monster attack_movement information. it is only noted here |
1149 |
since it starts with the move_ prefix. |
1150 |
|
1151 |
msg/endmsg: If an object has move_block of move_slow and that affects |
1152 |
the player movement, the objects message will be printed to the player - |
1153 |
thus things like 'The jungle slows you down' or 'The wall is in the way' |
1154 |
will be printed. Various hints can be contained in the messages. |
1155 |
|
1156 |
move_status: Not related to this code - noted here since it has the move_ |
1157 |
prefix. This is used to track monsters state of the attack_movement |
1158 |
variable. It is worth noting that move_type was changed to |
1159 |
attack_movement - this matches the name in the archetype, but is |
1160 |
a name change in the object field. |
1161 |
|
1162 |
Obsoleted fields: |
1163 |
This change of logic has resulted in the following fields no longer |
1164 |
being used: |
1165 |
FLAG_WALK_ON -> move_on |
1166 |
FLAG_NO_PASS -> move_block |
1167 |
FLAG_SLOW_MOVE -> move_slow |
1168 |
FLAG_FLYING -> move_type |
1169 |
FLAG_WALK_OFF -> move_off |
1170 |
FLAG_FLY_ON -> move_on |
1171 |
FLAG_FLY_OFF -> move_off |
1172 |
FLAG_PASS_THRU -> was unused, would be move_type |
1173 |
FLAG_CAN_PASS_THRU -> was unused, would be move_type |
1174 |
|
1175 |
|
1176 |
Load/Save behaviour and backward compatability: |
1177 |
The loader knows about certain old flags (walk_on, blocked, etc) and |
1178 |
sets up the appropriate bitmasks. When data is saved, it is saved |
1179 |
as the move_... with actual bitmasks. |
1180 |
|
1181 |
Special player notes: |
1182 |
Player can only pick up items if MOVE_WALK is set (this may need |
1183 |
to be expanded down the road). Basic idea is that if you are flying, |
1184 |
can't reach the ground, if swimming, don't really have any free hands |
1185 |
to grab anything. |
1186 |
|
1187 |
****************************************************************************** |
1188 |
4. SPECIAL OBJECTS |
1189 |
****************************************************************************** |
1190 |
A. MAPS: |
1191 |
======== |
1192 |
see doc/map-technical for this information. |
1193 |
|
1194 |
|
1195 |
B. HOLY_ALTARS |
1196 |
============== |
1197 |
(re-done code by Mark Wedel) |
1198 |
Holy altars are altars for the various religions. Praying at a |
1199 |
holy_altar will make you a follower of that god, and if you already follow |
1200 |
that god, you may get some extra bonus. Meaning of the fields |
1201 |
|
1202 |
level: To re-consecrate an altar, the players skill level must be as |
1203 |
high or higher than the level field. In this way, some altars can not |
1204 |
be re-consecrated, while other altars, like those in dungeons, could be. |
1205 |
|
1206 |
other_arch: The god that this altar belongs to. This replaces the |
1207 |
title field that used to be used. |
1208 |
|
1209 |
|
1210 |
C. DISEASES |
1211 |
=========== |
1212 |
by Peter Mardahl |
1213 |
|
1214 |
The following describes some things about the archetype |
1215 |
and implementation: |
1216 |
|
1217 |
Stat Property Definition |
1218 |
|
1219 |
attacktype Attack effects Attacktype of the disease. usu. AT_GODPOWER. |
1220 |
other_arch Creation object created and dropped when symptom moved. |
1221 |
wc+ Infectiousness How well the plague spreads person-to-person |
1222 |
magic+ Range range of infection |
1223 |
Stats* Disability What stats are reduced by the disease (str con...) |
1224 |
maxhp+ Persistence How long the disease can last OUTSIDE the host. |
1225 |
value TimeLeft Counter for persistence |
1226 |
dam^ Damage How much damage it does (%?). |
1227 |
maxgrace+ Duration How long before the disease is naturally cured. |
1228 |
food DurCount Counter for Duration |
1229 |
|
1230 |
speed Speed How often the disease moves. |
1231 |
last_sp^ Lethargy Percentage of max speed--10 = 10% speed. |
1232 |
|
1233 |
maxsp^ Mana deplete Saps mana. |
1234 |
ac^ Progressiveness How the diseases increases in severity. |
1235 |
last_eat*^ Deplete food saps food if negative |
1236 |
|
1237 |
exp experience experience awarded when plague cured |
1238 |
hp*^ ReduceRegen reduces regeneration of disease-bearer |
1239 |
sp*^ ReduceSpRegen reduces spellpoint regeneration |
1240 |
|
1241 |
name Name Name of the plague |
1242 |
msg message What the plague says when it strikes. |
1243 |
race those affected races the plague strikes (* means everything) |
1244 |
level Plague Level General description of the plague's deadliness |
1245 |
|
1246 |
last_grace Attenuation reduction in wc per generation of disease. |
1247 |
This builds in a self-limiting factor. |
1248 |
|
1249 |
Explanations: |
1250 |
* means this # should be negative to cause adverse effect. |
1251 |
+ means that this effect is modulated in spells by ldur |
1252 |
^ means that this effect is modulated in spells by ldam |
1253 |
|
1254 |
attacktype is the attacktype used by the disease to smite "dam" damage with. |
1255 |
|
1256 |
wc/127 is the chance of someone in range catching it. |
1257 |
|
1258 |
magic is the range at which infection may occur. If negative, this is |
1259 |
not level dependent. |
1260 |
|
1261 |
Stats are stat modifications. These should typically be negative. |
1262 |
|
1263 |
maxhp is how long the disease will persist if the host dies and "drops" it, |
1264 |
in "disease moves", i.e., moves of the disease. If negative, permanent. |
1265 |
|
1266 |
|
1267 |
value is the counter for maxhp, it starts at maxhp and drops... |
1268 |
|
1269 |
dam if positive, it is straight damage. if negative, a %-age. |
1270 |
|
1271 |
maxgrace how long in "disease moves" the disease lasts in the host, if negative, |
1272 |
permanent until cured. |
1273 |
|
1274 |
food if negative, disease is permanent. otherwise, decreases at <speed>, |
1275 |
disease goes away at food=0, set to "maxgrace" on infection. |
1276 |
|
1277 |
speed is the speed of the disease, how fast "disease moves" occur. |
1278 |
|
1279 |
last_sp is the lethargy imposed on the player by the disease. A lethargy |
1280 |
of "1" reduces the players speed to 1% of its normal value. |
1281 |
|
1282 |
maxsp how much mana is sapped per "disease move". if negative, a %-age is |
1283 |
taken. |
1284 |
|
1285 |
ac every "disease move" the severity of the symptoms are increased by |
1286 |
ac/100. (severity = 1 + (accumlated_progression)/100) |
1287 |
|
1288 |
last_eat increases food usage if negative. |
1289 |
|
1290 |
last_grace Reduction in the diseases' contageousness everytime it infects someone |
1291 |
new. This limits how many generations a disease can propagate. |
1292 |
|
1293 |
|
1294 |
|
1295 |
For SYMPTOMS: |
1296 |
|
1297 |
Stats modify stats |
1298 |
hp modify regen |
1299 |
value progression counter (multiplier = value/100) |
1300 |
food modify food use (from last_eat in DISEASE) |
1301 |
maxsp suck mana ( as noted for DISEASE) |
1302 |
last_sp Lethargy |
1303 |
msg What to say |
1304 |
speed speed of movement, from DISEASE |
1305 |
|
1306 |
|
1307 |
|
1308 |
D. CONVERTERS: |
1309 |
============== |
1310 |
other_arch = which archetype to convert into |
1311 |
slaying = which archetype to convert from |
1312 |
sp = how many other_arch to create |
1313 |
food = how many items are needed to convert into <sp> other_arch |
1314 |
|
1315 |
|
1316 |
|
1317 |
E. BOWS & ARROWS: |
1318 |
================= |
1319 |
Missile weapons |
1320 |
|
1321 |
Missile weapons (type BOW) can be used to shoot missiles |
1322 |
(type ARROW). The most common wepons are bows and crossbows |
1323 |
but other weapons are also easy to implement (e.g. a sling). |
1324 |
The following variables have the same meaning for both weapons |
1325 |
and bullets: |
1326 |
|
1327 |
race type of missile (indentifies weapon and missile pairs) |
1328 |
dam the basic damage |
1329 |
wc the basic wc |
1330 |
magic the magic bonus |
1331 |
|
1332 |
And these two used only for arrows. |
1333 |
|
1334 |
hp the basic damage (internal use) |
1335 |
sp the basic wc (internal use) |
1336 |
food the breaking probability after a shot (0-100) |
1337 |
|
1338 |
And these two are for bows. |
1339 |
|
1340 |
sp the shooting speed (% of normal speed, 1-100) |
1341 |
no_strength player's strength or monster's level doesn't affect |
1342 |
the damage done by bow. |
1343 |
|
1344 |
The other variables has their normal meanings. |
1345 |
|
1346 |
|
1347 |
|
1348 |
F. object creating objects |
1349 |
========================== |
1350 |
by peterm |
1351 |
What a creator is, is an object which creates another object when it is |
1352 |
triggered. The daughter object can be anything. (yet another way other |
1353 |
than runes to create surprise monsters, though runes are better for that, |
1354 |
they're smarter at placing monsters) |
1355 |
|
1356 |
You've seen a creator demonstrated if you've solved the Tower of |
1357 |
Demonology: when you summon a demon you also get some firetrails |
1358 |
|
1359 |
Creator object: an object which creates other objects. It is usually |
1360 |
invisible. |
1361 |
|
1362 |
other_arch the object to create |
1363 |
connected what will trigger it (button, magic ear) |
1364 |
hp number of times to create before dissappearing |
1365 |
lifesave if 1, it will create the object every time it's triggered, |
1366 |
and never disappear |
1367 |
slaying the name the created object will bear |
1368 |
level the level the created object will have |
1369 |
|
1370 |
|
1371 |
G.Player Movers |
1372 |
=============== |
1373 |
by peterm |
1374 |
|
1375 |
Player movers are objects which move objects above them. These objects |
1376 |
must be alive. They are directional, so players can be made to move in |
1377 |
a pattern, and so can monsters. |
1378 |
|
1379 |
Motion is involuntary. Additionally, players or monsters can be paralyzed |
1380 |
so that they MUST move along a chain of movers. |
1381 |
|
1382 |
Multisquare monsters can be moved by movers, however enough space is required. |
1383 |
|
1384 |
Here is the meaning of various fields: |
1385 |
|
1386 |
|
1387 |
attacktype: if nonzero, paralyzes anyone it moves (so they are forced to |
1388 |
move along a chain). Default values is 0 |
1389 |
|
1390 |
maxsp: the number of moves that the paralysis will rob the player of, |
1391 |
if unset, and attacktype is nonzero, this becomes 2. By default, |
1392 |
it is zero. |
1393 |
|
1394 |
move_type: What movement types this mover moves (replaces maxhp to denote |
1395 |
flying creatures) |
1396 |
|
1397 |
speed: how fast a chain of these will move a player along (default -0.2) |
1398 |
|
1399 |
sp: the direction--if unset (0) motion is random. |
1400 |
|
1401 |
level: if nonzero, players will be moved as well as monsters. 0 by default. |
1402 |
|
1403 |
lifesave: whether it can be used up, meaning is opposite, it may go away |
1404 |
if lifesave is set. default is not set. |
1405 |
|
1406 |
hp: if lifesave is set, the number of times (-1) it will move a player |
1407 |
(i.e., it will move someone hp+1 times before it vanishes.). default |
1408 |
0 |
1409 |
|
1410 |
subtype: a bitmask that specifies which of arch, name, and race affect the |
1411 |
race and slaying flags. If unspecified (or zero), all will be searched. |
1412 |
The LSB is arch, the next bit is name, and the third bit is for race. |
1413 |
Table for the lazy: |
1414 |
subtype 1: only arch |
1415 |
subtype 2: only name |
1416 |
subtype 3: arch or name |
1417 |
subtype 4: only race |
1418 |
subtype 5: arch or race |
1419 |
subtype 6: name or race |
1420 |
subtype 7: all three |
1421 |
|
1422 |
race: only affect objects with a arch/name/race matching this. |
1423 |
|
1424 |
slaying: don't affect objects with a arch/name/race matching this. |
1425 |
|
1426 |
Note from Mark: Player Movers and Directors are seperate objects, even |
1427 |
though they look and act similar. Directors only do spells/missiles, |
1428 |
however, while player movers only do living creatures (depending on how it |
1429 |
is set) |
1430 |
|
1431 |
H. Directors |
1432 |
============ |
1433 |
Directors are objects that change the direcion of objects moving through the |
1434 |
air such as spells and missiles. As in the noted in the section on player |
1435 |
movers, they act similar, however in constrast they only affect spells, |
1436 |
missiles, or other flying projectiles. |
1437 |
|
1438 |
Here are the various fields: |
1439 |
|
1440 |
sp: the direction--if unset (0) motion is random. |
1441 |
|
1442 |
subtype: a bitmask that specifies which of arch, name, and race affect the |
1443 |
race and slaying flags. If unspecified (or zero), all will be searched. |
1444 |
See the section above on playermovers for what subtypes mean what. |
1445 |
|
1446 |
race: only affect objects with a arch/name/race matching this. |
1447 |
|
1448 |
slaying: don't affect objects with a arch/name/race matching this. |
1449 |
|
1450 |
|
1451 |
|
1452 |
I. Magical Walls -- walls that cast spells |
1453 |
============================================ |
1454 |
Magical walls are like other walls, except every now and then, |
1455 |
they fire spells. |
1456 |
|
1457 |
Magical walls can contain any spell. However, some spells do not operate |
1458 |
very successfully in them. The only way to know is to test the spell you |
1459 |
want to use with a wall. |
1460 |
|
1461 |
Several types of magical walls are predefined for you in the archetypes, and |
1462 |
can be found on a pick-map available in crossedit. |
1463 |
|
1464 |
If you want a magical wall which is not already defined, all you need to do |
1465 |
is choose one of the predefined walls, and modify the 'dam' variable. The |
1466 |
'dam' variable contains the index of the spell. See include/spellist.h to |
1467 |
find your desired spell. |
1468 |
|
1469 |
Meaning of archetype fields: |
1470 |
field: Meaning: |
1471 |
|
1472 |
dam spell the wall will cast |
1473 |
|
1474 |
sp integer direction the wall will cast the spell. If 0, |
1475 |
the wall will cast the spell in random direction. |
1476 |
|
1477 |
ac armour class of wall |
1478 |
|
1479 |
exp experience value of the wall |
1480 |
|
1481 |
speed speed of the wall--you can fine-tune how fast the |
1482 |
wall will cast spells |
1483 |
|
1484 |
alive 1 means it can be attacked, 0 means not |
1485 |
|
1486 |
hp, maxhp hit points |
1487 |
|
1488 |
immune immunity OR mask |
1489 |
|
1490 |
type for magical walls, this is 62 |
1491 |
|
1492 |
other_arch obsolete now, means nothing |
1493 |
|
1494 |
maxsp has to do with turning walls. The wall will turn |
1495 |
by 'maxsp' every time it fires, changing face. |
1496 |
To make a wall turn, it is sufficient to set this |
1497 |
to 1. Setting it to 8 or any multiple thereof is |
1498 |
an exercise in futility. |
1499 |
|
1500 |
level The level the spell will cast spells at. Level 1 |
1501 |
walls will cast spells at minimal strength. Level 100 |
1502 |
walls will cast deadly spells. |
1503 |
|
1504 |
connected either rotate the wall or trigger it. If triggering, |
1505 |
set speed to 0 for best results. |
1506 |
|
1507 |
|
1508 |
|
1509 |
J. Containers |
1510 |
============= |
1511 |
container <xxx> : the maximum weight the container can hold |
1512 |
(stored internally in weight_limit) |
1513 |
|
1514 |
Str <xx> : reduces the weight of the objects in the container |
1515 |
0 == no reduction, 100 = weightless |
1516 |
|
1517 |
|
1518 |
K. Mood Floors |
1519 |
============== |
1520 |
("Brian Thomas" <thomas@astro.psu.edu>) |
1521 |
last_sp field is used to determine what will happen to the monster |
1522 |
when the floor is activated: |
1523 |
|
1524 |
(based on value that last_sp takes): |
1525 |
0: 'furious' Makes all monsters aggressive |
1526 |
1: 'angry' As above but pets are unaffected |
1527 |
2: 'calm' Makes all monsters unaggressive |
1528 |
3: 'sleep' Puts all monsters to sleep |
1529 |
4: 'charm' Makes monster into a pet of person |
1530 |
who triggers the square. This setting |
1531 |
is not enabled for continous operation |
1532 |
|
1533 |
|
1534 |
L. Altars, Triggers, Detectors and other connected items: |
1535 |
========================================================= |
1536 |
Note: This is not quite complete documentation, but is correct as far |
1537 |
as it goes (0.92.1) |
1538 |
|
1539 |
slaying: What the sacrifice must match. It either matches the archetype |
1540 |
name (internal value only), object name, or slaying field of object. |
1541 |
"money" is a special case - in this case, an exact name is not needed, any |
1542 |
types of money will match. |
1543 |
|
1544 |
food: How many objects must be sacrificed. If slaying is money, then the |
1545 |
value of the money must be greater than the food value (ie, if food=200, |
1546 |
then 200 sp, 20 gp, or 4 pp will all work.) Note that this is stored |
1547 |
in a 16 bit signed value - thus the maximum is 32767. |
1548 |
|
1549 |
msg: What to print when the altar is activated. |
1550 |
|
1551 |
connected: A link to another object to activate. |
1552 |
|
1553 |
sp: Spell number to cast when activated. |
1554 |
|
1555 |
level: What level to cast the spell at. |
1556 |
|
1557 |
hp: If set, use hp to match to that object type. |
1558 |
|
1559 |
Note: For all sacrifice types, the number to activate the altar must be in |
1560 |
one object. Thus, in the above money example, 100 sp and 10 gp would not |
1561 |
work. Likewise, if the needed sacrifice was 2 swords, 1 normal sword and 1 |
1562 |
+1 sword would not work, even though 2 of either one would. |
1563 |
|
1564 |
Quick summary of the different altars: |
1565 |
|
1566 |
TRIGGERS: |
1567 |
--------- |
1568 |
TRIGGERS are slightly different than normal buttons/pedestals/whatever in |
1569 |
that they reset after a short amount of time. Thus, they can be used to |
1570 |
open a door for a short amount of time. Triggers use stats.wc as |
1571 |
a temporary storage value to note activation. |
1572 |
|
1573 |
stats.exp is used do determine when the trigger resets. A smaller value |
1574 |
means faster reset. |
1575 |
|
1576 |
stats.ac is used to store the old value of the condition for TRIGGER_BUTTON |
1577 |
and TRIGGER_PEDESTAL to trigger only when condition changes from false to true. |
1578 |
|
1579 |
TRIGGER_BUTTON: if weight on the button is greater than the weight value |
1580 |
for the trigger, push a trigger. |
1581 |
|
1582 |
TRIGGER_PEDESTAL: IF a matching object is on top of the pedestal, then trigger |
1583 |
a trigger. |
1584 |
|
1585 |
TRIGGER_ALTAR: Takes a sacrifice, then pushes a trigger. |
1586 |
If "last_sp 0" is set, the altar will trigger the connected value TWO |
1587 |
times per sacrifice: Once by dropping the sacrifice, second by altar reset. |
1588 |
If "last_sp 1" is set, the altar won't trigger the connected value |
1589 |
by reset - Hence, only ONE time per sacrifice. |
1590 |
|
1591 |
TRIGGER (handle): Pushes a trigger. |
1592 |
Note: At one time, there was a difference between triggers and buttons - they |
1593 |
were considered different types for activation. However, now they are all |
1594 |
the same - a button can push a trigger, and vice versa. And of course, |
1595 |
triggers can activate other triggers, and the same for buttons. |
1596 |
|
1597 |
PEDESTALS: |
1598 |
---------- |
1599 |
These are sort of combo buttons & altars. If the pedestals race matches |
1600 |
the slaying of an object on top (race of player matches any player), then |
1601 |
push the connected objects. By default, pedestals match players. They |
1602 |
differ from buttons in that specific objects activate them (vs an amount of |
1603 |
weight.) They are different from altars in that the object that |
1604 |
activates them does not disappear. |
1605 |
|
1606 |
Inventory checkers (64) |
1607 |
----------------------- |
1608 |
Inventory checkers passively check the players inventory to see if it |
1609 |
contains some object. Thus, you can make portals which you can't pass through |
1610 |
if you contain certain objects. |
1611 |
|
1612 |
slaying: Object name we are looking for. |
1613 |
race: archetype name we are trying to match for. |
1614 |
hp: match on object with that type value. |
1615 |
last_heal: Remove object if found. |
1616 |
last_sp: If set, than having that object is a match. If 0, then not having |
1617 |
that object is a match. |
1618 |
connected: Value to to push. |
1619 |
no_pass: If set, you can only pass through that space if you be allowed to |
1620 |
(depending on last_sp determines if having/not having is the match |
1621 |
criteria.) if no_pass is 0 (default), then the inventory only acts as |
1622 |
a trigger/button. |
1623 |
|
1624 |
General usage notes: Putting a check_inventory space in front of a gate with |
1625 |
another on the other side works reasonably well as a control mechanism. Note, |
1626 |
however, that other people may still be able to slip by. To get around this, |
1627 |
use the no_pass to 1, and put it in the space you want to control (probably |
1628 |
makes sense to put a fake door or other object there to make it a little more |
1629 |
obvious what is going on.) |
1630 |
|
1631 |
DETECTOR: |
1632 |
--------- |
1633 |
This object samples the square its in, and if it finds an object |
1634 |
named in the slaying field, it toggles its connected value. Detectors are a |
1635 |
lot like pedestals - the only really difference is that they sample the |
1636 |
space periodically, where as pedestals will get triggered the instant |
1637 |
something is dropped. The use for pedestals is to add some indeterminate |
1638 |
time delay (indeterminate since you can never be sure at what point in its |
1639 |
timing the player will actually drop something on the detector.) Personally, |
1640 |
I don't see much if any use for detectors. (The author of this last sentence |
1641 |
didn't realize that if you blow a spell over a detector, it may be detected, |
1642 |
but a pedestal won't notice it.) |
1643 |
|
1644 |
slaying name of the thing the detector is to look for |
1645 |
* note: FORCEs with slaying fields == slaying field of detector |
1646 |
will be detected. |
1647 |
speed time between samples |
1648 |
connected connected value of detector |
1649 |
sp 1 if detection sets buttons, |
1650 |
-1 if detection unsets buttons |
1651 |
hp 1 if it is to search through an inventory of an object |
1652 |
sitting over it |
1653 |
|
1654 |
|
1655 |
MARKER: |
1656 |
------- |
1657 |
This object inserts a force into a player who stands on it. |
1658 |
This force does nothing except contain a string in its slaying field |
1659 |
which can be discovered by a detector. |
1660 |
|
1661 |
slaying the code |
1662 |
speed how quickly it will mark something standing on it |
1663 |
food duration of the force it inserts. If nonzero, the duration |
1664 |
is finite: about 1 food per 10 seconds |
1665 |
name slaying field of a force to remove. |
1666 |
|
1667 |
|
1668 |
See also the 'quests' file for special values on slaying field. |
1669 |
|
1670 |
------------------------------------------------------------------------------ |
1671 |
NOTE ABOUT ALL CONNECTED ITEMS: |
1672 |
|
1673 |
Whenever an object that is connected gets activated, all other objects |
1674 |
with the same connected tag also gets pushed. For some objects |
1675 |
(pedestals, inventory checkers) this is likely to be meaningless. However, |
1676 |
if something like an altar is pushed in this fashion, it will no longer |
1677 |
be usuable (only take one sacrifice, and being activated in this fashion |
1678 |
makes it so that it looks to have been activated.) |
1679 |
|
1680 |
One trick for connected objects that you want activated once: Set your |
1681 |
initial connects to a set (or multiple sets) of iron spikes that are in |
1682 |
a 2x1 enclosed area. On top of the spikes, put a boulder, and on the |
1683 |
other space, put a large button that is then connected to whatever object. |
1684 |
Thus, when the spikes are activated, they push the boulder to the other |
1685 |
space, that then activates whatever is desired. |
1686 |
|
1687 |
|
1688 |
M. Signs: |
1689 |
======== |
1690 |
msg: what to print when applied. |
1691 |
food: how many times the sign can be read. |
1692 |
last_eat: how many times the sign has been read (only used internally.) |
1693 |
|
1694 |
If food is zero, there is no limit on how many times the sign can be read. |
1695 |
|
1696 |
|
1697 |
N. POISONOUS BOOZE: |
1698 |
================== |
1699 |
stats.hp Poison player or monster that applies this booze with stats.hp |
1700 |
poison damage. |
1701 |
|
1702 |
stats.hp must be greater 0 to do damage. It used to be less than 0 for |
1703 |
-stats.hp direct damage, but that has changed. stats.hp <= 0 now means no |
1704 |
damage at all, just loss of 25% food. |
1705 |
|
1706 |
O. Duplicators: |
1707 |
=============== |
1708 |
Duplicators copy or remove objects. Duplicators are triggered objects. |
1709 |
|
1710 |
connected: Connected value for the duplicator. |
1711 |
other_arch: Archetype that this copies - if the archetype on top of the |
1712 |
duplicator doesn't match this, it isn't copied. Note that it only |
1713 |
matches the archetype - the object can then be further duplicated. For |
1714 |
example, if other_arch is sword, it will duplicate sword +4, different |
1715 |
attacktypes, etc, and all of those are duplicated. But it will not |
1716 |
duplicate a dagger for example. |
1717 |
level: The number of copies to make (1 means no changes). If set to 0 |
1718 |
the object is removed. |
1719 |
|
1720 |
Example: |
1721 |
|
1722 |
arch duplicator |
1723 |
level 2 |
1724 |
other_arch sword |
1725 |
connected 5 |
1726 |
end |
1727 |
|
1728 |
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 |
1730 |
unaffected. If the lever it is connected to is not pulled, it is also |
1731 |
unaffected. |
1732 |
|
1733 |
******************************************************************************* |
1734 |
5. Flags & specifications: (usage: flag value) |
1735 |
****************************************************************************** |
1736 |
Note: the flags are case sensitive. |
1737 |
G = generator. O = object. |
1738 |
|
1739 |
Note (961129): These notes look correct as far as they go. However, |
1740 |
oftentimes, the real effect in game terms might be more complicated than |
1741 |
list here. As an example: Exp value is just base - it will be further modified |
1742 |
based on stats, levels, and potentially skills. |
1743 |
|
1744 |
Flag syntax Value |
1745 |
=========== ===== |
1746 |
Object <name> name of O, internal refs only. |
1747 |
name <name> name of O as seen in the game. |
1748 |
race <name> race of O, internal. |
1749 |
slaying <name> Those O's with this race receives 2x damage. |
1750 |
|
1751 |
other_arch <other obj> which other O this G generates. |
1752 |
More use between linked object defs. |
1753 |
|
1754 |
anim |
1755 |
. which bitmaps to use in animation of the O. |
1756 |
. If TEAR_DOWN flag is set, this contains the different |
1757 |
. stages of being destroyed. |
1758 |
face name Name of the face (ie, food.111) |
1759 |
. |
1760 |
mina |
1761 |
end terminates definition of this O. |
1762 |
|
1763 |
last_heal <no> Internal use (for regaining hit-points) |
1764 |
last_sp <no> Internal use (for regaining spell-points) |
1765 |
last_eat <no> Internal use (for consuming food) |
1766 |
|
1767 |
speed <no> speed of O. A negative number means that speed_left |
1768 |
will be randomized when the object is loaded. |
1769 |
speed_left <no> speed of O remaining, internal. |
1770 |
face <bmap no> bitmap first drawn for O. |
1771 |
Str,Dex,Con, |
1772 |
Wis,Cha,Int <no> default ability for O. |
1773 |
hp,maxhp,sp,maxsp <no> default value for O hitpoints, spellpoints. |
1774 |
maxsp In main.c:fire() which arrowtype to use |
1775 |
Number equal to to the arrows type definition. |
1776 |
|
1777 |
exp <no> Xp gained for killing O. |
1778 |
food <no> nutrition value for O. *DANGEROUS* as it's also |
1779 |
used to contain internal values for non-edible |
1780 |
objects. This should be changed in future. |
1781 |
dam,wc,ac <no> default damage, weaponclass, armorclass. |
1782 |
dam 0 gives a 'friendly' monster ;) |
1783 |
wc main.c:move_gate(). Is used by gates to indicate in |
1784 |
which position they are. |
1785 |
x,y <no> relative coords for bmap when using large objects. |
1786 |
x=y=0 is default, x=1 is second bmap in first row etc. |
1787 |
nrof <no> No. of O:s. 0 means that objects of this type |
1788 |
are not to be joined/split (it's a lone object). |
1789 |
level <no> O:s level. |
1790 |
direction In which direction (1=north, 8=north-west) this O is |
1791 |
moving (flying). Simple schematic of the dirs: |
1792 |
812 |
1793 |
7-3 |
1794 |
654 |
1795 |
|
1796 |
type <no> the object as defined in 'defines.h' |
1797 |
material <no> the sum of materials in this O. (see materials.) |
1798 |
value <no> the value for this O. |
1799 |
weight <no> the weight for this O. |
1800 |
carrying sum of the weight of objects within this object. |
1801 |
|
1802 |
attacktype <no> type of attack from O. (see attacks) |
1803 |
|
1804 |
invisible <1> set if O is invisible. |
1805 |
magic <no> magic modifier of O. (bracers +3 has magic 3) |
1806 |
state internal. Used when animating the object |
1807 |
alive <1> set if O is alive (can be attacked). |
1808 |
applied set if object is readied/worn/etc. |
1809 |
unpaid set if object is unpaid (internal) |
1810 |
|
1811 |
no_pick <1> set if O can't be taken. |
1812 |
no_pass <1> set if O can't be passed. (eg, a closed door) |
1813 |
walk_on <1> O is applied by anything walking onto it. |
1814 |
walk_off <1> O is applied by anything walking off it. |
1815 |
fly_on <1> O is applied by anything flying onto it |
1816 |
fly_off <1> O is applied by anything flying off it. |
1817 |
is_animated <1> set if O is animated. |
1818 |
|
1819 |
flying <1> set if O is flying (used in fly_on/fly_off). |
1820 |
monster <1> set if O is a monster. |
1821 |
friendly Not used yet. |
1822 |
generator <1> set if O is a generator. |
1823 |
auto_apply <1> O is applied when it is loaded (for instance, some |
1824 |
chests open automatically when the map is loaded) |
1825 |
treasure <1> not used yet. |
1826 |
|
1827 |
apply_once <1> not used yet |
1828 |
see_invisible <1> set if O can see invisible player. |
1829 |
can_roll <1> set if O can be rolled. |
1830 |
is_turnable <1> set if O can be turned 'automagically' |
1831 |
|
1832 |
is_lightable <1> set if O is something like a lantern that can be lit |
1833 |
is_used_up <1> bizarre. O is used up after created, eg an explosion. |
1834 |
identified <1> true if the item has been identified. |
1835 |
reflecting <1> set if O is reflective. |
1836 |
changing <1> set if O will change appearance. |
1837 |
splitting <1> set if O will divide. |
1838 |
hitback <1> set if O hits when being hit. |
1839 |
|
1840 |
blocksview <1> set if O blocks line of sight. |
1841 |
undead <1> set if O is undead. |
1842 |
scared <1> internal (O is running away from players right now) |
1843 |
unaggressive <1> internal (not used yet) |
1844 |
|
1845 |
color_fg <no> foreground color of O. Remember to set face/anim first! |
1846 |
color_bg <no> background -"- - "" - |
1847 |
reflect_missile <1> set if O throws back missiles. |
1848 |
reflect_spell <1> set if O throws back spells (some). |
1849 |
no_magic <1> set if O totally resists magic (*use with care*) |
1850 |
|
1851 |
tear_down <1> set if O can be torn down (using animations and hp). |
1852 |
run_away <no %> percentile of hp left which causes monster to flee. |
1853 |
|
1854 |
pass_thru <1> set if O can be passed thru by objects <below>. |
1855 |
can_pass_thru <1> set if O can pass thru objects <above> |
1856 |
pick_up <value> Which items monster will pick up (see pickup (above)) |
1857 |
|
1858 |
is_buildable <1> set if items can be built on top of this O. |
1859 |
|
1860 |
******************************************************************************* |
1861 |
6. TREASURES (and Abilities) |
1862 |
******************************************************************************* |
1863 |
|
1864 |
The treasures are kept in LIBDIR/treasures. Their format is: |
1865 |
|
1866 |
treasure <name> |
1867 |
<item> |
1868 |
more |
1869 |
<item> |
1870 |
end |
1871 |
|
1872 |
Also, 'treasure' above can instead be 'treasureone'. This means |
1873 |
that only 1 item on that list will be generated. The chance for |
1874 |
all objects on that list are summed together, and one is then generated. |
1875 |
|
1876 |
And the format for an item is: |
1877 |
|
1878 |
arch <name> |
1879 |
nrof <n (random 1 to n items generated)> |
1880 |
magic <max-magic> |
1881 |
chance <1-100%> |
1882 |
yes |
1883 |
<item> |
1884 |
no |
1885 |
<item> |
1886 |
end (or "more", if this is not the last element) |
1887 |
|
1888 |
If "magic" or "nrof" is omitted, it is set to 0. |
1889 |
If "chance" is omitted, it is set to 100%. |
1890 |
"yes" tells what can be generated if this item was generated. |
1891 |
"no" tells what can be generated if this item was not generated. |
1892 |
"yes" and "no" can of course be omitted. |
1893 |
|
1894 |
Note: the 'no' and 'yes' fields are meaningless in treasureone |
1895 |
treasurelists. |
1896 |
|
1897 |
Also, instead of an item, a list to transfer to can be used instead. |
1898 |
The format is the same as for an object, but instead 'list <list>' is |
1899 |
used instead of 'arch <name>'. |
1900 |
|
1901 |
For list transitions, the chance, yes and no fields have the |
1902 |
same meaning. 'magic' is used to determine the difficulty required |
1903 |
to transfer to the new list. |
1904 |
|
1905 |
If the list is of type 'treasureone', and a list transition fails, |
1906 |
what happens next is determined by the 'nrof' field. If it is zero, |
1907 |
no object is generated. If 'nrof' is one, than another attempt is |
1908 |
made to generate an item (or list transition) from that treasurelist. There |
1909 |
is a maximum number of attempts that can be made. |
1910 |
|
1911 |
Also, a reserved list name of 'NONE' is allowed. This means that no |
1912 |
item should be generated (of relevence only on treasureone lists.) |
1913 |
|
1914 |
To use such a treasure, just put "randomitem <name>" into any |
1915 |
archetype in the archetype-file. Random treasure will then be generated |
1916 |
whenever such a monster is generated by generator, or when a map |
1917 |
containing such <monsters> is loaded for the first time. |
1918 |
|
1919 |
ABILITIES |
1920 |
|
1921 |
Adding in invisible objects like known spells and skills gives these abilities |
1922 |
to the object. |
1923 |
|
1924 |
for example: |
1925 |
|
1926 |
treasure pirate |
1927 |
arch skill_stealing |
1928 |
chance 50 |
1929 |
arch skill_throwing |
1930 |
no |
1931 |
arch skill_punching |
1932 |
end |
1933 |
more |
1934 |
arch heart |
1935 |
chance 5 |
1936 |
more |
1937 |
list standard |
1938 |
end |
1939 |
|
1940 |
or |
1941 |
|
1942 |
treasure skeletalmage |
1943 |
list standard_old |
1944 |
more |
1945 |
arch ability_fear |
1946 |
more |
1947 |
arch ability_frostbolt |
1948 |
chance 67 |
1949 |
end |
1950 |
|
1951 |
Treasure lists of gods are special. See below. |
1952 |
|
1953 |
------------------------------------------------------------------------------ |
1954 |
GOD INTERVENTION: |
1955 |
|
1956 |
Treasure lists of gods are special. They must be of 'treasure' type, |
1957 |
not 'treasureone', and the 'yes' and 'no' fields must not be used. |
1958 |
The contents of a god's treasure list is not used by |
1959 |
create_treasure(), but by god_intervention() which traverses this list |
1960 |
from beginning to end until an item causes an action. The "chance" in |
1961 |
the treasure list can be used to randomly skip items, but items that |
1962 |
don't have an effect (e.g. healing follower, but follower isn't |
1963 |
injured) will be skipped anyway. The meaning of the different items |
1964 |
in the list is: |
1965 |
|
1966 |
Treasure list reference: |
1967 |
|
1968 |
Such a list is passed to create_treasure() with flag GT_STARTEQUIP. |
1969 |
The generated treasure is put into the followers inventory. The |
1970 |
follower can get unlimited amounts of this treasure just by praying |
1971 |
long enough. See below ("other visible items") for an alternative |
1972 |
way of giving items to followers. |
1973 |
|
1974 |
Invisible books (with specific names): |
1975 |
|
1976 |
Can be accessed through determine_holy_arch() which will return the |
1977 |
item's other_arch field. For example, such book with name "avatar" |
1978 |
determines the avatar archetype for the "summon avatar" prayer. |
1979 |
|
1980 |
Invisible book with name "grace limit": |
1981 |
|
1982 |
If follower doesn't have maximum grace, or follower's grace is less |
1983 |
than item->stats.grace, a "holy possession" prayer is invoked and the |
1984 |
function returns. Can be used to limit the lower part of the treasure |
1985 |
list to followers with much grace. |
1986 |
|
1987 |
Invisible book with name "restore grace": |
1988 |
|
1989 |
If the follower's grace is negative, sets the grace to a small |
1990 |
positive value and returns. |
1991 |
|
1992 |
Invisible book with name "restore hitpoints": |
1993 |
|
1994 |
If the follower's hitpoints are not at their maximum, sets hitpoints |
1995 |
to maximum and returns. |
1996 |
|
1997 |
Invisible book with name "restore spellpoints": |
1998 |
|
1999 |
Can restore the followers spellpoints. The maximum spellpoints for |
2000 |
this effect are calculated using this formula: |
2001 |
|
2002 |
max = follower->stats.maxsp * (item->stats.maxsp / 100.0) |
2003 |
|
2004 |
In other words, the item's stats.maxsp is the maximum in percent |
2005 |
relative to the followers normal spellpoint maximum. If the followers |
2006 |
current spellpoints are below 50% of 'max', they are set to a random |
2007 |
value between 50% and 100% of 'max', and the function returns. |
2008 |
|
2009 |
Invisible book with name "heal spell": |
2010 |
|
2011 |
Casts a heal spell (which spell is determined by item's slaying or |
2012 |
stats.sp field) and returns if the spell was successful. |
2013 |
|
2014 |
Invisible book with name "remove curse": |
2015 |
|
2016 |
Removes curse from all cursed (but not damned) items, returns if curse |
2017 |
was removed from at least one item. |
2018 |
|
2019 |
Invisible book with name "remove damnation": |
2020 |
|
2021 |
Removes curse and damnation from all cursed or damned items, returns |
2022 |
if curse or damnation was removed from at least one item. |
2023 |
|
2024 |
Invisible book with name "heal depletion": |
2025 |
|
2026 |
Removes all depletion effects and returns unless the follower's stats |
2027 |
were not depleted. |
2028 |
|
2029 |
Invisible book with name "voice_behind": |
2030 |
|
2031 |
The follower hears a voice from behind. item->msg is what the voice |
2032 |
says. Always returns. |
2033 |
|
2034 |
Invisible book with name "message": |
2035 |
|
2036 |
The follower receives item->msg as a simple message. Always returns. |
2037 |
|
2038 |
Invisible book with name "enchant weapon": |
2039 |
|
2040 |
The follower's weapon is enchanted in various ways. item->level |
2041 |
affects how much the weapon is enchanted, higher value means less |
2042 |
enchantment. |
2043 |
|
2044 |
Invisible spellbooks: |
2045 |
|
2046 |
If the prayer in the book is not yet known to the follower, and the |
2047 |
follower has the required level, teaches the prayer to the follower |
2048 |
and returns. The prayer is determined by item's slaying field. |
2049 |
|
2050 |
Visible spellbooks: |
2051 |
|
2052 |
If the prayer in the book is not yet known to the follower, the |
2053 |
follower has the required level, and the follower doesn't already have |
2054 |
a spellbook with that prayer, gives a copy of this spellbook to the |
2055 |
follower and returns. The item must have FLAG_STARTEQUIP. The prayer |
2056 |
is determined by item's slaying field. |
2057 |
|
2058 |
Other visible items: |
2059 |
|
2060 |
If the follower doesn't already have this or a similar item (with same |
2061 |
type, name, title, msg and slaying fields), gives a copy of this item |
2062 |
to the follower. You have to set FLAG_STARTEQUIP in the archetype |
2063 |
yourself if you wan't the copy to have this flag. This method (with |
2064 |
FLAG_STARTEQUIP set) should be prefered for giving items to followers, |
2065 |
because it is rather safe to use. The amount is limited, because if |
2066 |
the follower wants more of it he has to go back to an altar of his |
2067 |
god. He can't pray an hour over an altar and then go fighting with a |
2068 |
hundred potions of restoration. |
2069 |
|
2070 |
Other invisible items: |
2071 |
|
2072 |
If the follower doesn't already have it this item, gives it, similar |
2073 |
to visible items. Except, it ALWAYS gives it, upon conversion. |
2074 |
And on conversion to another religion, it is ALWAYS removed. |
2075 |
Signs and forces and skills may not be given/taken this way. |
2076 |
|
2077 |
*************************************************************************************** |
2078 |
7. Misc change description: |
2079 |
*************************************************************************************** |
2080 |
The following area describes various comments about various pieces of |
2081 |
code. In general, the information describes a basic idea of how things |
2082 |
work. The following may not really be necessary, but I figure that it is |
2083 |
probably worth saving, and this seemed to be as good as place as any. |
2084 |
|
2085 |
LIGHTING CODE (by Brian Thomas): |
2086 |
- fast calculation of lighting. For players los (line- of |
2087 |
sight)is calculated from a linked list of nearby lights. |
2088 |
For monsters, no los is calculated, rather a modified |
2089 |
check_wakeup routine is used to see if they will |
2090 |
follow/attack players. Monsters with can_see_in_dark act |
2091 |
normally in dark areas. |
2092 |
|
2093 |
- New attacktype -AT_BLIND. This is a pretty severe penalty |
2094 |
for monsters and players alike. Players cant see any square |
2095 |
but thier own, monsters can only attack/follow players who |
2096 |
are in an adjacent square. Need to make the monsters stumble |
2097 |
around when no player is near, rather than the current way |
2098 |
in which they stand around waiting to get "ace'd". Undead |
2099 |
cannot be blinded, nor should be effected by darkness. For |
2100 |
other monsters, if they have immunity to blindness or can |
2101 |
see invisible, they are uneffected by AT_BLIND attacks. |
2102 |
|
2103 |
- New spells. Some magician, some clerical. They work, but |
2104 |
may need to be adjusted for playbalance. Normal spells |
2105 |
available include: "light", "darkness", "sunspear", "faery |
2106 |
fire" and "dark vision". All spells (but darkvision) work |
2107 |
(do something) whether the lighting code is used or not. |
2108 |
|
2109 |
- Modified archetypes and artifacts list to encompass changes |
2110 |
to the code from lighting. Also, some new archs instroduced, |
2111 |
namely "flint and steel" for lighting stuff on fire and |
2112 |
"torch" a source of light. |
2113 |
|
2114 |
|
2115 |
|
2116 |
*************************************************************************************** |
2117 |
8. How to add new values |
2118 |
*************************************************************************************** |
2119 |
|
2120 |
This section details how to add new fields/flags to an object structure. |
2121 |
|
2122 |
1) Send mail to the development list to make sure that a new element is really |
2123 |
added. |
2124 |
|
2125 |
For flags: |
2126 |
|
2127 |
2) Update the FLAG_.. entries in include/define.h for your new flag. Recycle unused |
2128 |
values if possible - there may be cases where you want to group the new flags together. |
2129 |
If you are adding beyond the end of the existing values, update the NUM_FLAGS entry |
2130 |
|
2131 |
3) Decide the name of your flag as loaded/saved in objects. The default syntax is |
2132 |
the name you assigned in step 2 above, minus the leading flag_ part. |
2133 |
|
2134 |
4) In the common/loader.l, update the load section (where the code is mostly ^value |
2135 |
SET_OR_CLEAR(...)) add your entries in. |
2136 |
|
2137 |
5) update the flag_names in common/loader.l. The location of your names _must_ be |
2138 |
in the same array location as the FLAG_ value. |
2139 |
|
2140 |
6) Update other areas of the code that you presumably know about that will use these |
2141 |
flag values. |
2142 |
|
2143 |
7) As appropriate, update the arch files and rebuild. |
2144 |
|
2145 |
|
2146 |
******************************************************************************* |
2147 |
9. PROGRAMMING NOTES |
2148 |
******************************************************************************** |
2149 |
|
2150 |
This section provides some specific programming notes about objects. If |
2151 |
you don't actually work with the C code, there is no need to read this section. |
2152 |
|
2153 |
Basically, all the char* pointers in the object structure use a shared |
2154 |
string library. Using shared strings saves memory and improved performance. |
2155 |
|
2156 |
To use the share string library, it is as simple as calling add_string(char |
2157 |
*cp), where *cp is the pointer to the string you want to add. You can pass |
2158 |
defined strings also. The function the finds the string, if it exists, |
2159 |
increases the referecne count, and returns a pointer to the existing string. |
2160 |
If the string does not exist in the table, it allocates space for it, copies |
2161 |
the data into the space, and returns that new pointer. |
2162 |
|
2163 |
free_string should be called to free these strings. |
2164 |
|
2165 |
strdup and free should never be used on these shared strings. |
2166 |
|
2167 |
When copying objects, the copy_object routine should always be used. It will |
2168 |
add reference counts to the copied strings. |
2169 |
|
2170 |
Because shared strings will return a pointer to a string if it |
2171 |
exists, one can see if the strings are equal by comparing the shared |
2172 |
string address they point to. |
2173 |
|
2174 |
Shared string data should never be modified by any means - eg, |
2175 |
strcpy(op->name, "new value") will update all the objects that use the same |
2176 |
shared string as op does for its name. Even without shared strings, this |
2177 |
should never be done, because you can not be sure of the space allocation for |
2178 |
op->name is long enough. |