> True, but that is not what your message said. It's not the delay that > is being removed, but the incorrect warning message. You are right, the ChangeLog entry should say "unwanted war delay message" instead of "unwanted war delay". > Trying to copy my ideas from Paradise-2000 I see. You can make a working > client side timer without changing the server by turning the timer off if the > PFWAR flag goes away. > Yes I could do this, but the server shouldn't be sending that message regardless. > The timer isn't exactly decremented. Rather, it is the absolute time the > delay should turn off. The player's p_updates counter is incremented every > update and the delay turns off when it p_updates reaches the delay or rdelay > value. I think the problem is that the code to check for this is in the alarm > sig handler that server robots don't use. > Yup. From design standpoint, I guess one could ask: should robots get "freeze" when declaring war? If so, they are going to have to pass through whatever function keeps track of updates. This patch would still be compatable with that scenario - just change robot call to declare_war to add delay (int 0 to 1) > Ok, that make sense. Does this mean masking the WAR flag for observers can be > removed? That way you could still see if the observee had declared war. > > I wonder, does a similar issue exist for refit? I don't think the bots will > ever get their PFREFITTING flag set, but once they do, it won't go away > either. > No, the WAR flag for obs still can't be masked - the one place where the delay in declare_war is needed (in socket handler) is the same place where both player and observer would send declare war request. A similar issue existed with observing obs'ing someone who was refitting - it froze up observer with same delay timer. Previous patch fixed this issue as well. Bots don't ever get PREFIT set, and but yes it wouldn't go away either. Bill