game ticks, frames, and packets aren't one and the same.. it's all about serializing and conveying the 'state' of the game.
I never said they were not the same. I said that I have already implemented my first interpretation of quake 3 method which at the very least requires serialization and packets and game state as well as the compression. So I could not think they were the same. Also I explicitly said get the delta compression part out of your mind .
It is no doubt my fault as I am horrible at communicating. Why can't everyone just live in my brain.
Bullets need to be sent reliably. Ie, they must be guaranteed to be received. Send one original position shot. Then do all the physics simulation. Easy.
Why would bullets be guaranteed from the server to the client? if someone shot a bullet 1 second ago I'm not going to display it because it is out of date. If you think you need it to calculate someone's health that will be done by the players state on server.
I am not sure if your talking about inputs from the client to the server or not. I understand from the client to the server of queuing commands.
I am more talking about getting entities sate that is on the server to clients so they can show the entities state. It is like the player input thing but in reverse. send 3 states taken at different times in a packet. not guaranteed though because we do not need old information.
It would have been nice to get a confirmation if that is what quake 3 uses or that this is the general idea of how this model should be implemented. I suppose no one really knows.
Missed papalazaru's message it was posted as I was writing.
Your idea about using state to communicate how many shots have been fired is interesting. I will give it some serious thought. Though things like flag caps I can represent with my broadcast event thing I have.
I had a look around quake 3 source. Though it would take for ever to understand where everything is to figure out what to look out for.