Why can't everyone just live in my brain

Be careful what you wish for... :-)

When it comes to server->client state communication, it's been so long, I forget exactly what Quake 3 does. Something that's generally done, is to baseline entity states every so often. For example, round-robin entities, with the "base" state of one entity per packet. Then, send the inputs for each entity to all the clients. Again, enqueued for the next X ticks of simulation. This lets each client simulate the game on its own. If there should be some divergence, then the occasional baselining will take care of that.

Another time to send entity state update is when you detect server-side interference; being shot, colliding between players, etc.

The state compression a la Quake 3 can still be transmitted the same way -- "state in this packet equals state in the last packet you acknowledged, with the following fields changed" and a bit mask for which fields changed.

Btw: Firing weapons happens so often and with such low latency in an FPS, that reliable messages for that doesn't seem like a good idea to me. The really important events that need reliable packets are mainly main entity creation/deletion -- player spawn, death, perhaps health pack pick-up, etc.

Btw: Firing weapons happens so often and with such low latency in an FPS, that reliable messages for that doesn't seem like a good idea to me. The really important events that need reliable packets are mainly main entity creation/deletion -- player spawn, death, perhaps health pack pick-up, etc.

Agree -> UDP :-) Also didn't Quake3 use some kind of repetition of previous game states (in each packet transmitted) with unreliable sends? Kind of best of both worlds.

Btw: Firing weapons happens so often and with such low latency in an FPS, that reliable messages for that doesn't seem like a good idea to me. The really important events that need reliable packets are mainly main entity creation/deletion -- player spawn, death, perhaps health pack pick-up, etc.

Agree -> UDP :-) Also didn't Quake3 use some kind of repetition of previous game states (in each packet transmitted) with unreliable sends? Kind of best of both worlds.

spinningcube

They used input duplication (cl_packetdup), but not state duplication, as it's unnecessary.

You don't necessarily need reliable creation / deletion with reliable messages, it can also be part of the delta-compression protocol. (State (B) has entity E0, State (A) doesn't have entity E0 -> send entity E0 creation data + latest state). Maybe not as efficient as with a reliable stream, since you will send that creation data with every state until a state with that entity is acknowledged.

Btw: Firing weapons happens so often and with such low latency in an FPS, that reliable messages for that doesn't seem like a good idea to me. The really important events that need reliable packets are mainly main entity creation/deletion -- player spawn, death, perhaps health pack pick-up, etc.

Agree -> UDP :-) Also didn't Quake3 use some kind of repetition of previous game states (in each packet transmitted) with unreliable sends? Kind of best of both worlds.

They used input duplication (cl_packetdup), but not state duplication, as it's unnecessary.

Thanks, yes makes sense.