[CF-Devel] Some bugs/comments in crossfire.metalforge.net

[crossfire-devel at archives.real-time.com]

Nicolas Weeger wrote:
>
     
      Ok, I checked why some traps are broken.
     
     >
     
     
     >
     
      Apprently, it's a missing other_arch field.
     
     >
     
      Some runes, like 'mass confusion', have the slaying field filled in 
     
     >
     
      (slaying mass confusion), but no other_arch field. Those runes don't work.
     
     >
     
      Other runes, like 'rune_icestorm', have the 'other arch' field set 
     
     >
     
      (other_arch spell_icestorm) and work.
     
     >
     
      So I assume it's related to that :)
     
     
  In theory, the loader is suppose to take care of this.  Since the spell stuff 
was changed around a bit, I added some code in the loader that attempts to 
update these 'old' objects.

  The specific case here is is if the type is a rune, and slaying is set, it 
tries to convert that slaying into the spell object and insert it into the rune.

  This apparantly doesn't work really well.

  One limitation I ran into doing the spell code is that you can't have 
archetypes with inventory (and even if you did, when copy_object is called, it 
wouldn't copy the inventory anyways).

  However, the real solution here is to just update all the traps to use other_arch.

  However, I just tried the run of confusion on a test map, and it detonated fine.

  The problem I found however is different - the rune casts a cone, and if 
you're in the center of a cone, you're not hit by the effects (players can cast 
cones on themselves and also avoid the damage/effect, but hit everyone around them).

  One solution to this is to change the cone code such that it being cast with 0 
direction does affect the caster/person on that space.  I don't know how often 
players cast cone spells centered on themselves expecting no damage.

  If that is not a viable solution, then a flag or perhaps something in the 
spell itself needs to be set that says hit centered space.

  If it's a flag, the spring_trap() code could just be modified to set that flag 
in the spell before calling cast_spell(), removing the need for a seperate arch 
for trap objects.



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