MegaGlest Forum
MegaGlest => Bug reports => Closed bug reports => Topic started by: tomreyn on 22 June 2013, 21:10:49
-
The Desert4 tileset was recently moved from OS user specific UserData_Root to the global storage location. However, doing this seems to change the checksum (why?), and the old checksum was not removed.
We were able to verify this as follows:
Yesterday when I started MegaGlest, the Desert4 tileset I had in UserData_Root was automatically renamed to desert4_custom.
Test 1:
I was hosting a game with Desert4 set, Titi and two of his sons were connected to my server. The server reported that Titi's tileset did not match, however, for his two sons, there was no such message (i.e. same tileset as the server). Titi then cleared out his checksum cache, restarted MegaGlest and reconnected to the server, but the message was repeated - according to the server he still had a different tileset. He restarted MG and connected to the server again with the same effect.
Titi said he did not modify his copy of the tileset. We checked the XML files' MD5 and they matched between Titi's computer and the server.
Test 2:
So this time I deleted my checksum cache, restarted MG and hosted the same game again, and all the players from the last game connected to my server again. This time, Titi's two sons' clients reported a tileset mismatch on Desert4, while none was reported for Titi.
So it would seem that checksums need to be recalculated when a mod (or maybe just a tileset?) is moved from system user to global system scope.
-
In general we have trouble with the checksums very often when playing. Do we really need the CRC-cache and if yes, can we revalidate/clear it each time we get a possible conflict ?
-
Svn now forces the host to refresh its CRC if any client has a mismatched CRC.
-
it must not be done now, but is there a way to make the client calculates his checksum again too?
-
Clients recalc after downloading something new. Otherwise updates are done rnadomly every x days or weeks.
-
Solely based on logic (not testing, since it's not clear how to create a proper test case) the solution announced in https://forum.megaglest.org/index.php?topic=9130.msg88083#msg88083 should fix the originally discussed issue. [Fixed].