[CF-Devel] Traps not working reliable

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