Questions about replays, random seed, recruit and unit checksum

[demario]

I am trying to load some 1.12 replays in wesnoth 1.14.14.
It raises a couple of OOS that I have trouble to understand. Maybe someone is knowledgeable to help?

First question: how many random calls to recruit a unit?
In BFW1.12, it seems all "drake faction" units are recruited with 14 calls to random.
In BFW1.14, saurians are still recruited with 14 seeds but drakes are taking 22 seeds.
I look at changes in Glider/Clasher cfg, the difference is new alternative portraits but they seem not related to the number of call to randomness (if removed, still 22). I think the unit facing on recruit may be random in BFW 1.14 but when that call is removed from src/units/unit.cpp, the number of calls is still 22 (saurians have new mirror portraits too anyway).

Second question: does the existence of OOS impact the recruited unit during the replay?
In seems that in BFW1.14 an OOS in replay will lead to all recruited units to have "intelligent, resilient" traits if checksum OOS is raised. They all then have the same checksum which is the one reported in the OOS, which may show that the traits may not originate from OOS (hence the following question).

Third question: is is there any incompatibility in random seed (new_seed in replays) between the two versions?
A replay from BFW1.12 is giving seed as integer while the seed for BFW1.14 is a string. Yes, generated by different algorithms.

Fourth question: are random choices made in music, map scenery, alternative portraits used in help/dialog... impacting the random seed before first recruit?
I guess it should not, as the result of these random choices are not part of the replay data.

[demario]

Third question: is is there any incompatibility in random seed (new_seed in replays) between the two versions?
A replay from BFW1.12 is giving seed as integer while the seed for BFW1.14 is a string.

So it seems that the incompatibility must be broken down in two parts:
- integer vs string format: BFW 1.14 is still using integer to initialize the random pool and the "string" is just the hexadecimal encoding of that integer.
- if integer seeds from BFW 1.12 replays are encoded in hexadecimal format, there is still OOSes. Beside the seed value, the algorithm using that seed may be incompatible. If different algorithms are provided the same seed, they will generate different numbers.

It seems there are at least three "incompatible" random algorithms:
- BFW 1.14 (mt_rng, based on boost random?)
- BFW 1.12 (random_new, based on standard C rand()?)
- BFW 1.10 and earlier (simple_rng, based on specific generator)

It appears that both BFW 1.14 and BFW 1.12 are using different seeds through the game. The seeds are stored in replay (the drawn number are not).
But BFW 1.10 and BFW 1.8 are using one single seed for the whole game, replays stores the drawn numbers but actual values are replaced by values from replay if not matching ("no check" draws), which means no OOS.

So it seems unlikely to be able to replay an old save using the current random generator and we should use the RNG matching with version of the replay. So ...

Fifth question: what would be a possible design to embed the different RNG in the current code and select one based on replay version?

[gnombat]

It seems a lot simpler just to keep an old version of the game installed to view old replays...

[Soliton]

You're focusing a lot on random number generation as the source of OOS but surely there are countless other reasons. There is generally no effort spent to keep compatibility between different stable versions.

[demario]

You're focusing a lot on random number generation as the source of OOS but surely there are countless other reasons.

I will clarify the limits of my endeavor: I am not interested in recovering local campaign replays to keep playing in the next version.
I am only interested in multiplayer game replays. By multiplayer, I don't consider loading the replay on the server which is excluding OOS from networking. I mean the passive replay we are viewing from "Load game" dialog on the main screen.

I only plan to load existing replays which is basically limit the scope to:
- stable versions of wesnoth (with minor version as even number)
- openly available 1v1 replays (which mainly begun at version BFW 1.4 for ladder game and BFW 1.6 for non-ladder)
I also don't consider user add-ons to focus on default scenarios (which I expect to be maintained and updated to newest version).

With these limitations, I believe if the replays can be loaded and recruits got right properties (MP, HP, XP, damage, def/resists, ...), the only cause of OOS left is numbers from RNG to be wrong. But I am probably wrong myself as I might find out in a near future.

[Soliton]

There is not much difference between network OOS and replay OOS. Multiplayer pretty much consists of sending ReplayWML around.

Simple properties are not everything. Every action needs to work as in the version the replay is from. Occasionally how stuff works is changed and that is not necessarily just contained in WML/lua. How random numbers are used is one thing you already noticed.

To give an ancient example: Drain used to be able to "heal" units above max HP. A replay played with that logic will unlikely work now. A little more recently drain was changed to only drain as much as the victim had HP left. (It always drained half damage regardless before.) Same outcome, old replays will unlikely work anymore since the amount of HP drained does not match. (They might if there are no draining units in the replay or the amount of drained HP never made a significant difference in the game...)

Same thing for trait changes etc etc.

[demario]

To give an ancient example: Drain used to be able to "heal" units above max HP. A replay played with that logic will unlikely work now. A little more recently drain was changed to only drain as much as the victim had HP left. (It always drained half damage regardless before.) Same outcome, old replays will unlikely work anymore since the amount of HP drained does not match. (They might if there are no draining units in the replay or the amount of drained HP never made a significant difference in the game...)

Thanks for the details, I was not aware how the drains logic was changed in the past.
Still it might not changed the technique to reach the goal. It is clear that old replays can't be used in new version using the current stats of the units.
It stands for simple changes as damage, MP, number of traits, ... It can only be run using the stats at the time of the replay.
That is where targeting only stable version replay works best because no change in stats for any minor version update.
For example, the orcish archer had his ranged attack changed in version 1.10 (bow boosted at 6-3), so if I want to use a 1.8 replay, I need to use the previous stats:

Code: Select all

#textdomain wesnoth-units
[unit_type]
    id=Orcish Archer-1.8
    name="Orcish Archer-1.8"
    [base_unit]
        id=Orcish Archer-1.10
    [/base_unit]

    advances_to=Orcish Crossbowman-1.8

    hide_help=yes
    do_not_list=yes

    [attack]
        name=dagger
        description=_"dagger"
        icon=attacks/dagger-orcish.png
        type=blade
        range=melee
        damage=3
        number=2
    [/attack]
    [attack]
        name=bow
        description=_"bow"
        icon=attacks/bow-orcish.png
        type=pierce
        range=ranged
        damage=5
        number=3
    [/attack]
[/unit_type]

I believe the example of drains change could be handled the same (id=drains-1.x). Of course, more complex the change, harder is the code to write.
And the new code may break the unit checksum

[demario]

Occasionally how stuff works is changed and that is not necessarily just contained in WML/lua.

I see what you mean now. If I look at the code of the healthy trait, there is no parameter that gives any details on its behavior

Code: Select all

#define TRAIT_HEALTHY
    # Units with trait Healthy get 1 more HP plus 1 per level and always rest heal.
    [trait]
        id=healthy
        description= _ "Always rest heals"
        [effect]
            apply_to="healthy"
        [/effect]
    [/trait]
#enddef

It looks just like a marker that is caught in the code to trigger some behavior (+2HP each turn, -2 damage from poison).
If we want another behavior (BFW1.4 healthy is +2HP if no fight last turn and no effect on poison), we need to either change the code in a compatible way or implement the feature fully in WML. For the example of healthy trait, it seems that WML could be doing the job, lucky enough.