Demos

See code/client/cl_main.c for (most of) the code that is writing demo files. Each demo file has a “header” generated from the current client state in CL_Record_f(); this is followed by the actual network messages the client receives; messages are written by CL_WriteDemoMessage() which is called at the end of CL_PacketEvent(); each demo file has a “trailer” marking its end written by CL_StopRecording_f().

CL_Record_f() sets clc.demowaiting to true; CL_ParseSnapshot() in code/client/cl_parse.c sets it to false once a non-delta frame/snapshot arrives; messages until the non-delta frame/snapshot therefore don’t make it into the demo file (the call to CL_WriteDemoMessage() is guarded by !clc.demowaiting). In other words, the first message is always a non-delta frame.

Note that for playing back a demo, CL_ReadDemoMessage() simply drops each message back into CL_ParseServerMessage() again; so viewing a demo is definitely like playing the game without working controls. Whoa this doesn’t treat the header section any different?

Apparently all numbers are little endian, at least all of the functions that write data call things like LittleLong() and LittleShort() and stuff; those are macros defined in code/qcommon/q_platform.h

Note: For debugging demo issues cl_shownet is your best-est friend!

Header

No header in the “usual” sense: demo files don’t start the same way twice except by accident.The header starts with 4 bytes of clc.serverMessageSequence-1 why? followed by 4 bytes of length for the initial game state message which follows next. Verified against UrT 4.1 dm_68 demos. This message contains a mess of stuff, apparently as follows:

4 bytes of clc.reliableSequence
1 byte of svc_gamestate
4 bytes of clc.serverCommandSequence
variable number of config strings (each has 1 byte of svc_configstring, 2 bytes with the index of the string, n byte string, zero terminated really?)
variable number of entity baselines (each has 1 byte of svc_baseline, n bytes of MSG_WriteDeltaEntity() encoding too bizarre to understand)
1 byte of svc_EOF
4 bytes of clc.clientNum
4 bytes of clc.checksumFeed
1 byte of svc_EOF

Unverified

Messages

Each message is 4 bytes of clc.serverMessageSequence followed by 4 bytes of length (of the remaining data) followed by the actual data. Note that CL_WriteDemoMessage() skips “headerBytes” at the beginning of the original message. (This “headerBytes” seems to be whatever CL_Netchan_Process() had to read out of the message to do it’s magic.) Verified against UrT 4.1 dm_68 demos.

Trailer

Just 8 bytes of 1 bits, no special alignment. Verified against UrT 4.1 dm_68 demos.