-
-
Notifications
You must be signed in to change notification settings - Fork 521
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Team Arena servercache.dat not compatible between 32- and 64-bit clients #586
Comments
I don't know if it would be possible to support big endian and little endian from the same file. |
I think the sizes of the addresses will be way larger than the file size if it's the wrong endianness but I haven't tried to think it through very much. |
Probably a different format would be better suited for forward-compat conversion I guess. Also if you add more fields to serverInfo_t struct at all that breaks things too. I was okay with 1 time sacrifice of cache in ETe resulting from changing to |
servercache.dat—used for Team Arena server browser—is not compatible between 32- and 64-bit Linux and macOS clients due to "unsigned long scope_id" being 32 or 64 bit. 64-bit Windows uses 32-bit scope_id. So 64-bit Linux/macOS and 64-bit Windows are also incompatible. The file is also not compatible between big and little endian systems. The client ignores the incompatible file; it doesn't load cache and favorite servers.
Ideally the file would be compatible for rare cases of using the same homepath with different arch or OS. However for the case of upgrading an 64-bit Linux/macOS client, changing
unsigned long scope_id
touint32_t scope_id
will fail to load the existing server cache / favorites.The servercache.dat contains the address count and size in bytes so it would be possible to support loading 32- and 64-bit scope_id. (It may also be nice to support no IPv6 scope_id like in the original game. Though someone would need to check for other differences.)
Serializing the file as little endian for compatibility on big and little endian would be nice but I'm not sure it's worth the effort to supporting loading big endian format.
Issues pointed out by @ensiform (etfdevs/ETe@ec99193).
The text was updated successfully, but these errors were encountered: