Let's fix the linux multiplayer problem! (new workaround!)

[Duke]

True, but at least we can be relatively sure that there is only just this one problem.

[AF]

it's likely to cause more problems than it solves.

Also intentional crashes are bad because there's no way for a user to determine bugs from desyncs, and potential bug reports are lost. It's also unprofessional looking and reflects badly on your coding efforts when the end user experiences it.

For example how is the user to know that there's a horrendous bug introduced in a new version when they go "oh its a damned desync" every single time? Or when every crash is immediately labelled a desync when users ask about it? Indeed the game should not continue without any notice, but a crash is not the only option available nor is it the most appropriate.

[Duke]

Agreed, if it is called release and not beta, it shouldn't crash every 10 minutes.

Its worse if they don't run it in a terminal, because then there is no message at all and the game is simply ... gone 0o.

My prof once said somthing along the line of: "alway catch an exception as early as possible to minimise its consequences".

As titi said if a unit doesn't respond properly it might be a wise idea to stop the current game, but not to crash the entire Programm.

And even then you could give the user a warning and ask him if he wants to try if the game goes on if the unit in question is simply removed.

[KaSek]

Hi.

I think the cause of the problem is the implementation of Glest.

I've ported Glest 3.0 to Mac OS X. As far as I know the multiplayer works if Mac connects to each other.

I found the original code puts C++ object (not data) into data packet (noooo!).
So I had to make another way. And more it ignores not only endian but data alignment. My Mac version resolved these problems and it doesn't depend on specific platform, I think. But it cause a little bit overhead.

Now I'm preparing the source code of Mac version and I'm going to post to my Web site. Please see this one. I will announce when it's available on "Glest 3.0 package on Mac OS X" thread.

[ttsmj]

Today our multiplayer game crashed when playing the same binary!

server: ttsmj, Ubuntu 7.10 32 bit (titi's binary, sourceforge data)
client: justWeedy, sidux 32 bit (titi's binary, sourceforge data)

console message on client was:

Code: [Select]

Exception: Disconnected

if you need some more info, tell me

[titi]

This is a network timeout. This would happen in windows too. The connection was too bad or disconnected!

[martiño]

Glest doesn't make much of an effort to keep connections alive when they die, so if you have a bad connection you will have trouble playing the game. LAN and broadband users should be fine.

[weedkiller]

Hi, i played with him.
Yes looks like it was a ping problem;
the bandwith took under 10 mbits (?), but when i looked after it the game closed as it was no longer in focus.
I assume that since it was not longer the active programm the commands where managed more slowly and then the connection was to slow to continue.

I thinks its quite hard to improve big pings although it felt like the connection was fast enough at the beginnig, i'm not sure if it was only  one moment when the connection got to slow. Is there a possibility that the server finds out if its to slow and waits some time? But how should the client know...

[AF]

If actual C++ objects memory footprints are being copied across network traffic then it appears we have found a huge security flaw. Someone could exploit this to install a worm or trojan or cheat code. Its also a big no no  as said before if there's ever to be communication between glests from different compilers.

[weedkiller]

Hi again,
i played again with ttsmj and everything went fine, so it was really just a bad connection error.
We played against 2 computerAI and there was only little slowdown compared to simgleplayer.
It was really playable.

OK, how much traffic may the AI need? is it like a additional human player or do they need less bandwith/trafficspeed?

[ttsmj]

I am playing games with different binaries trough loopback 127.0.0.1.

binary1: GCC 4.0.3 ---- titi's binary
binary2: GCC 4.1.3 20070929 (prerelease) -- compiled by me

Game starts fine, running, but sooner or later it crash with this message:

Code: [Select]

Exception: Can not find command type with id: 1 in unit: energy_source. Game out of synch
In game/commander.cpp:

Code: [Select]

ct= unit->getType()->findCommandTypeById(networkCommand->getCommandTypeId());

//validate command type
if(ct==NULL){
throw runtime_error("Can not find command type with id: " + intToStr(networkCommand->getCommandTypeId()) + " in unit: " + unit->getType()->getName() + ". Game out of synch");
}



When unit->getType()->findCommandTypeById(1); returns NULL?

[ttsmj]

In types/unit_type.cpp:

Code: [Select]

const CommandType* UnitType::findCommandTypeById(int id) const{
for(int i=0; i<getCommandTypeCount(); ++i){
const CommandType* commandType= getCommandType(i);
if(commandType->getId()==id){
return commandType;
}
}
return NULL;
}