non MP-safe WML

[gfgtdf]

AFAIK, as long as you're using one of the events listed as "syncronized" you do not need to manually request synchronization with wesnoth.sync_choice. This is based on my experience coding the dialogs in SoW, where I have both lua dialogs and wml dialogs ([message] dialogs with options such as your example above, just called from lua). I only ever needed the manual synchronization for the pure lua dialogs.
So, message with options was safe already when the lua interface didn't exist yet. (How should a pure wml author use sync_choide anyway, that code above looks ugly).

This sounds like you can use mp sync in "non synconized" events by "requesting it manually". This is not the case, using wesnoth.sync_choice (or [message]/option)in the "non syncornized" events (like attack in 1.10) is most likeley a guaranteed OOS in 1.10.
In 1.11.15+ the code will notice that we are in an unsynconized event, and just ignore the wesnoth.sync_choice in this case and call the function normally.

There had been a bug regarding side_for but it has been fixed. (side_for is incompatible with [option], in 1.10 or 1.12 at least).

i think we could bring side_for for [options]/Text_input back in 1.14. shouldn't be that hard.

[Anonymissimus]

AFAIK, as long as you're using one of the events listed as "syncronized" you do not need to manually request synchronization with wesnoth.sync_choice. This is based on my experience coding the dialogs in SoW, where I have both lua dialogs and wml dialogs ([message] dialogs with options such as your example above, just called from lua). I only ever needed the manual synchronization for the pure lua dialogs.
So, message with options was safe already when the lua interface didn't exist yet. (How should a pure wml author use sync_choide anyway, that code above looks ugly).

This sounds like you can use mp sync in "non synconized" events by "requesting it manually". This is not the case, using wesnoth.sync_choice (or [message]/option)in the "non syncornized" events (like attack in 1.10) is most likeley a guaranteed OOS in 1.10.
In 1.11.15+ the code will notice that we are in an unsynconized event, and just ignore the wesnoth.sync_choice in this case and call the function normally.

Hm, I thought that "synchronized" events just use the same code wesnoth.sync_choice calls ? Anyway, I said it rather because even if the event is synchronized, I still need to use synch_choice if I call a pure lua dialog with input out of that event. And I can't tell about the non-synchronized events as I avoid them in fear of hard to fix OOS.

myav:
I want to put emphasis on some bits of iceiceice's excellent post above:

a) step through the program very slowly one step at a time on both clients. Watch carefully to be sure that everything looks as it should!
b) use the gamestate inspector (:inspect command) to observe if variables are different.

When I took over SoW it was full of OOS and I got it stable with these two; you really can't say it's a simple MP addon or anything.
However, if your addons contain 10k+ lines of wml or something then I can imagine it's a nightmare to maintain. (Code should be more efficient than that.) Such amounts of code tend to be created by copying code which is always a very bad thing to do.

[tekelili]

A side note to Devs: in 1.10 the recall event is not as safe as recruit event. I had to hack completely the AI recalls because try to apply WML that were working for AI recruits directly crashed Wesnoth when used in recall event.

I have unburied an old version of my add on to test this in 1.11.15 and code worked well without cause any crash. Wichever was the issue in recall event, it looks solved now

[gfgtdf]

i think we could bring side_for for [options]/Text_input back in 1.14. shouldn't be that hard.

implemented in http://git.io/A0jiMA.

[iceiceice]

Btw: I want to point out that we currently do test for OOS on all unit tests in the project.

For example, this unit test illustrates how to get a guaranteed OOS using lua math.random, and then how to fix it using synchronize_choice.
This unit test mechanism runs this test to ensure that it is properly detecting broken replays, and that the example is fixed with this fix.

https://github.com/wesnoth/wesnoth/blob ... random.cfg

If there is code which you are concerned about causing OOS, you can submit similar unit tests and we may commit them to the repository. The project is automatically and continually tested to ensure that the unit tests are working.

What this means is that all of the code in the unit tests is more or less guaranteed not to cause broken replays, at least on the development version.

See more here:

http://forums.wesnoth.org/viewtopic.php?f=8&t=40449

[myav]

myav:
I want to put emphasis on some bits of iceiceice's excellent post above:

a) step through the program very slowly one step at a time on both clients. Watch carefully to be sure that everything looks as it should!
b) use the gamestate inspector (:inspect command) to observe if variables are different.

I repeat again, these methods not works.

