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.