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.
Automatic archiving of replays
Moderator: Moderators
Re: Automatic archiving of replays
Yes, it saves a huge amount of space.
No it doesn't, you can feed the compressed replay directly to spring.exeFor users it also adds an extra step before you can watch the replay.
Re: Automatic archiving of replays
The data inside replays is compressed with that algo, spring still plays them like before.changelog wrote:demo files are now compressed with gzip
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.
Re: Automatic archiving of replays
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/91To 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?
-> nothing to discuss, someone needs to fix the detection if a replays is already compressd or not
Re: Automatic archiving 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.8611z wrote: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.
Also this reminds me to clear me demo folder:
Code: Select all
~/.config/spring % du -h demos
3.4G demos
Re: Automatic archiving of replays
+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.
What I've done is associated .sdf with spring.exe -- that way I can just double-click to open the replays.
Re: Automatic archiving of replays
The problem is multiple spring engine versions. The sdf needs to be opend with correct version.Jools wrote:What I've done is associated .sdf with spring.exe -- that way I can just double-click to open the replays.
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
Re: Automatic archiving of replays
imo to much talk, to few contributions. JFDI
Re: Automatic archiving of replays
Thanks Abma https://github.com/spring/spring/commit ... b945c75d54Jools wrote:changing the extension.