search

ioquake / ioq3

The ioquake3 community effort to continue supporting/developing id's Quake III Arena
https://www.ioquake3.org/
GNU General Public License v2.0
2.34k stars 522 forks source link

Team Arena servercache.dat not compatible between 32- and 64-bit clients #586

Open zturtleman opened 1 year ago

zturtleman commented 1 year ago

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 (https://github.com/etfdevs/ETe/commit/ec991933bb60edfab6905faed6c8f3adccdbddf4).

ensiform commented 1 year ago

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

zturtleman commented 1 year ago

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 commented 1 year ago

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.