2020-06-03 15:46 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0006286Spring engineGeneralpublic2019-08-31 11:00
Assigned ToKloot 
Product Version104.0 +git 
Target VersionFixed in Version104.0 +git 
Summary0006286: joined battle room, game is downloaded from rapid but user remains unsynced
DescriptionI started this as a pr-downloader issue, more information here:

The core of the issue seems to be inconsistencies in the checksums on ArchiveCache15.lua for files on the rapid pool.

Sometimes the checksums are != 0 (does this have any special meaning?) but the one from the game sdz (http://repos.springrts.com/metalfactions/builds/) differs from the one you get if you download the same game version using the rapid pool.

There are also examples of two different game versions downloaded from the rapid pool which got the same checksum on archivecache15. That can't be correct.

I've marked this as urgent because it breaks the core "join room, download, play" service and won't even allow the user to become synced by manually placing the sdz file after it has been downloaded through rapid pool

(unless the user manually removes the archivecache and the whole pool and restarts the lobby, but it's unreasonable to expect anyone to do that)

Additional InformationNot sure if this is relevant, but the checksum shown in the archivecache file doesn't match the one shown on the infolog when playing the game, regardless of whether it came from the pool or sdz.
TagsNo tags attached.
Checked infolog.txt for ErrorsIrrelevant
Attached Files




abma (administrator)

does it work with the latest version of spring?

(maintenance or develop)


abma (administrator)


should have fixed the problem.


raaar (reporter)

MF doesn't work with develop build, only maintenance.

I've set one of my spads hosts to use engine "104.0.1-1378-g00fda18_maintenance" and MF 1.141.

after joining the host I was prompted to download the engine and did it, then....it remained unsynced.

i removed archivecache15.lua on the spads server but after reappearing there it changed to "00000..." and then to the same checksum

                        name = "metalfactions-v1.141.sdz",
                        path = "/spring/spring/games/",
                        checksum = "21ec0030391c545d53d53ce0c8fb40719d8632c3190cd531e5a8bf5977d66f27fe0e2e64339a8b7a80718941cb312e71964759c6745f389f384f4dc4d3cebccb",

my desktop's archivecache15.lua still showed this

            name = "22aa514dcf310f131f312b8718dc7e31.sdp",
            path = [[C:\Users\Rui\Documents\My Games\Spring\packages\]],
            modified = "1565474752",
            checksum = "9010c21ad37acd0c9608ac82fdaabfd035ed7341f783250dcd938edd5383547dd355b3325b27326960fe6593a38f38a071bd478b273c65a690f98ce753c839fc",
                name = "Metal Factions v1.141",

after removing the file and restarting SL, it shows "0000000000..."

after playing a game on it, it shows

            name = "22aa514dcf310f131f312b8718dc7e31.sdp",
            path = [[C:\Users\Rui\Documents\My Games\Spring\packages\]],
            modified = "1565474752",
            checksum = "21ec0030391c545d53d53ce0c8fb40719d8632c3190cd531e5a8bf5977d66f27fe0e2e64339a8b7a80718941cb312e71964759c6745f389f384f4dc4d3cebccb",
                name = "Metal Factions v1.141",

and it matches the spads host's archivecache, and i'm now synced on the spads room.

So in a way it seems to have fixed it, but I had to manually remove archivecache15 on my springlobby pc to achieve that.


raaar (reporter)

note that the infolog.txt still shows different checksums than the archivecaches

[f=-000001] [Game::ClientReadNet][LOGMSG] sender="Player" string="[PreGame::GameDataReceived][mod-checksums]


raaar (reporter)

unfortunately the latest builds have this other issue :/

-Issue History
Date Modified Username Field Change
2019-08-27 20:46 raaar New Issue
2019-08-30 01:00 abma Status new => feedback
2019-08-30 01:00 abma Note Added: 0020094
2019-08-30 01:01 abma Note Added: 0020095
2019-08-31 01:49 raaar Note Added: 0020097
2019-08-31 01:49 raaar Status feedback => new
2019-08-31 01:51 raaar Note Added: 0020098
2019-08-31 02:44 raaar Note Added: 0020099
2019-08-31 11:00 Kloot Assigned To => Kloot
2019-08-31 11:00 Kloot Status new => resolved
2019-08-31 11:00 Kloot Resolution open => fixed
2019-08-31 11:00 Kloot Fixed in Version => 104.0 +git
+Issue History