Todd Mitchell wrote: > Ok, I didn't think I was so dim witted but I guess i am...<pause for you > to stop nodding> anyway I have a proposal: > step 1. add an entry to the define.h : #DEFINE TIMER 125 correct. > step 2. add code to button.c ... (why - it's a button - what if it's was > say a boat?) button.c is basically what activates other objects when they are 'pushed'. The name isn't great for the file (connected.c would be more accurate), but this probably dates back to when the only connected objects were button. > step 3. make entry in loader.c : (a case statement entry for say type > #125?) nope - no change needed there. > step 4. create arch... > other steps...? Well, how you envision it, I'd say this: The code (or function) called in button.c would set up various values - it would set the speed of the object to non zero (depends how fast it should tick), reset the food/charges/whatever value for how long it ticks, and call update_ob_speed. Add code in time.c that looks for the TIMER object. This code will be called each time the timer gets an action (which is determined by its speed). that function should print something like 'tick' or whatever. Note, it would need to print it on the map or look for nearby players, as at this point, you no longer know who activated it. That function would decrease food/charges/whatever. When it reaches zero, it does it other action (pushes other connected objects, prints messages, whatever). It would also reset its speed to zero, and make the call to update_ob_speed. If the 'is_used_up' flag is used, then that would mean it could only get activated once. Easiest thing is for it to just remove itself - since it is invisible, no need to worry about showing a used up version (like altars). However, the alternative is to use some variable to denote the object has been used, and if so, the code in button.c doesn't do anything if that value is set. Most likely, the code in button.c shouldn't do anything if it is already ticking down, eg, a player shouldn't be able to reset that ticking bomb. _______________________________________________ crossfire-devel mailing list crossfire-devel at lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel