Wesnoth 1.11.0

[JaMiT]

OK, looks like some key information was missing from the initial report. Specifically regarding:

Point is, the sequence may be random, but it is a set sequence for that scenario.

This implies that to see the bug, a scenario must be played multiple times. Now I have not made anything close to a comprehensive survey of user-made campaigns, but going by mainline campaigns, I only recall two instances (off the top of my head -- I might have forgotten some) where repeating a scenario does not mean repeating a campaign. So I'm thinking it really should have been mentioned that this bug only occurs when a campaign repeats a scenario. Otherwise the natural assumption is that one repeats the campaign to repeat the scenario.
(Reminder to everyone that omitting key pieces of information in a bug report risks the report being tossed out as unreproducible. Also don't assume an issue is known unless you can find a bug report for it.)

There are other factors involved too, but those are more subtle. Anyway, I do have a way to get the behavior you are looking for, but it's more of a band-aid than a fix at this point.

[doofus-01]

Reminder to everyone that omitting key pieces of information in a bug report risks the report being tossed out as unreproducible. Also don't assume an issue is known unless you can find a bug report for it.)

I posted a test case and tried to explain it as well as I could, I'm sorry it was not up to your standards.

[JaMiT]

I posted a test case and tried to explain it as well as I could,

In this post, yes, but the post I quoted (with the general reminder to everyone, not just you) was this one. If not for the post with the test case and better explanation, I still would not know how you produced the bug.

[Max]

here's a similar report:
http://forums.wesnoth.org/viewtopic.php ... 93#p540247

looks like weird bug - the part that generates random numbers hasn't been changed for ages and it's pretty guaranteed that srand will be called...

[Anonymissimus]

the part that generates random numbers hasn't been changed for ages

Not quite true. See r52822 and also http://gna.org/bugs/index.php?18996 ; perhaps it interferes. It was only applied to trunk.

[JaMiT]

here's a similar report:
http://forums.wesnoth.org/viewtopic.php ... 93#p540247

Similar in that it also involves the random number generator, but there are some key differences. One that sticks out is that that report describes the consistency as "more than half the time", while the report by doofus-01 states "always [...] the same". OK, technically "always the same" is something that occurs more than half the time, but somehow I doubt that is what your reporter was thinking.

Another key difference is that that report is for version 1.10.3, not 1.11.0....
(Not that 1.10 bugs are invalid, but they are a bit off-topic here.)


Anyway, the doofus bug is fixed in trunk, so will be fixed in 1.11.1. In fact, I think fixing this bug made the codebase a (tiny) bit more robust and less prone to future bugs, so it was a useful report.

[doofus-01]

This may be a dead issue, but just in case it matters to 1.10.x users:

Another key difference is that that report is for version 1.10.3, not 1.11.0....
(Not that 1.10 bugs are invalid, but they are a bit off-topic here.)

I wasn't sure if it really was a 1.11.0 issue, I only know it happened after 1.10.0 and stable releases should not have big changes, such as things touching the RNG (hence my hesitant first post). Based on some reports on the forum, it is possible 1.10.3 has the same issue. If it is only a 1.11.x thing, and JaMiT has fixed it, then never mind. But if 1.10.x is the public face of Wesnoth for the next two years, and this is really present in 1.10.3, then that could be a problem.

My point is: I'm not really sure this is a 1.11.0 problem and not a 1.10.x problem. All I know is 1.10.0 did not have this issue, and I did not see anything in the 1.10.x change-log that would hint where things could have changed (but I'm not a good judge of that).

[Coffee]

This RNG bug for multiplayer or campaigns has been around for a while. What I've done is "seed" the RNG with the the total cost of all the leaders combined to randomize it in my MP Campaign (The Great Quest). To me this is an easy way to make sure it is more random and you don't get only 3 or so different random sequences because the leaders are chosen at random and the next event that gets a different sequence comes only after the first turn is finished (in my testing from 1.8 -- 1.11.0+SVN).

[lipk]

This RNG bug for multiplayer or campaigns has been around for a while. What I've done is "seed" the RNG with the the total cost of all the leaders combined to randomize it in my MP Campaign (The Great Quest). To me this is an easy way to make sure it is more random and you don't get only 3 or so different random sequences because the leaders are chosen at random and the next event that gets a different sequence comes only after the first turn is finished (in my testing from 1.8 -- 1.11.0+SVN).

Did you use rand in a prestart event? I recently wrote a little mp scenario and noticed that random doesn't work well in prestart, but is fine in start events.

[JaMiT]

This RNG bug for multiplayer or campaigns has been around for a while.

Which RNG bug for multiplayer or campaigns? Obviously not the bug reported by doofus-01, as that bug did not exist in 1.10. Possibly the one linked to by Max, but that report was too vague to make sense of for someone who does not have Wesband downloaded (and it looks like Wesband is going to work around that bug instead of reporting it). Is the RNG bug you are referring to documented anywhere? If it is not reported -- preferably reported properly -- it probably will never get fixed. (Case in point -- once doofus-01 made a nice report here, that bug got fixed. It helped that the bug reporter had already narrowed things down to a small test campaign with little WML beyond what was needed to reproduce the problem.)

Again, a bug that is known to exist in 1.10 is off-topic for discussion of 1.11.0, as it was not created by 1.11.0. There is a nice forum for reporting bugs and a lovely little bug tracker that are more suitable for reporting bugs, particularly when the bug exists in more than one version. Please make use of these -- they are where I turn when I feel like finding something different to work on. The forum is particularly good if you are trying to narrow down the cause or scope of the bug, as the forum reaches more people who could help with that.

[Scatha]

Rather late, but I wondered why this didn't make it into the players' changelog?

Implemented feature request for difficulty changing during campaigns.
(see bug #10978)

This can actually have a serious impact on the way people engage with the game. There are campaigns I'm considering going back to with this feature that I'd been frustrated with before. I think it could do with further advertisement (there is an argument to wait until the interface is better, but at least a mention in the players' changelog is pretty small).

[Kurt_Aust]

The random number generator bug described by doofus-01 appears to remain in Wesnoth 1.11.1

I was starting a campaign (Legend of the Invincibles) and accidentally recruited the wrong unit, no big deal, I simply reloaded the start-of-turn save and recruited the correct unit.

That's when I noticed that the units I recruited had the exact same traits as the previous lot, in this case:
Int, Str
Str, Res
Qui, Res
Res, Str
If I reloaded the autosave I would always get the same traits (in the order listed above) on the units I recruited regardless of unit type recruited (only humans were available in this case).

If I started the campaign again a different sequence would result, but once again if I reloaded the autosave I'd always get that new sequence.

[Dugi]

Not sure if it belongs here, but that behaviour is related to random seeds - there seem to be two random seeds, one is saved in saves, that affects randomised things that are created by scenario designers, and another one that is related to the generic random seed, like the value in the saved random seed at the beginning of a campaign, or the hit/miss result. Traits are obviously using the first kind of random seed.