[CF-Devel] Traps not working reliable

crossfire-devel at archives.real-time.com crossfire-devel at archives.real-time.com
Mon Aug 30 02:00:33 CDT 2004


Andreas Kirschbaum wrote:
>
     
      I noticed that some traps (in chests and doors) do not work reliable
     
     >
     
      anymore. Sometimes you set off a trap, but nothing happens.
     
     >
     
     
     >
     
      My investigations resulted in:
     
     >
     
     
     >
     
       - There is a bug in trap_adjust() in server/rune.c. The code basically
     
     >
     
         does "level = MAX(1, rndm(...))" to ensure "level >= 1".
     
     >
     
     
     >
     
         This does not work because MAX() is a macro and evaluates its
     
     >
     
         arguments multiple times. The result may be a trap (RUNE) with level
     
     >
     
         zero: a rune that does not detonate.
     
     
  That seems bad.  Taking a very quick look at the code (for all other uses of 
MAX), I'm a little concerned with random_roll() and die_roll() which is pasiing 
RANDOM() into MAX (actually, it passes it into MIN, which is inside a MAX 
construct).

>
     
     
     >
     
       - It seem me that there are three ways to puts spells into runes:
     
     >
     
     
     >
     
         1) put an item (spell) into inventory
     
     >
     
     
     >
     
         2) use spell name in 'slaying' field
     
     >
     
     
     >
     
         3) use archetype name in 'other_arch' field
     
     >
     
     
     >
     
         For traps,
     
     >
     
     
     >
     
         1) can't be used because inventory items can't be used in archetypes.
     
     
  Yeah - that's been a problem.  My solution to that is to create a one item 
treasurelist with the desired object.

>
     
     
     >
     
         2) The 'slaying' field (or the obsolete spell number in the 'sp'
     
     >
     
            field) is converted to an inventory item by check_loaded_object()
     
     >
     
            in loader.l. However, this conversion is not done by
     
     >
     
            create_all_treasures()/create_one_treasure() in treasure.c.
     
     >
     
     
     >
     
            spring_trap() in server/rune.c does not use the 'slaying' field,
     
     >
     
            only inventory items or the 'other_arch' field.
     
     >
     
     
     >
     
            Therefore runes using the slaying field do not work when created
     
     >
     
            by a treasure list.
     
     
This is perhaps left over from the old code - probably no reason it has to be used.

>
     
     
     >
     
         3) The other_arch field does work. But I'm not sure if that is the
     
     >
     
            preferred way: doc/Developers/runes, server/rune.c, and
     
     >
     
            CFJavaEditor specify to use the 'slaying' field but do not mention
     
     >
     
            the 'other_arch' field.
     
     
  One difference is slaying is just a text field, where as other_arch has to 
point to another active archetype.  Now in most all cases, I can't think of this 
being a problem (a new spell created on a map can't be put into a rune, because 
you can never be sure that object is available).  other_arch is certainly faster 
to resolve, but probably no issue here.  So I think using other_arch works out 
good here.

>
     
     
     >
     
      After fixing the bug in rune.c and changing most runes in the archetypes
     
     >
     
      file according to 3), I got all kinds of traps working again. I
     
     >
     
      summarized some attributes of the runes in runes-old.txt/runes-new.txt,
     
     >
     
      because the diff of the archetypes file is not very clear.
     
     
  Note that you can do diffs in the arch directory - that would probably produce 
the clearer, albeit more verbose results.  I agree that a diff of the archetype 
file is relative hard to see.

>
     
     
     >
     
      Besides that, I re-enabled the 'maxhp' field for runes to cast more than
     
     >
     
      one spell. Now it works for all types of spells, not just for summoning
     
     >
     
      spells.
     
     
  I don't see any problems with the code in my quick look over.


_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel
     
     
    


More information about the crossfire mailing list