Save randomizer seed in save file?

[Anthony]

Prevents reloading to get a new and better summon hero or research outcome, as well as a few other retry methods, at least one turn in advance. If you can force the randomizer to be called a different number of times, you can still change results, but that's more work (MOO2 does this). It's likely that the game is calling the system clock or something to seed its randomizer.

[kyrub]

-it is now impossible to get better hero by reloading before a summon
-it is now impossibe to get better reward from lair by reloading before the battle

[Anthony]

Above statements are not true. Perhaps you intended them to be true, but they aren't.

[Jtm]

Above statements are not true. Perhaps you intended them to be true, but they aren't.

This savegame proves the intended mechanism does not work for heroes as stated. Press Next Turn to finish Summon Hero spell then reload. It is still possible to get better hero by reloading.

[kyrub]

Funny, nobody never averted me.
(This feature actually works until people realise it does not, hehe).

Jtm, thanks for the saves. Nice to see you back.

[Asfex]

(This feature actually works until people realise it does not, hehe).

No. I always think it would not work. This is a reason i cut this feature from all my mods.

The only way i see to do it: this is described in the 'homeless ideas...' thread. About artifacts only.

[Anthony]

There are several ways of doing this, but they all depend on assembler level coding. For lairs, there's sufficient space in bytes 0x12-0x17 to store book/retort data, book/retort data 2, hero code for prisoner, and three item numbers -- none of those values require more than one byte. Any hero set to a prisoner should be marked as unavailable for hiring/summoning, which will require adjusting how the hero status bytes are interpreted. For summons, if there's code that's fired when a spell is started, the bytes used to store the item being created (for Enchant Item/Create Artifact) can be used to store the code of the hero being summoned, since by definition you aren't creating an item when you're summoning a hero. This lets you recast the entire spell to get a different hero, but that's a lot more hassle.

[Asfex]

There are several ways of doing this, but they all depend on assembler level coding. For lairs, there's sufficient space in bytes 0x12-0x17 to store book/retort data, book/retort data 2, hero code for prisoner, and three item numbers -- none of those values require more than one byte. Any hero set to a prisoner should be marked as unavailable for hiring/summoning, which will require adjusting how the hero status bytes are interpreted.

Wrong! 1byte is not enough to store items in this node structure. 2.you assume you will free the prisoner? If other wizard will free her? You cannot block hero to hire.
You lost your attempt.

[Anthony]

Wrong! 1byte is not enough to store items in this node structure.

Yes it is, there are only 127 pregen items. It does mean that items in lairs need to be marked so they won't be randomly offered. Alternately, you can just store a seed randomizer, meaning what you get out of a lair will vary based on what other heroes and items have previously been offered in the game, meaning you can slightly adjust lair rewards by altering the order you crack them, but again, that's more trouble than it's worth.

2.you assume you will free the prisoner? If other wizard will free her? You cannot block hero to hire.

Legitimate point but not impossible to handle. If another wizard frees, mark the hero as available for hire.

None of this stuff would be at all difficult if we had sources; it's just that poking around in uncommented assembler code is annoying and risky.

[FrancoK]

you can just store a seed randomizer, meaning what you get out of a lair will vary based on what other heroes and items have previously been offered in the game,

This one is much better than other options, if it is possible to do.