Random effects during battle aren't so random

[crypt47]

Preliminary checks

• [X] I've checked that there aren't other open issues on the same topic.
• [X] I've checked that this issue is reproducible on the latest snapshot build.

Platform

Other

Describe the bug

The automatic battle outcome is clearly reproducable, so are the random Luck (Rainbow) effects. The problem is shifting units or playing different combination of turns breaks random completely. One time you get Rainbows every turn, other time not even one. This way the automatic battle with not so optimal moves may be more preferable then played by the user. Something is clearly off here, but I don't know what exactly. In attached savefile ask Tsabu to attack Zam. In case of autobattle you've got almost 4 Rainbows in a row and will end the battle with lost of 11 druids, 2 fenix and 4 unicorns.

Then try this battle to be played by yourself and see no Rainbows and much more loses.

Save file

Pyramid_0023a.sav.zip

Additional info

No response

[oleg-derevenetz]

So what's the bug?

This way the automatic battle with not so optimal moves may be more preferable then played by the user.

So what? It's kind of "unfair"? :) Random events are not designed to be "fair" in this sense.

[crypt47]

I understand Random to be defined like here https://en.wikipedia.org/wiki/Random_number_generation (cannot be reasonably predicted). Maybe the game uses some other definition of Random that is beneficial for the AI, I don't know.=) I came actually to ask, because it annoys to guess which behavior is more favorable (mine of AI) instead of relying on random and play. I kinda strange that there is a reproducible pattern of moves that triggers 'random' events in predictable order.

[oleg-derevenetz]

I understand Random to be defined like here https://en.wikipedia.org/wiki/Random_number_generation (cannot be reasonably predicted).

Are you able to predict random events depending on in-battle actions (except that the same chains of actions produce the same chain of random events, this is by design)? In other words, can you intentionally trigger the chain of random events you need? If not, there is no problem here.

I kinda strange that there is a reproducible pattern of moves that triggers 'random' events in predictable order.

This is by design and this happens in the original game (and in other games of HoMM series, e.g. HoMM3 and HoMM5).

[crypt47]

No, but

except that the same chains of actions produce the same chain of random events, this is by design

I kinda don't understand the reasons after that design :-\ It's not like in Homm3 for example. In the end I can predict, that autobattle is in some cases better for bad reasons.

[oleg-derevenetz]

It's not like in Homm3 for example.

It's exactly like in HoMM3 and original HoMM2. By performing exactly the same chain of actions, you will get the same chain of random events.

[crypt47]

