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.

@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- 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

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

@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

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

@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.

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

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.