Server-side recording and admin spectator system

[Chomenor]

This adds basic server-side recording support, enabled by sv_recordAutoRecording 1. Recorded files can be converted to the standard dm_68 demo format for playback. It also allows admins to spectate the server without joining, enabled by setting sv_adminSpectatorPassword, which can be useful to monitor for cheating.

I expect this should generally work with any mods that are compatible with client-side demos, but if any compatibility issues do come up they probably shouldn't be hard to fix.

Current limitations / features which could be added later:

• No built-in compression; currently post-compressing record files with zip or 7z reduces size by ~2x-3x.
• No free-movement spectating.
• No direct playback of .rec files. Must be converted to demo before playing.

[Chomenor]

I think this should be safe to merge, as it shouldn't have any effects unless enabled by cvar. I can help support it with fixes and improvements in the future. If there is interest I might be able to add Q3SDC-like live replay support.

Feel free to let me know if you have any questions or changes to request.

[froschgrosch]

@ec- I don't mean to disturb or annoy you, but will this be merged eventually? I'm using the server-side demo recording feature and had no issues so far.

[ec-]

@ec- I don't mean to disturb or annoy you, but will this be merged eventually? I'm using the server-side demo recording feature and had no issues so far.

I already have more advanced code, I'm not ready to merge neither implementation

[Chomenor]

Is this other implementation publicly available? What do you believe makes it more advanced, if you don't mind my asking?

[ec-]

@Chomenor q3e-mv.diff.zip It can automatically record on server side or broadcast multiview stream to allowed clients with efficient compression, mv demos contains all entities/playerstates, you can switch between then using mouse1 and record dm68-compatible demos during that

[ec-]

This all is only for reference/research, I'm not going to merge anything in near future

[Chomenor]

@ec- I was able to get your implementation to run and do some basic testing. Here is roughly how I would say my implementation compares in its current state:

Advantages:

• Much lower code footprint in main codebase (11 lines of non-header code in server vs. thousands of lines integrated in client and server)
• Allows me to contribute to the project, potentially freeing your time to work on other things

Disadvantages:

• About 2x larger record filesize without post-compression (but about equal with zip/7z post-compression applied)
• No direct playback of record files, must be converted to demo first, no live player switching

I think it's very feasible that I could add direct playback support and compression improvements (among other things) to my implementation. It's just an issue of not being worth the time unless there is at least a plan for it being merged into q3e.

Is there any downside to merging my implementation? It's useful now, it adds barely any complexity outside of its own source files, and you can revert it at any time. You can give me a chance to improve it and fix the missing features. If it doesn't work out you can always switch it for your implementation later, or even keep both since they seem to coexist without issues.

[ec-]

I won't merge anything that I can't handle

[Chomenor]

I assume I would be responsible for bigger changes (like direct playback, free spectating, or skip/rewind) since I'm more familiar with my own code and architecture. For more minor maintenance I'd assume you would be fine to handle it if you needed to. I don't think this is inherently less maintainable than anything else in the Q3 codebase.