Wesnoth 1.10.7
Moderator: Forum Moderators
Re: Wesnoth 1.10.7
So.. I start to become mad .
1. Used ONLY safe events:
3. Never used side.controller
4. And always OOS...
I'm crazy ((
So... In which else situations OOS can appear? (after my 1.+2.+3.)
Who can help me to find this bad thing which boring me whole year? (yes, these oos have started 1 year ago and I still not find reason, because all people always said only about usual OOS (random or non-synched events or messages with choice not in players turn or controller in the mp and e.t.c.) and nobody not help with unusual OOS... Please help to find it...
1. Used ONLY safe events:
2. Used ONLY safe rand.iceiceice wrote:http://wiki.wesnoth.org/Eventwml#Multiplayer_safetymyav wrote: When it was? And can you link on changes which OOS was fixed ?
3. Never used side.controller
4. And always OOS...
I'm crazy ((
So... In which else situations OOS can appear? (after my 1.+2.+3.)
Who can help me to find this bad thing which boring me whole year? (yes, these oos have started 1 year ago and I still not find reason, because all people always said only about usual OOS (random or non-synched events or messages with choice not in players turn or controller in the mp and e.t.c.) and nobody not help with unusual OOS... Please help to find it...
Re: Wesnoth 1.10.7
That's true, it's not a magic bullet, but it's rather like a seat belt. myav has an enormous project with bugs which no one has any idea how to fix. (s)he is now apparently stuck and has no recourse but to beg for help on the forums -- the normal methods "remove code and test again" don't work (s)he tells us, it's too hard or too complicated to remove code. The project is now very old, who knows how it was assembled / how to disassemble it? No one has a good answer, hence the year of awkward silence.zookeeper wrote: To be fair, version control isn't a magic bullet when you got a situation like described, where a bug only manifests occasionally.
But with version control, it's trivial to remove code and get back to a smaller working state, which was previously tested!
This "stuck" situation where you have no idea how to proceed with debugging is exactly prevented by version control.
Besides this, the situation with OOS is actually a perfectly useful case for version control, at least in my experience. Usually with OOS, it's not like, your scenario goes OOS only 1/1000 of the time, and you can't realistically detect it by testing. Rather it's more like, maybe it goes OOS half the time, or even 1/6 of the time, so it won't always happen but it can happen. (Another strategy is to seed the rng with the bad value, and then test multiple versions with that seed.)
With repeated testing you still make rapid progress on isolating the bug -- as soon as you see failure you know that version is dirty. So you just keep updating your hypothesis as you move down the chain, testing while reading the diffs.
Edit: Besides this, with version control you can use binary search as you go through the tree searching for the source of the bug -- if you don't have version control, each "hunk" of code that you remove represents a huge amount of work on your part. So on a large project, version control will make isolating the bug several orders of magnitude faster. Even if the faults are probabilistic, noisy binary search is still vastly faster than incrementally removing bits of code.
I'm not saying it's easy but it's vastly easier than the no version control strategy... at least there is some process you can realistically follow to eventually succeed.
If you don't have version control, and you have a bug way down deep in the roots of your program, you may end up essentially reconstructing a history of the program, by trying to repeatedly remove code to get to smaller working states. It makes debugging in some cases almost as hard as writing the program in the first place.
I'm merely stating the obvious. It's intended to be helpful.pyrophorus wrote: I strongly second this.
There's no reason to tell myav (s)he has "a flawed software development methodology".
This is the kind of thing a programmer normally does only once in their life. It's important to understand that in this situation, you cannot "blame the language" or blame wesnoth itself.
If you write a program which you intend to maintain, but you discover that it's unmaintainable, then it means that you made a mistake, plain and simple.
Re: Wesnoth 1.10.7
Most likely there will be no mysync fixes for 1.10 anymore.
It's recommended to checkout 1.11.15 dev version and check whether these bugs are still existent there.
It's recommended to checkout 1.11.15 dev version and check whether these bugs are still existent there.
Scenario with Robots SP scenario (1.11/1.12), allows you to build your units with components, PYR No preperation turn 1.12 mp-mod that allows you to select your units immideately after the game begins.
- pyrophorus
- Posts: 533
- Joined: December 1st, 2010, 12:54 pm
Re: Wesnoth 1.10.7
The problem is you behave like those level 1 hotliners who systematically consider customers are all some kind of nannies knowing not how to plug their computer into the wall socket. As them, you deliver your little manual, even if it has nothing to do with the problem. The method you describe in so much details is functionally the same as "remove code and test", and the use of a version control system makes only it easier.iceiceice wrote: I'm merely stating the obvious. It's intended to be helpful.
But, as our friend says, this method works not (with or without VCS). This because this kind of bug (coming from synchronisation between independent processes) cannot be found reliably in that way.
In other words, myav is a noob who needs to be taught about the very basics, or worse, someone stupid enough to repeat the same error. Do you think very friendly and helpful to convey such an opinion ?iceiceice wrote: This is the kind of thing a programmer normally does only once in their life. It's important to understand that in this situation, you cannot "blame the language" or blame wesnoth itself.
Yes but using a VCS is not enough. A noodle pack under a VCS is still an unmaintainable noodle pack. Maintainability has much more to do with good program design than using sophisticated tools. Most often, those only incite intellectual lazyness.iceiceice wrote: If you write a program which you intend to maintain, but you discover that it's unmaintainable, then it means that you made a mistake, plain and simple.
Friendly,
HowTos: WML filtering, WML variables
Re: Wesnoth 1.10.7
pyrophorus wrote:The problem is you behave like those level 1 hotliners who systematically consider customers are all some kind of nannies knowing not how to plug their computer into the wall socket.
Yes, iceiceice's tone was not ideal, but he later indicated he was trying to be helpful to a user who had already said that Wesnoth showed a low level of programming and demanded iceiceice's attention be focused on fixing his issue.pyrophorus wrote:In other words, myav is a noob who needs to be taught about the very basics, or worse, someone stupid enough to repeat the same error. Do you think very friendly and helpful to convey such an opinion ?
Your comments are focused insults, and so think about your next posts.
Mainline Maintainer: AOI, DM, NR, TB and THoT.
UMC Maintainer: Forward They Cried, A Few Logs, A Few More Logs, Start of the War, and Battle Against Time
UMC Maintainer: Forward They Cried, A Few Logs, A Few More Logs, Start of the War, and Battle Against Time