I have a theory about map sync errors

[Forboding Angel]

Ok, as many of you devs prolly know, I use the userfolder for mods/maps/whatever, but as most of us have seen siratturi has been running into sync troubles and it was discovered that paths seemed to play a role in the problems.

I noticed something last night... for some reason spring had created a maps/paths folder in my spring dir. It didn't have much in it, but it's still kind of disturbing. I think that possibly people are having trouble because of old paths that persist because of paths in the spring dir AND the user dir.

At any rate, it would be worth having the installer delete the paths folder in the spring home maps dir.

[Beherith]

For me there never was a paths dir in my user folder, only in spring_install/maps/paths. Its the singular one.

[Auswaschbar]

Old paths are old paths, regardless of where you place them. The only thing that matters is the filename (with the checksum).

[Tobi]

First note there are two numbers involved:

• Path hash: this is the number in the filename. It is independent on the actual path data, but depends on map name, heightmap, movetypes, movedata, etc.
• Pathing data checksum: this is what is printed in the infolog. This is the CRC32 of the path info file that is inside the path zip file.

With these definitions present, the only ways the pathing data checksum can be different are, as far as I can see:

• Path hash collision -> wrong path info is used, with different pathing data checksum (it's a very whacky hash, and has to include a lot of things, so it isn't entirely unreasonable that this collides, possibly simply because it fails to take a certain input into account.)
• Somehow under certain conditions the path estimators aren't entirely deterministic (i.e. bug), and write out slightly different paths (with different pathing data checksum) for the same input.

[Auswaschbar]

• Path hash collision -> wrong path info is used, with different pathing data checksum (it's a very whacky hash, and has to include a lot of things, so it isn't entirely unreasonable that this collides, possibly simply because it fails to take a certain input into account.)

This is known to have happened before, see http://springrts.com/mantis/view.php?id=1507