Skip to content
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

Open
zturtleman opened this issue Feb 7, 2023 · 3 comments

Comments

@zturtleman
Copy link
Member

zturtleman commented Feb 7, 2023

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 to uint32_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).

@ensiform
Copy link

ensiform commented Feb 7, 2023

I don't know if it would be possible to support big endian and little endian from the same file.

@zturtleman
Copy link
Member Author

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.

@ensiform
Copy link

ensiform commented Feb 7, 2023

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 uint32_t because not enough people are really using it yet. And it only affected 64-bit non-Windows clients which only like me and 1 other person were using.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants