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