Post by iceiceice » June 16th, 2014, 2:25 pm

myav wrote: When it was? And can you link on changes which OOS was fixed ?

myav wrote: In the wiki is still not written which random is unsynced and which is synched. So, example: Code: Select all [set_variable] name=random rand=1,1,1,1,2,2,2,3,3,1 [/set_variable] In the wiki iswhich random is unsynced and which is synched. So, example:it is synched or no? If no, how to correct write it without oos?

myav wrote: Can you link on this in the wiki ?

myav wrote: Method of detecting: "remove part of the code and check again" - not works. Because, these OOS errors can to not appear 5 full games and to appear only in the 6th and impossible to find them with such methods.



And this is realy boring when you create heavy scenario with a lot of interesting things and got OOS... I have posted my problems in the forum and nobody can't find reason why OOS appears (even game coders and developers which answered me).

I think that this one is synced, I don't remember for sure, it might have changed. Normally in 1.10 you should not use [set_variable] rand=, because there are known bugs where it is not properly seeded during start and prestart events. There is plenty of example code on the forums and wiki using lua random, with synchronize_choice, which is always safe: http://forum.wesnoth.org/viewtopic.php? ... 06#p517620 ******************Edit: I repost to address something else you said:The problem here is not with wesnoth, rather it is that you are using a flawed software development methodology.If you use version control and you encounter a bug, you can revert to old versions and test them, and determine rigorously exactly which version introduced the bug.If you use version control, you can easily compute the diffs between versions and see exactly what changed to show you exactly what introduced the bug.If you use version control, and you can automate the failing test case, you can tell the compute to automatically identify which revision introduced the bug.If you use version control you never need to "delete half the code" which, as you rightly point out, doesn't work for a large and tightly interconnected piece of software.Testing and version control go hand in hand -- when you use version control and you test a revision, you know for all time which tests passed there, and you can easily get back to the state that you tested.I strongly recommend to use git (or equivalent) for any piece of code of any kind that is larger than your screen. Personally I won't even write a document without using git, if I intend to revise it another day. git is extremely easy to use for every day purposes once you get used to it, and the service it provides is invaluable.If you find yourself with a large software project that is broken and you don't know why, and you didn't use version control, you are just screwed . IMO the only reasonable option at that point is to rewrite the whole thing from scratch, using version control the second time, and using the first version as a template. And testing at each commit until you figure out what caused the bug.The amount of time that you save in the long run every time you fix a bug will always vastly repay the time you spent on version control, if you are using a good system like git.