[CF-Devel] button.c, bug in multi-tile door animations

Mark Wedel mwedel at sonic.net
Sat Sep 7 16:11:08 CDT 2002


Kurt Fitzner wrote:
>
     
      Sorry for all the posts.  I'll start making them in digest format to get it
     
     >
     
      all at once. :)
     
     >
     
     
     >
     
      I've noticed that mine_secret_1_1 and mine_secret_2_1, which are type 26
     
     >
     
      (timed gate) multi-tile doors don't quite work properly.  The issue is that
     
     >
     
      only one tile's animation seems to get used on the correct 'connected' value.
     
     >
     
     
     >
     
      I've fixed this with a slight mod to button.c, but I'm not sure if this is the
     
     >
     
      correct place for it:
     
     >
     
     
     >
     
          case TIMED_GATE:
     
     >
     
              while (tmp) {
     
     >
     
                  tmp->speed = tmp->arch->clone.speed;
     
     >
     
                  update_ob_speed(tmp);  /* original values */
     
     >
     
                  tmp->value = tmp->arch->clone.value;
     
     >
     
                  tmp->stats.sp = 1;
     
     >
     
                  tmp->stats.hp = tmp->stats.maxhp;
     
     >
     
                  tmp = tmp->more;
     
     >
     
              }
     
     >
     
              break;
     
     >
     
     
     >
     
      Another way to fix is to call add_button_link() for every tile in a muli-tile
     
     >
     
      archetype that has a connected value.
     
     >
     
     
     >
     
      I noticed that even though the head tile was the only one that activated on
     
     >
     
      the correct button, that sometimes (without rhyme or reason) the second tile
     
     >
     
      would get activated.  I only noticed this a handful of times, and I've been
     
     >
     
      unable to duplicate it in a debugger.  At first I thought maybe the second
     
     >
     
      tile was getting connected to zero, but that doesn't seem to be the case.
     
     
  Another place to make the change would be to the move_gate() in server/time.c. 
  But then again, I'm not sure about that as I think about it - while in theory 
the gates should be synced up, that doesn't happen in numerous cases (eg, 
something on the gate preventing it from closing) - if they were linked up, you 
could get a case where the first gate has done all its work, but the second gate 
isn't done yet, but since the first gate isn't processing, the second gate stays 
in that odd state.

  I'm a little concerned about the above method - In most cases, a lot of the 
code refers to the head for proper values.  Certainly for things like monsters, 
the head is the piece that gets called to action, and the code that moves the 
head deals with moving the rest of the monster.  So I'm concerned that at some 
level, people may think that the values for the second piece (like the type 
value) are not really necessary - if that type value got removed, the above 
suggestions would not work, as the second piece would not have proper type value.

  But it is probably easiest to say something like 'gates are a special case - 
the values in the second piece are important'.  Or maybe just add a line to your 
above code which also sets the type value.

  As I think about it, thats probably what I'll do.




    
    


More information about the crossfire mailing list