On Fri, 19 May 2006, William Balcerski wrote: > Right, the delay is set to 0, but not before the server would send a > newwarning message to client that your battle computers are being > reprogrammed. This prevents that message from being sent (I came across True, but that is not what your message said. It's not the delay that is being removed, but the incorrect warning message. > this while adding a timer client-side to keep track of declare war delay. > If the server is not going to give us a delay, the delay message should > not be sent, period.) 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. > As for bots, the whole problem with observers locking onto iggies and then > not being able to do anything (lock onto someone else, quit, etc) was due > to bots being in a permanent state of delay (their war timer is never > decremented like a player's timer). This was partially fixed by a 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. > previous patch of mine by not masking the PFWAR flag to observers. This > second patch gets at the root of the problem - bots should not be flagged > PFWAR. Of course, bots don't freeze cause they don't have to input > anything. 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.