Offline replays

Development Feature Requests
1

Currently, Space Station 14 replay files from servers depend on an active internet connection, which can be inconvenient for users who want to access their replays offline or in areas with limited connectivity.

To improve this, replays should be fully self-contained. This means they should come packaged with all the necessary data, including engine files and dependencies, to allow them to be watched offline. Not only would this make the system more user-friendly, but it would also ensure that replays are preserved for long-term use without relying on external servers.

This change would enhance accessibility, simplify the viewing process, and contribute to the longevity of replay content. Even after a server goes down.

2

This is already possible, albeit not in a very user-friendly way. If you have a prebuilt client, or build your own from the source code, then you can load a replay into that. You are likely to run into severe issues if your client is not on the same commit as the replay, though, so this works best if you have a copy of the git branch of the codebase and can check out the replay’s commit

3

That’s kinda the core problem that this suggestion seeks to tackle. While the approach I proposed might lead to larger file sizes, the trade-off is worth it to ensure compatibility and standardization. A standardized format would eliminate the need for users to match commits or manage code branches, to view replays offline. It should be accessible and simple even to a non-technical user.

Replay files should be fully self-contained. So that they can always be accessible. And remain preserved.

4

Having to put the client fully along in the replay will increase replay file size by A LOT

Replay files are already huge right now (200mb for like 2 hours) and the client itself is pretty hefty (164mb compressed as of writing this)

We already had to recently wipe a bunch of old replays (that were unplayable anyway due to engine security issues and dotnet upgrade breaking them) due to storage size limitations on our servers. (we had chosen not to pay for more storage) (afaik these are backed up by someone)

In theory though, with the way robust toolbox bundles work… this is possible if you look into it. But im my opinion its not worth the effort when its far easier to just compile from our github, which will have multiple copies even if our download servers die (and more secure as discussed by the game engine security upgrades (we backport critical security features, which in the past used to break old replays (this is now fixed)) actually thats stupid of me to say its not secure

5

I understand that embedding the entire client within replay files would significantly increase their size, potentially leading to storage challenges. However, the current method, requiring users to compile from GitHub or ensure version compatibility, can be cumbersome and may deter less tech-savvy players from engaging with replays.

A potential compromise could involve creating a lightweight, standalone replay viewer. This tool would be optimized for replay playback, removing the need to package the full client with each replay while still allowing users to view replays offline without extensive technical steps.

Implementing such a solution would enhance accessibility and preserve the integrity of replays, ensuring they remain a valuable resource for the community.

This standalone replay viewer would download the engine, and remain modular. If a player wants to share a replay, they can “export” it, which includes all the engine files.

The server does not need to retain this extended-size engine, rather, the client can merge all the necessary files into the replay archive itself.

However, there is another potential solution as well:

Rather than rely on a standalone client, it could be possible to store one copy of the engine files on the replay server (or another source that already exists)

When a user clicks to download a file, they can be given two options, an offline or online copy. (Or just default to offline)

The offline copy will create a temporarily stored file in a temp directory and merge it with the engine. After the download, the merged temporary replay file is deleted.

The user receives a self-contained copy, unless they opt for an online copy, which does not merge engine files.

6

I’m sorry, but I believe this message looks AI generated. But I will respond to it.

I agree this is possible, like I explained. The content bundle system which replays use. In theory (i have not tested this) can have their client files added onto by an external program. However, I do not believe it’s worth officially making it.

This issue in my opinion is pretty low priority, especially currently where all files required to run replay files can still be served by Wizards den (or well any servers) cdn. Our replays will be able to be played back for a while. And with some newer fixes to the replay system. They will now be able to survive dotnet version upgrades and security engine critical upgrades while still being able to be read back.

For security reasons, security checks are made every time you connect to a server or replay. To ensure the current engine you are loading is safe from known vulnabilities and loads a safe version for you automatically if it is. Replays can never be “offline” from the launcher itself. And thus we cant just include the engine itself (being able to pass your own engine may also result in people having an easier time making modified clients. Take this with a grain of salt)

A “lightweight replay client” is not possible. Due to how replays are loaded, they require the exact client to be loaded. Otherwise, they are good as gone as the data will mean jack shit to a modern client, or any reimplementation of the client. And again will require development time we dont have.

A far easier solution here also is to just make a script that automatically gets the correct version from the replay, check out the git hash and build the game for the user if user accesibility is the issue. We don’t need to overcomplicate the replay system.

7

To be sure this word is getting across.

This IS possible. But It’s not currently worth the effort officially imo. It could be an interesting project for someone though to tackle. Maybe if someone makes a pr it can be put into the launcher. No promises

8

Just confirming here: this is the core issue.

I want to make the launcher able to work offline even if just to make sure the game qualifies as a LAN party game, but we cannot compromise security for it. SS14 is a very unique game that in many ways makes this harder.

If we crack the above issue, the replay issue would be solveable as well.