I never receive OOS when connect to multiplayer server from 2 local clients (even, when one client have scenario and second - not have, in this situation I not receive OOS too) and inspect always show 1:1 results in both clients.

But I always receive OOS when play with other people.

[iceiceice]

myav:

What *exact* version of wesnoth are you using? (What is the third number in 1.10.x ?)

[Anonymissimus]

Well, you are wrong, the methods are known to work, and many MP addons prove it.

I never receive OOS when connect to multiplayer server from 2 local clients (even, when one client have scenario and second - not have, in this situation I not receive OOS too) and inspect always show 1:1 results in both clients.

But I always receive OOS when play with other people.

If this is actually true, then your addon must be OOS free and the reason has to be something else. For instance, are you playing with a small number of other people, and those people have modified their wesnoth installation ? Then those OOS are their fault.
Or - this seems much more likely to me actually - do you have modified your wesnoth installation somehow, perhaps accidentally ? If anything about the core unit files is modified for instance, it will cause OOS.
A deinstallation and reinstallation of wesnoth will reset the core files. Actually, I suggest you do this anyway, just in case, as it's easy, and then check again for OOS with other people. Make sure that you save a copy of wesnoth's userdata directory somewhere, in case it gets lost in the process.
Did you use a second wesnoth installation when doing the check with only 1 client having the addon ? (It's possible to do this with only one install, via the --config-dir switch, which sets the userdata directory to use).

Just to make this clear, the usual way to check for OOS is: You open up wesnoth twice, start a local server instance ("host networked game") via the starting screen menu with one of these wesnoth instances, and connect to this local server with the other wesnoth instance, and then play with yourself thoroughly through the complete scenario until any OOS error message appears.
The same thing can be done with an official MP server, but it is less conveniant, and means the same, as far as OOS is concerned.

EDIT:
Another idea: Once you get OOS when playing with someone else, you could beg this person to save his/her game, and send this save to you. You also make a save, and then compare the two. Something must be different, that's the OOS.
I'm sure there are programs which allow quick line-by-line comparison of text files.

[myav]

iceiceice, I using 1.10.7 for windows, downloaded from wesnoth.org.

Anonymissimus, my game core not modified, and all addons are in the "userdata". And about other people... Too big amount of people have played with me (more than 300 people for all time). It is impossible that absolutely all they have modified their game and as result - OOS. I think that reason of OOS is other.

P.S.: developer "AI" already have tried to help me. At the beginning he found some bad things in my code and I removed them. But OOS didn't stop to appear in the final version of my code where he didn't see mistakes which can start OOS any more.

I still hope that I will find the developer with even more deeper knowledge how to fight against unknown OOS and he will help me...

[iceiceice]

Anonymissimus, my game core not modified

Hmm well just to be safe you might want to reinstall anyways.

(Aside: Maybe we should have a feature that hashes the contents of your core data directory, and compares this with expected value when you log onto the mp server, otherwise it's hard to detect stuff like this ... )

[myav]

Hmm well just to be safe you might want to reinstall anyways.

This was done many times Today - too ))

I'm not lazy and very wanna to find this silly reason of OOS which boring me all this time ((

All methods was tried by me.. Inspect; division of a code into parts; playing from 2 clients; reinstalling game; asking other people to send me their replays. And nothing..

My last hope - the help from the advanced developer, which can check code as made developer "AI" and would try to help.

[iceiceice]

And nothing..

This part I don't understand.

You say you tested many times, what was the outcome? You step through the program, at some point the OOS is observed, where? Is it that the outcome is inconsistent?

You remove pieces until it is smaller, and the OOS goes away eventually? the OOS never goes away?

What are the results of the tests? I don't understand how the result can be "nothing."

Edit: So the problem is that you cannot reproduce locally? A strange issue but still I think you should be able to debug using a different computer, or use a virtual machine.

I have *never* seen an OOS which is caused by a cross platform issue, so I'm somewhat skeptical. It might actually be a file system issue or something? You might want to check that all of the file names used in your add-on are legal.

[Anonymissimus]

asking other people to send me their replays.

Unless I'm completely mistaken, the file sent to you (a savefile, ideally, not a replay) should be bit-by-bit identical to your version (provided the clients use the same wesnoth version), unless there's OOS, because that's what OOS is about. (There are programs for comparing files bit-by-bit; comparing line by line makes much more sense for wesnoth savefile though.) A savegame is the image of the current gamestate of the client it was made on. If they are identical, you shouldn't get OOS. So you must be able to find something, if you don't, search better.