[Issue Report]: Incorrect hero alignment with petrified monsters

[Chance4us]

Operating System

Linux x64

DevilutionX version

Custom build (commit 181247924b6ffe4d25b6988f3b1c0e4965399247)

Describe

While playing the hero very often does not face the monster in battle. In 1.4.0 it looks normal and needs to be narrowed down further.

To Reproduce

1. Load attached game. stone.zip
2. Only play with Stone curse and pay close attention to whether the hero is looking towards the monster when hitting.
3. Unfortunately, it doesn't always happen and it's not easy to determine whether the issue is occurring. If necessary, play longer to determine the issue by continuing to play
4. You should notice from time to time that the alignment is not correct.

Expected Behavior

The hero should always look in the direction of the monster when hitting

Additional context

In 1.5.3 things already look bad in this regard

[julealgon]

Interesting that this would only happen with stone cursed monsters... apparently, the monster was moving while he got petrified, and for whatever reason his position was set to the target tile, which is what the hero is targeting?

[Chance4us]

Yes, just as you describe it seems to be. This also seems to be related to timing and is not easy to isolate the issue. It will take time.

[kphoenix137]

Is it possible to walk into the tile that you seemingly attempt to attack? I'd be curious to see the dMonster display in debug.

[kphoenix137]

I'm under the impression it's intentional that the player attacks facing the tile that the monster is walking into. Consider this:

If the player was attacking the originally occupied tile of the monster, the player would begin pathfinding to the side of the monster in an attempt to reach the tile they're exiting. Normally you wouldn't notice this behavior of targeting the tile they are entering, but it becomes much more apparent then you stone curse a monster that's in the beginning stage of moving into the next tile.

Initiating an attack also takes a few frames (depending on character class), so targeting the tile a monster is exiting can be quite detrimental in cases where your attack animation takes too long and you're swinging at the air.

I think changing this behavior would not be ideal. The tile occupation system just results in a very strange feeling system and was quickly left in future ARPG games. I believe the only true fix to this would be handling stone curse the same way that animation changes are handled, which is snapping the entity to the tile grid. I'm not entirely sure this is a good idea though, as it both doesn't look very good, and it ends up resetting the monster's walk progress and allows them to immediately choose a different behavior, when normally they would resume the walk animation.

Thoughts? @AJenbo @StephenCWills

Edit: I think I may be completely wrong about this. I remembered that you can target and attack things that are moving away from you as well without trying to pathfind to the tile they're entering. I'll dig into the code some more.

Edit: It appears that the player is completely unwilling to begin swinging at the tile a monster is exiting, specifically in the current master. When tile occupation was fixed, I don't recall ever making changes to targeting behavior, but I'd assume that this means certain directions were bugged with targeting, since it wasn't always the case that the original tile had the positive monster index and the tile being moved into had the negative monster index. Seems like we need a bugfix.

[kphoenix137]

So it is by design that the player pathfinds to the tile the monster is moving into, and faces that tile when starting an attack. Although the game technically does allow you to hit a target successfully by attacking the tile they're moving out of.

We could introduce logic that forces the player to conditionally target a tile based on walk progress, rather than consistently always the future tile. It may result in some cases where the player swings at nothing, but still might be worth it, as there could be many cases where the player can successfully hit the target instead of beginning a pursuit.

[StephenCWills]

We could introduce logic that forces the player to conditionally target a tile based on walk progress, rather than consistently always the future tile. It may result in some cases where the player swings at nothing, but still might be worth it, as there could be many cases where the player can successfully hit the target instead of beginning a pursuit.

A more intelligent pathing for melee attacks could fix one of your bigger gripes about Hellfire, I guess. Ranged attacks should probably continue to target the future tile.

[kphoenix137]

We could introduce logic that forces the player to conditionally target a tile based on walk progress, rather than consistently always the future tile. It may result in some cases where the player swings at nothing, but still might be worth it, as there could be many cases where the player can successfully hit the target instead of beginning a pursuit.

A more intelligent pathing for melee attacks could fix one of your bigger gripes about Hellfire, I guess. Ranged attacks should probably continue to target the future tile.

Working on this right now. Should also fix the weird facing direction with stone curse as well.

[julealgon]

Slightly related to this:

• https://github.com/diasurgical/devilutionX/issues/801

SHIFT-Attacking doesn't track the monster and thus performs an attack against the current tile instead of future tile.

@kphoenix137 I suspect your proposed change will align the behaviors unexpectedly, but maybe in a worse way (read on).

I'll be honest here... I've always preferred the tracking behavior. It is super noticeable when you are fighting a pack of fallen around you: if you try to kill them with SHIFT-Attack (non-tracking), it results in much worse hit chance than doing normal (tracking) attacks.

IIRC the only difference between the 2 is that shift+attack does not pass the monsterID while normal attack does.

I had proposed before that SHIFT+Attacking should also be tracking if you do so on top of a monster.

[kphoenix137]

Should we close this? The game is working as intended and this isn't a bug.

[StephenCWills]

Yes, I think so.

[Chance4us]

I'm glad it's not a bug, even if it's hard to believe. :yum:

[StephenCWills]

I'm glad it's not a bug, even if it's hard to believe. 😋

You said it looks correct in 1.4.0, but it appears to work the same way to me. I actually have a hard time believing anything has changed with regard to attacking future tiles.

[julealgon]

@Chance4us are you consistently using normal attack or shift+attack in your tests? Keep in mind it makes a difference (check my linked issue for more details on that).

[kphoenix137]

I'm glad it's not a bug, even if it's hard to believe. 😋

Basically, when a monster is walking, it is occupying 2 tiles at the same time. in the dMonster array, the positive monster index indicates it's the tile they're originating from, and the negative monster index indicates it's the tile they're moving into. Targeting always takes into account the future tile always to avoid "whiffing" as julealgon put it.

Using this knowledge, in the circumstance that a monster just began moving into another tile and is stone cursed, it will look like you are facing the wrong direction. if you stone curse the monster when it's over halfway into the destination tile, then it will look correct. If we changed it to use the original tile to target, that means when you stone curse a monster near the beginning of the walk animation, it will look correct, and when it's over halfway, it will look incorrect.

The PR that I opened made it so the targeted tile for an attack would choose whichever tile the monster is most inside, however this can create a scenario where a slower attacking character (even a warrior without a speed boost) may end up swinging at a monster that's fleeing and ending up with a 0% chance to hit. A potential alternative to having to do a bunch of special handling for this would be simply changing the facing direction to the tile the monster is most inside, however that's not entirely ideal either, because your attack is targeting a tile you're no longer facing. Applied to bows, this would result in arrows visually shooting in the wrong direction.

The problem is that the game uses such a big tile system and only has 8 facing directions. If it was more like d2, or hit detection didn't use a tile grid at all, then this wouldn't be an issue.

[julealgon]

The problem is that the game uses such a big tile system

And that alone also doesn't necessarily solve all the issues. D2's range detection is quite bad, as it tends to consider the very tip of your maximum range to decide it is time to swing. This means if a monster is moving away from you, even if very slowly, you have a very strong tendency of missing every single hit while trying to hit it from behind.

D2 also had a huge problem with stuff like dual wielding when using weapons with 2 different ranges because it wasn't smart enough to handle the situation when one of your weapons was in reach but not the other, leading to buggy double swing/frenzy. They eventually fixed that one though, but the first problem still exists to this day (unless they've done something about it in D2R which I'm not sure of).