Tasclient + SpringLobby archivechecksum vs mapchecksum

[Licho]

Atm lobby system uses mapchecksum/modchecksum when it advertises battles.

Because even mapchecksums depend on springcontent.sdz (which is changed often), spring releases often result in completely different hashes for every map and mod.

This breaks lots of things - tasclient genrates new minimaps, downloader cannot download any file etc..

Could we switch to archivehash instead for mods and maps (this does not depend on dependencies).

At least for "broadcasted" battle info messages.

When you join game, real mod hash/map hash could be used to test sync with dependencies included.

[AF]

+1, if you can get aegis on board then your halfway there

[Licho]

We dont need aegis, its semantics change .. no need to change protocol?

[bibim]

We dont need aegis, its semantics change .. no need to change protocol?

I don't think this would work with current server. If you open a battle with mapHash1, then send mapHash2 to server, then the server will broadcast mapHash2 to all players, even those who are out of the battle lobby.

[Licho]

for now we would have to do with just 1 hash - archive hash

[bibim]

That would mean that sync problems due to springcontent.sdz for instance wouldn't be detected before game launch :/

[Licho]

Yes but thats non issue.
Tasclient checks for correct spring version. So only people who manually modified springcontent would "fail" after starting without desync indication.

Not a huge issue imo.

[AF]

Agreed, I think we should switch as soon as possible.

[bibim]

What about mods and missing otacontent ? This happens quite a lot...

Actually, even springcontent.sdz is quite often mis-generated on Linux systems (bug in base file generator script that doesnt remove files from sdz files, it only adds new files). It's quite handy to be able to detect it from lobby.

[AF]

Aside from fixing the problem with the generator script, perhaps the script can be modified to check the files hash against a hash maintained by buildbot?

As I said aegis could sort this all out by forcing through the change and providing protocol ammendments to solve these issues.

[Tobi]

Just change the script to delete the .sdz files before updating them.

(And maybe add dev mode which doesn't do it, because it's a lot slower when compiling and it gets done everytime.)

[bibim]

What about mods and missing otacontent ? This happens quite a lot...

If you broadcast archive-hash instead of mod-hash, then missing otacontent wouldn't be detected in lobby anymore. And this happens much more than invalid springcontent.sdz...

[AF]

Shouldnt games needing otacontent have it in their modinfo.tdf/archiveinfo.tdf anyway? At which point it becomes an issue of unitsync not displaying errors for missing dependency, or not telling the lobby about it.

[imbaczek]

that information was (is) contained in the checksum.

[Licho]

All people who started springdownloader (default on windows) have otacontent..
It auto downloads it without asking..
Thats like 80+% of users..

[imbaczek]

I'm not sure we can afford to piss off the other 20%, of which most is likely to be new players.

[Licho]

we piss 100% if downloader system is broken, which is when you do it current way!!

[Licho]

Can you please do this for next release? Springdownloader has to follow what lobbies do..
Just use archive checksum..instead of mod/map checksum..

[Tobi]

This is lobby only issue right? I checked and unitsync has three functions which each do pretty much what they are supposed to do:

• GetArchiveChecksum returns the archive checksum (not XORed with anything, just the special fast-CRC based on filenames and CRCs in archive zip/7z header)
• GetModChecksum returns cehcksum of mod including all dependencies, to be used for sync checking in battle.
• GetMapChecksum does same but for map.

If it's really problematic however to get lobbies to switch at exactly same moment I suppose we could rename GetModChecksum and GetMapChecksum in unitsync to GetModFullChecksum and GetMapFullChecksum, and then make new methods with same interface as GetModChecksum and GetMapChecksum which internally just call GetArchiveChecksum.

In other words; I think lobbies need to use GetModChecksum/GetMapChecksum for sync checking, and GetArchiveChecksum on first archive of mod/map for SpringDownloader.

[Licho]

Yes thats the way it is, they also need to use archive checksum for hash advertised with battle on the tas server (which is the one used by downloader).

Since there is only support for one hash atm in tasserver protocol, mod/maphash check for syncing will be disabled anyway until we switch to new lobby server.

Thats why I think quickly fixing (renaming) functions in unitsync would be easiest solution atm.