[CF-Devel] button.c magic mouth suggestions

Mark Wedel mwedel at sonic.net
Wed Sep 18 01:18:18 CDT 2002


Kurt Fitzner wrote:
>
     
      I'd like to make a suggestion for magic mouths.  After struggling in a map
     
     >
     
      editor for an hour on an esoteric problem, I finally realized that a slight
     
     >
     
      code change makes more sense.  The gist of the problem was that I needed a
     
     >
     
      magic mouth to be activated when a button was pushed, but not released.  I
     
     >
     
      can't think of why someone would want to 'connect' a magic mouth and then have
     
     >
     
      it respond to both push and release signals.  But, I'm sure that it happens,
     
     >
     
      so as not to break maps, I propose the following in button.c (line 75 or so)
     
     >
     
     
     >
     
          case SIGN:
     
     >
     
            if (!tmp->stats.sp || ((tmp->stats.sp > 0) && op->value)
     
     >
     
                             || ((tmp->stats.sp < 0) &&  !op->value))
     
     >
     
                if (!tmp->stats.food || tmp->last_eat < tmp->stats.food) {
     
     >
     
                  (*info_map_func)(NDI_UNIQUE | NDI_NAVY,tmp->map,tmp->msg);
     
     >
     
                  if (tmp->stats.food) tmp->last_eat++;
     
     >
     
                }
     
     >
     
            break;
     
     
  Just to come back to this -

  I've put the changes into CVS to do this.  I've updated the arch's, so make 
sure you use the updated archetype file, or connected objects won't work (as 
there is now both a activate on push and activate on release).  All the code in 
that function can be controlled by this.

  I wasn't all that clever when updating the archetypes - basically, all the 
affected archs have both values set - that keeps the old behaviour.

  given this is just 2 bits out of the FLAGS value (of which the memory is 
already there), I didn't do anything clever about putting it in an object 
subtype/substructure.  That is a seperate conversation, but I think a more 
notable change/addition to the object structure would be in order before making 
such a change.



    
    


More information about the crossfire mailing list