SERIOUS Suggestion - Please Read !!!

[SoofMan]

It's really few lines of code. And it will help to improve playability a lot.

You keep claiming this. So go write them, submit a patch, and commence bugging the devs to commit the patch, rather than bugging them to code the feature.

[/quote]

Well, i surely could, but there are some reasons i can't.

0) I never wrote anything in C
1) It would be very difficult for somebody, who's never programmed any part of OTTD before. It would take me 100 X the time you (or sb else who's a good developer) need to do it. First i need to learn C. And i don't like C. Second i need a lot of time to understand the part of code we are talking about.
1a) I would need to learn and get used to your coding conventions.
2) If i would try to write it now, surely it will have hundereds of bugs providing it will work at all. It's much faster to do it for an experienced developer than for anybody else.
3) I'm out of time - I'm just finishing my studies now (Engineer degree), and writing my engineer's work (or whatever you call lots of pages of paper that you write to finish studies).

You must understand, that i'm trying to convince somebody else to do it, because it's the best i can do as i know that any attempts to fix it myself will fail. So you could say that for now, i'm doing my best to better the game.

I'm sorry if i failed to convince you. Nobody will force you to do it. I simply suggested what would be good for the game. It's nothing more than cost-effective way to improve playability.

[Brianetta]

Obviously, both of these include clearly invalid positions, such a game with no kings on the board, or adjacent squares that have vastly different heights, but I'd say that your "on the order of millions of times more" is pretty safe.

Yeah, I did a back-of-the-envelope order-of-magnitude sanity check before I committed that post. (:

[SoofMan]

Lucky i'm getting less desync errors now. Anyway, even if you won't fix the desyncs, OPEN TTD is still a wonderful game, and i would like to thank all developers for their work.

You simply made almost all possible efforts to improve this game, and now there are so many upgrades, that TTDPatch cannot even be compared to OpenTTD. It's long way behind it's back.

[jez]

I just read this whole thread so I'm responding to a few comments at once. I've been getting so many desyncs (every 5 mins or so) that the multiplayer game's pretty much been unplayable for me also, so it'd ben nice to see this fixed.

Thinking is one thing, trying it in practice is another. I think that MD5 or CRC suming everything can be a way to avoid data corruption. And some kind of data corruption is what causes the desync errors. Logical conclusion.

A desync is a desync. It is the local and server machines getting out of synch. It is not a data corruption, but a lack of synchronised data communication. Corruption would be the server sending 50tonnes, and the client saying "i got 20tonnes". It is more the server sending 50, the client getting nothing, and making up an answer.

Either way, desyncs are a pig. I agree that "something" needs doing - at minimum I think better debug info would be useful; eg. "Desync caused by lack of .grf file xxxx", or "Too many data packets lost.", or "Data difference between client and server maps". The first would certainly stop people attempting to connect a zillion times without checking their .grfs.

(I know this is WIP or at least in the roadmap; it doesnt hurt to say its a *good* idea!)

Is there some way we can see this 'roadmap' or even a 'to do' list? I can't find anything of the sort.

Either way, desyncs are a pig. I agree that "something" needs doing - at minimum I think better debug info would be useful;

What debug info? Only two things can cause a desynch-disconnect:
1) A client sending an invalid command.
2) A client with a random seed that doesn't match the server's seed.
Once either of these things happens, there's basically no way to tell why it happened, unless you have full activity logs[0] dumped by both the client and server from a known accurate state to the disconnect.

Apparently there are a few more things that can cause a desync, because those 2 reasons seem almost guaranteed not to happen if you're using the same client version as is supported by the server. I'd like to see some debug info, giving the reason for the desync. Then at least I could start to diagnose whether there was a specific bug causing the problem, or just a generally messed up connection.

Meush, your assumption that the differences between the initial map and the current map would be smaller than the size of the current map is misguided.

Firstly, everything about a map can change, with the exception of the map's absolute dimensions and (to a certain extent) the names and number of towns, lighthouses and transmitters. Even those *can* change, given the right cirsumstances.

So, other than the length and width of the map, nothing is known about the map, nor can it be inferred from the initial position.

Indeed. It would be helpful if, when connecting to a server, it said something like 'downloading game state data' instead of 'downloading map'. I, too, was fooled into thinking of the map as a static thing until I read this thread and thought about it.

Regarding the protocol incorrectness: the protocol is correct, but because OpenTTD is a stateful game, even the slightest difference can cause a desync. This includes buffer-overflows, amongst others. But totally different things can cause desyncs as well. For example we used the OS-supplied qsort() (quicksort algorithm) to sort the distance to bus/truck-stops. Unfortunately Windows and *nix-en handled the order of the same values differently and games disconnected.

[*]corrupt data is not necessarily corrupt, corrupt but for example a different random seed. It is corrupt with respect to the server.

Right, there are loads of different reasons why a desync might occur. So some basic diagnostic info would be very useful. eg. 'Desync caused by differing client/server values for ship count', or what have you.

It's really few lines of code. And it will help to improve playability a lot.

You keep claiming this. So go write them, submit a patch, and commence bugging the devs to commit the patch, rather than bugging them to code the feature.

Well, i surely could, but there are some reasons i can't.

0) I never wrote anything in C
1) It would be very difficult for somebody, who's never programmed any part of OTTD before. It would take me 100 X the time you (or sb else who's a good developer) need to do it. First i need to learn C. And i don't like C. Second i need a lot of time to understand the part of code we are talking about.
1a) I would need to learn and get used to your coding conventions.
2) If i would try to write it now, surely it will have hundereds of bugs providing it will work at all. It's much faster to do it for an experienced developer than for anybody else.
3) I'm out of time - I'm just finishing my studies now (Engineer degree), and writing my engineer's work (or whatever you call lots of pages of paper that you write to finish studies).

You must understand, that i'm trying to convince somebody else to do it, because it's the best i can do as i know that any attempts to fix it myself will fail. So you could say that for now, i'm doing my best to better the game.

I'm sorry if i failed to convince you. Nobody will force you to do it. I simply suggested what would be good for the game. It's nothing more than cost-effective way to improve playability.

Yet you have time to post on these boards and play lots of OpenTTD.

Oh SoofMan, you remind me of me when I first got onto the internet. Please keep going, you split my sides. Maybe you could go for a career in stand-up!

[Darkvater]

Right, there are loads of different reasons why a desync might occur. So some basic diagnostic info would be very useful. eg. 'Desync caused by differing client/server values for ship count', or what have you.

If that was so simple desyncs would've been solved ages ago .
The problem is that you only know that a desync occured if the random-seeds used by all clients differ. But you have no idea why they differ or how they came to differ.
There is some debug code that prints out every seed so you can try and trace back to the cause but even then it's not simply something you do, or even can find.

All the game can say is 'desync' and nothing else.

[jez]

Oh dear, sounds a shame that it's so hard to debug. So what are we gonna do about these regular desyncs? Is it just gonna be a fact that, for some of us, we'll never be able to play until we get a new computer or something?

[Darkvater]

Did you check for newgrf incompabilities? That is the #1 source of desyncs.