This may be related to #2501, however I think the issue only manifests if said Client hasn't joined a Server using the now-updated map for quite some time (Needs confirmation). If an affected Client manually subscribes to the Workshop addon the map is contained in, the issue goes away and they are able to successfully join. This happens despite whether the map is included in the Server's addon collection ( +host_workshop_collection) and/or included for download ( resource.AddWorkshop()). I am still thinking about making a front-end for people to look for and download deleted Addons.Clients who join a Server using a map contained in a workshop addon that they are not subscribed to sometimes fails with the kick reason Your map differ's from the server's if they had a previous playing session using the same map, but the map (And therefore the workshop addon containing it) have been updated since, but retain the same map name.
Im storing metadata about every Addon+Version in a MongoDB(yeah its not the best, but i needed a fast migration to dump json from steamwebapi into). (just cat input.gma | lzma -d - > output.gma) The Images are just stored once, they have the same schema but without the Timestamp.some of the Addon Files(especially the older ones) are GMAD archives, BUT!! theyre layered with LZMA compression.
Im working on a GMAD-Parser (special addon archive file) to generate a fileindex+sha256 hashes for every Addon, to look for dupes.(prob a lot of repacked addons) but its going to take some more time.įile Structure is: (AddonID for example is 1337420) 1/3/420.gma/bin I finally got the initial download of 16TB(207,7K Addons) done(took a few weeks) and now the continuous download and indexing of the workshop is working without supervision.
0 kommentar(er)
