When is the gamehash sent to the client?
according to docs, the gamehash is sent to the server when a client opens a battle:
http://springrts.com/dl/LobbyProtocol/P ... TLE:client
but it is never sent back to the client it seems:
http://springrts.com/dl/LobbyProtocol/P ... NED:server
oO
did i miss something?
in lobbyserver its received and stored (hashcode):
https://github.com/spring/uberserver/bl ... l.py#L1640
but only send on JOINBATTLE?
http://springrts.com/dl/LobbyProtocol/P ... TLE:server
hu?
it seems thats the initial implementation of these command(s):
https://github.com/spring/uberserver/bl ... rotocol.py
why do clients receive map hashes for all open battles but not the game hash?
LobbyProtocol: when is gamehash sent to client?
Moderators: Moderators, Lobby Developers
Re: LobbyProtocol: when is gamehash sent to client?
I don't understand your `question`
Never the less, afaik the original implementation only know 1 hash (result of game + map hash) all splittings of those in the lobby protocol were added later.
So all bogus stuff comes from that (instead of cleanly implementing an arbitrary data interface, ppl glued their stuff on it).
Never the less, afaik the original implementation only know 1 hash (result of game + map hash) all splittings of those in the lobby protocol were added later.
So all bogus stuff comes from that (instead of cleanly implementing an arbitrary data interface, ppl glued their stuff on it).
Re: LobbyProtocol: when is gamehash sent to client?
ok, then it makes sense, but it was done in a very bad way.jK wrote:Never the less, afaik the original implementation only know 1 hash (result of game + map hash) all splittings of those in the lobby protocol were added later.
So all bogus stuff comes from that (instead of cleanly implementing an arbitrary data interface, ppl glued their stuff on it).
an arbitrary data interface is still missing
Re: LobbyProtocol: when is gamehash sent to client?
AFAIK, the original hash was the product of the map, game but also the engine. This was designed to prevent desyncs due to wrong engine versions, or something like that.
I think we should prefer separate hashes for each module type that can be stored correctly in third party systems and not require the engine to compute (therefor ideally it would be just md5/sha hashes).
I think we should prefer separate hashes for each module type that can be stored correctly in third party systems and not require the engine to compute (therefor ideally it would be just md5/sha hashes).
Re: LobbyProtocol: when is gamehash sent to client?
not sure if thats the proper name, but the sdp hashes for all required files (=the same hashcode as retrieved from unitsync) should be used, but without any dependant files. games can be distributed via rapid or as zip and the sdp hash can be used to check if file contents are the same.I think we should prefer separate hashes for each module type that can be stored correctly in third party systems and not require the engine to compute (therefor ideally it would be just md5/sha hashes).