Well, I should have put this in to Questions. I agree:(

[crypt47]

It's exactly like in HoMM3 and original HoMM2.

If it doesn't bother anyone except for me, then it's ok.:-\

[oleg-derevenetz]

If it doesn't bother anyone except for me, then it's ok.:-\

For example, there are instant battles in HoMM3 HotA (actually, the idea of instant battles in fheroes2 was taken from there). The chain of random events during the instant battle absolutely coincides with the chain of random events during the auto combat (i.e. if you start the manual battle and then immediately press the "auto" button) and with the chain of random events that will occur if you manually repeat the actions of the auto combat exactly. You will always get absolutely the same results by performing absolutely the same moves. This applies not only to luck and morale, but also, for example, damage, which is also random.

[crypt47]

if you manually repeat the actions of the auto combat exactly

in the given savegame, 1st move: fenix up, then 2nd druid gets rainbow only in autobattle, not if I repeat this steps manually.

btw, in the original game there is some way to interrupt autobattle by clicking on the same auto button, though now warning or window appear. this method is unclear to me.

[oleg-derevenetz]

in the given savegame, 1st move: fenix up, then 2nd druid gets rainbow only in autobattle, not if I repeat this steps manually.

I cannot reproduce this on the master branch (i.e. our latest snapshot). Here is the auto battle on my machine:

https://github.com/ihhub/fheroes2/assets/32623900/afc72112-a054-40f1-a137-e489ee0a5144

and here is the manual battle that I reproduced by watching the video above and reproducing the same actions manually:

https://github.com/ihhub/fheroes2/assets/32623900/978ebea4-39d1-4fa8-80f7-2a21e76cf37c

(resolution of the second video is reduced to fit into the GitHub 10MB limit). As you can see, all the random events in the second video happen in the same order, including luck events, triggering of Medusa's Petrification ability, etc. I don't see any differences.

btw, in the original game there is some way to interrupt autobattle by clicking on the same auto button, though now warning or window appear. this method is unclear to me.

You still can interrupt the auto battle by clicking on the same auto button. But since the action of the auto battle stops only after the end of your unit's turn, some users click on this button many times (apparently this is happening to you as well) and thus turn the auto battle back on. There is the dialog window added to prevent such an accidental event.

[crypt47]

It plays differently on 1.0.9. Druids got Rainbow, then Archers, then Trolls too. Tree Rainbows in a row and Bone Dragons are crashed! That's why it looks so strange. (The Fast spell goes to vamps.)

apparently this is happening to you as well

Yeh, that's what I always do: click wildly while it stops:) Would be happy to have some pop up there some day.:)

[oleg-derevenetz]

It plays differently on 1.0.9. Druids got Rainbow, then Archers, then Trolls too.

The way it plays depends on the fheroes2 version (because AI can perform different actions in different versions since AI decision making algorithms change over time) and on the OS/compiler (because random generator implementations are compiler-dependent). But it should always play the same battle on the same fheroes2 build (built from the same set of sources using the same compiler) in the same way, and in this case you should always get the same chain of random events if exactly the same moves are performed (doesn't matter whether they are performed by a human or AI). In the video above I performed absolutely the same moves manually and got absolutely the same chain of random events.

Yeh, that's what I always do: click wildly while it stops:) Would be happy to have some pop up there some day.:)

You already have such a pop-up. This pop-up doesn't allow to accidentally turn the auto battle back on when you want to turn it off. In this video I'm clicking many times on the "AUTO" button:

https://github.com/ihhub/fheroes2/assets/32623900/c22a9181-dba2-45c5-a20d-92a69de5bd6c

All you need is to press the "No" button in this pop-up.

[zenseii]

Hi, @oleg-derevenetz and @crypt47. For visually indicating to the user perhaps it's enough to just lock the AUTO button into a pressed state when enabled, and pressing it will disable it and make it released?

Not sure how intuitive it is to click on a pressed state button though. It's certainly not done elsewhere in the game.

[oleg-derevenetz]

@zenseii auto battle is not the global state, but the per-player state (because it can be turned on in PvP battles if either player wants to let the AI to play instead of him), so mostly the confusion is because auto battle can be turned off only during the turn of a player who turned it on - for example, it cannot be turned off during the AI turn.

[zenseii]

I see, @oleg-derevenetz. I was under the impression that right now, if you press the A key or the AUTO button during the AI turn it would still activate or deactivate once your next creature's turn comes. But I just checked with the button and what you are describing is actually the case.

[crypt47]

You already have such a pop-up. This pop-up doesn't allow to accidentally turn the auto battle back on when you want to turn it off. In this video I'm clicking many times on the "AUTO" button:

All you need is to press the "No" button in this pop-up.

Well, I'm an ordinary user and that's not obvious. What I like though (found just now), that when I press ESC it clearly asks me if I want to abort the automode now. That's fine. I like it.

[crypt47]

if exactly the same moves are performed (doesn't matter whether they are performed by a human or AI)

If it's still relevant for 1.0.9, I'll make a video to show you that it apparently doesn't do so on my build. The Rainbows appear in auto, but it doesn't produce the effect the very next turn if manually interrupted.

[oleg-derevenetz]

If it's still relevant for 1.0.9, I'll make a video to show you that it apparently doesn't do so on my build. The Rainbows appear in auto, but it doesn't produce the effect the very next turn if manually interrupted.

On 1.0.9 there were issues with this, that were fixed by #7967 about two weeks ago. These issues were expressed in the fact that instant battle and auto battle were 100% repeatable (i.e. instant battle and auto battle always performed absolutely the same events and brought absolutely the same results), but if a human player tried to do the same things, the chain of random events was not 100% the same as in case of instant/auto battle. These issues should be no longer relevant for the latest snapshot.

But I should note once again that actions should be absolutely the same to get the same chain of events. For instance, if you cast the spell on the wide unit, the spell should be casted on absolutely the same cell of this unit (if you or AI cast this spell on the head cell during the first try and on the tail cell during the second try, the subsequent chain of random events will be different).

[crypt47]

On 1.0.9 there were issues with this

Ok. If anything comes up in the next release I'll come back.

p.s.

Also didn't have a chance to say thanks for fixing resolution in 1.0.3. Now scales conveniently alright.