Why Linux and Windows Glesta are not multiplayer compatible?

[sbrbot]

Why Linux and Windows Glest versions are not compatible for multiplayer playing? I'm interested in Linux version of Glest and like it very much on my Linux machine. But it seems that with Linux Glest version I am in minority among Glest players so my question is why Linux and Windows Glest versions are not compatible that I can play over network with Windows Glest mates?

[Geek Squad 2gb]

linux glest is more popular and also runs faster unless you have a Windown Vista it runs pretty fast.

[Geek Squad 2gb]

i have a game started on icechat if any one wana join (windows).

[softcoder]

To answer the original question, I beleive the networkconsistencychecks flag in the glest.ini file may possibly be why? It seems to do a CRC check of various files on all networked pc's and on different OS's (windows. linxu, mac) you would get different CRC values for some files (definately the main binary if it checks that.. i have not looked at that part of the code yet). But setting the consistency checks to 0 in the glest.ini you should be able to connect but you'll likely have other synchronization issues.

Thanks

[titi]

Linux / windows  even different builds of Linux32bit using different compiler versions get out of sync after a while. The developers believe that the reason why this happens are floatingpoint calculations which are handled slightly different in these systems.

To protect users from starting games which will crash, this network consistency check checks the binary too.
And this is the reason why windows/linux is currently not possible.

[bork]

Linux / windows  even different builds of Linux32bit using different compiler versions get out of sync after a while. The developers believe that the reason why this happens are floatingpoint calculations which are handled slightly different in these systems.

How can it be affected by floating point calculations if checksum is calculated using integer arithmetic only? It looks like the only system dependent thing there is using file path and files content for checksum calculating. It might produce different results because of different file path separators and line-endings and it'd be rather trivial to neglect these differences before checksum calculating, I think.

To protect users from starting games which will crash, this network consistency check checks the binary too.
And this is the reason why windows/linux is currently not possible.

Just wondering, how it is possible to visit websites hosted on various OS's from Windows or Linux and not get web-browser crash?  Actually the problem might be in network message sending/receiving code (see glest_game/network/network_message.cpp). All messages do it with

Code: [Select]

NetworkMessage::send(socket, &data, sizeof(data));

where data is instance of internal structure containing all message, well data. The problem is that sizeof(data) might produce different values for different compilers and even for same compiler, but with different settings due to member aligning (not to say it will never work for platorms with different endianess). A correct way of sending data over network (or storing it in file) is sending each field separately. E.g. for NetworkMessageIntro it'd be

Code: [Select]

NetworkMessage::send(socket, &data.messageType, sizeof(data.messageType));
NetworkMessage::send(socket, &data.versionString, sizeof(data.versionString));
NetworkMessage::send(socket, &data.name, sizeof(data.name));
NetworkMessage::send(socket, &data.playerIndex, sizeof(data.playerIndex));
NetworkMessage::send(socket, &data.resumeSaved, sizeof(data.resumeSaved));

This is not 100% correct from C++ standard point of view, since it's UB to treat pointer to non-POD data (here versionString and name) as pointer to char, but it should work on most widely used compilers/platforms, and you can add something like getBuffer method to NetworkString class to avoid possible problems here. Also, it'd be better to use htonX functions or like to convert data to particular endianess before/after sending/receiving.