(25 Jul 12, 08:07PM)Mael Wrote: Looking through the source recently I saw that a demo is basically just the packets sent by players to the server(obviously).Actually, it's the packets sent from the server to the (i.e. all) clients, but you got the idea.
(25 Jul 12, 08:07PM)Mael Wrote: So each part of the packet describes position, yaw, pitch, and other values at that point in time. When you play a demo you are reading the positions, yaws, pitches, etc. from each packet and interpolating to fill in the gaps. I don't see any reason you couldn't play those packets in the opposite direction. Or even skip packets.Correct, but that's only true for the position packets. There are others as well (e.g. shoot, reload, died, item spawned,...), look in protocol.h for the full list. To roll those back, you'd need to undo whatever effect they had (e.g. "revive" a player, add ammo back into the magazine,...). As you noticed, the demos consist of packets as they were sent during the game. They incrementally rebuild whatever happened in the game, contrarily to e.g. a (non-compressed) video where every frame contains all the information available for that specific point in time.
Sure rewinding a demo is still possible, but it would be a PITA to implement, and you'd basically have tons of code just "mirroring" the functionality of other code.
Skipping packets, on the other hand, is completely impossible for anything but position packets. Well, not impossible of course, but the game/demo would completely desynchronize.
(25 Jul 12, 08:07PM)Mael Wrote: Speaking of packets, I noticed that the packets have the potential to vary in size. I wonder if it would be possible to reduce the size of packets sent to the server while some constant action is taking place.You would be correct, but basically there are no packets being sent for constant action. Even the position packets will almost always have some delta to the previous one (position - even if it's just rounding error, orientation, velocity). You'll hardly ever stand completely still.
(25 Jul 12, 08:07PM)Mael Wrote: For instance, when a player is afk/dead, must they really attempt to send 25 packets per second telling the server their position, yaw, pitch, etc? If something like a variable width packet is possible the first bit of data might describe whether any action was taken by the player. If no action is taken the server knows they must be standing still and there is no need for the server to receive position data(or any data for that matter). The first bit tells the server no change was made and the server just uses the previous packet's data.Something like this should be possible, at least for dead players.
(25 Jul 12, 08:07PM)Mael Wrote: More generally, until some change has taken place between two packets is it really necessary to update the server with every bit of data? If I'm running in a straight line down a corridor, maybe swinging my aim around, the only thing that has changed is my position, yaw, and pitch. Why not just send the data that has changed? Upon firing my weapon I can report to the server that such action has taken place and the server becomes aware of my new status.Well, but that's exactly what's happening already ;) The only thing that's being sent continuously is the position packet with position, yaw/pitch/roll etc. See above.