Automatic archiving of replays

[Jools]

I just wanted to discuss the new policy of automatically putting the replays in a .gz archive. To me it seems that it breaks the replays.springrts.com site, as the upload script can't process packaged stuff. Is this possible to (easily) fix?

Does the packaging also save that much space or what is the benefit?

For users it also adds an extra step before you can watch the replay.

[hokomoko]

Yes, it saves a huge amount of space.

For users it also adds an extra step before you can watch the replay.

No it doesn't, you can feed the compressed replay directly to spring.exe

[8611z]

demo files are now compressed with gzip

The data inside replays is compressed with that algo, spring still plays them like before.
No need to unzip files or anything.

In .sdf files is some readable text if opend with texteditor which is sometimes useful. For example zK players can use it to find their elo or so. Chat is more or less readable too, without playing through whole replay. Such things might not work anymore after compression, maybe also scripts like https://springfiles.com/spring/tools/sp ... ats-viewer could break. No idea how many/relevant those are.

I zipped a 2,39 MB replay with gzip ultra setting and it came out to be 0,76 MB
From playerside that does not matter much I think. Maybe matters for server when there is tons of replays.

[abma]

To me it seems that it breaks the replays.springrts.com site, as the upload script can't process packaged stuff. Is this possible to (easily) fix?

currently replays.springrts.com compresses replays on its own to safe disk space. so the fix is trivial, maybe see the https://github.com/dansan/spring-replay-site/issues/91

-> nothing to discuss, someone needs to fix the detection if a replays is already compressd or not

[gajop]

I zipped a 2,39 MB replay with gzip ultra setting and it came out to be 0,76 MB
From playerside that does not matter much I think. Maybe matters for server when there is tons of replays.

It definitely is a good thing for servers, as you can also serve gzipped files which are immediately usable. It probably shouldn't have an .gz extension, but something in the lines of .sdgzf (or .sdg) so programs don't try to extract it and it's easier to associate the extension with the Spring executable.
Also this reminds me to clear me demo folder:

Code: Select all

~/.config/spring % du -h demos 
3.4G    demos

[Jools]

+1 for changing the extension.

What I've done is associated .sdf with spring.exe -- that way I can just double-click to open the replays.

[8611z]

What I've done is associated .sdf with spring.exe -- that way I can just double-click to open the replays.

The problem is multiple spring engine versions. The sdf needs to be opend with correct version.
I used to have links to several spring-versions in startmenu and then I could drag&drop downloaded replays onto correct one. Kinda stupid but did not find better solution.
Other suggestion was to not associate .sdf with spring.exe but with lobby. Because lobby knows where on computer to find the correct engine versions. Lobby can also download things so it download missing map&game. https://github.com/springlobby/springlobby/issues/298

[abma]

imo to much talk, to few contributions. JFDI

[gajop]

changing the extension.

Thanks Abma https://github.com/spring/spring/commit ... b945c75d54