OG bug: alligators can get stuck in an attack animation and deal no damage

[walkawayy]

Alligators can get stuck in their animation of attacking Lara. They look like they are attacking but deal no damage. If Lara moves, they will move and fix themselves. I think this is an OG bug, but I haven't confirmed it yet to add the label.

https://streamable.com/ld1l6d

May be related to #44.

[walkawayy]

If Lara treads water in place, alligators will attack once and then loop animation 2 and roll around at Lara. It never bites or deals damage after the first bite because damage can only be dealt from animation 1.

Three possible solutions I propose:

1. Make the alligator's goal animation to swim after a bite. It will bite, deal damage, then swim through Lara and turn around to attack Lara again. This seems like the behavior Core intended, but there was an oversight if Lara doesn't move so it tries to attack again.
   https://streamable.com/ne3l89

2. Make the alligator attack try to immediately attack again. The possible issue with this is, the animation 1 bite animation normally connects from the alligator swimming. So the alligator moves forward slightly when it bites. This means it sometimes can get two bites in before it has moved forward enough where it's not touching Lara anymore. Or it can miss the second bite which looks janky. Then it starts to swim and turns around and attacks again.

3. Make the damage be dealt during animation 2. This could change gameplay because the damage could be dodged differently if Lara moves away between the original bite and the new damage frame. At the beginning of the clip, the alligator attacks at just the right distance, so it will start swimming after the bite because of some forward movement and it no longer touches Lara. But for most cases, it continues the attack during its jaw lock animation.
   https://streamable.com/3rgkrw

[rr-]

I like the third approach where he bits and doesn't let go, but the crocodile… is flashing as if he was taking damage in a Mario game? :D

The first approach is good too. Thanks for going the extra mile to record these videos.

[walkawayy]

Np. I think the flashing might have to do with the new renderer? In the original issue post using TombATI, it doesn't flash when we were using TombATI. Seems like the animation moves the croc up enough that the game thinks it's out of the water for a few frames so it loses the underwater coloring. The issue happens without my changes.

[walkawayy]

WadTool calls the animal Crocodile (on land) and Crocodile (in water). How was the alligator name chosen? Just wondering if it's worth possibly renaming to like Land_Crocodile and Water_Crocodile or something.

[rr-]

That's what Core Design chose to call it. I don't think it's an issue

…

On Wed, Dec 08, 2021 at 01:09:49PM -0800, walkawayy wrote: WadTool calls the animal Crocodile (on land) and Crocodile (in water). How was the alligator name chosen? Just wondering if it's worth possibly renaming to like Land_Crocodile and Water_Crocodile or something. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. *

[Richard-L]

I honestly would not change this as the solutions seem too fiddly and introduce new undesirable behaviour, like the first bite being missed, or the second bite coming too late. Yes it's a bit odd when alligators get stuck and don't do further damage, but people aren't going to float on water waiting for this to happen.

[walkawayy]

The first bite can miss in the vanilla game too. And the fix would be optional in the JSON though I'm not sure why you'd want broken AI. Option 1 is still on the table I guess where the alligator does one bite then swims away and comes back around. But it makes the alligators much less aggressive.

Maybe I need to look into how they act in TR4.

[rr-]

Hmm @Richard-L can you show an example when this would be an issue? @walkawayy 's solution seemed to be quite resilient on his video. Or have you tested it and confirmed that it's not really as consistent as we'd like it to?

[walkawayy]

I can't record video in the compatibility mode, but the water crocs attack is "fixed" in TR4.. They deal damage in the bite animation then do the roll animation like in TR1. But, now they will go back to the bite + roll animations properly instead of only rolling and dealing no damage. However, the bite animation still has that forward movement, so if Lara doesn't move, it will eventually move too far forward through Lara after a bite and will have to swim away and turn to try and attack again. So based on this, maybe we should just go for the option 1 fix in the issue, where it does one bite then swims away to try and attack again. They also possibly added a bigger touch_bits range in TR4 because it can get in a third attack in a row rarely. Though the croc's body is embedded in Lara and the mouth is way too far forward to look like it should attack again.

I don't think we can make the alligator go back to their bite since the roll animation state in the level file doesn't connect properly to the bite in the level file. In TR4, the roll connects to the attack ending animation, which connects back to swim, which connects back to bite, etc. Maybe we could hack it to connect? I know the shotgun animation is hard coded frame by frame. Other option is inject into the level file and patch it to connect to the right animation, but idk how practical that is.

[rr-]

I'd say frame hacks and content injection are too much for this issue.

I still am not sure why solution 3 is not practical – can the croc still get stuck?
Also can the croc grab and not let go of Lara in normal OG?

[walkawayy]

I'd say frame hacks and content injection are too much for this issue.

I still am not sure why solution 3 is not practical – can the croc still get stuck? Also can the croc grab and not let go of Lara in normal OG?

Ok I'll try to do a full overview. For reference, the croc and alligator were combined together in TR4, so I kind of throw the name around interchangeably.

The alligator (water croc) has 4 animations (also true for TR4 except it has additional animations because it can transition from land->water and water->land):

• 0: Swim
  

• 1: Bite (slight forward movement+damage)
  

• 2. Attack (in place "roll" with no damage)
  

• 3. Attack to Swim (slight forward movement)
  

• 4. Death
  

In TR1 when Lara sits still in the water, the alligator swims to Lara, bites, and gets stuck looping animation 2. And since the damage frame is in animation 1, it deals no damage.

The fix I currently implemented moves the damage frame from animation 1 to 2. That way, when the alligator continuously does it's animation 2 in place, it deals damage because it looks like it has Lara gripped. We don't know the devs original intention since it's not properly implemented. Here's the WAD Tool screenshot showing that animation 2's next animation is 2 hence why it gets stuck.

After looking at the behavior in TR4 however, it seems the devs fixed the bug by making animation 2 connect to animation 3. This works because the croc will go back to the swim animation and can bite again. Here's the WAD Tool screenshot of the TR4 croc showing that animation 2's next animation is changed to 3 (the animation numbers are different because the water and land croc are combined into one enemy type since it can transition between land and water).

In both TR1 and TR4, animations 1 and 3 have some slight forward movement to them. So, if Lara stays still, the Croc eventually will move forward through her body enough to no longer be able to attack.

Relating this back to my proposed solutions:
In solution 1, the croc does one full attack animation then continues to swim. Damage is dealt in animation 1 like the OG game and TR4. This is more similar to the TR4 behavior, however, there is no potential to perform multiple bites in a row.

In solution 3, the croc deals damage in animation 2. Because that animation loops in TR1, the croc stays in place and can continuously attack if Lara stays still.

[Richard-L]

I'm in favour of suggestion No1.

Currently this is what happens:

2021-12-12_22-49-31.mp4

Apparently the first bite missing can happen in vanilla too? If we only look at what happens after, I think the damage suddenly occuring much later in the animation than what you're generally used to feels unnatural. Also the croc being stuck and taking damage without opening its mouth anymore also looks a bit odd to me.

[rr-]

Apparently the first bite missing can happen in vanilla too?

This croc is not the smartest, is it? :D

Thank you @walkawayy for the detailed analysis. Yeah, in this case I think we should go with solution 1.

[walkawayy]

Ok I have (hopefully) the last thing to discuss on this topic.

The OG code checks if (item->frame_number == g_Anims[item->anim_number].frame_base) to put the alligator in the required_anim_state to perform an attack. The issue with the frame_base check is, the alligator only has two useful current_anim_state's, ALLIGATOR_SWIM and ALLIGATOR_ATTACK. Animations 1, 2, and 3 are all attack states, so multiple damage instances can occur because the alligator can hit its frame_base animation number multiple times.

My proposed change would be to change if (item->frame_number == g_Anims[item->anim_number].frame_base) to if (item->frame_number == ALLIGATOR_BITE_AF) which is like frame 43. This way the damage only occurs once during the animation 1 bite and not during other animations' base frames.

[rr-]

I'm fine with such approach. We have to hardcode such frames anyway in other places, e.g. shotgun anims. And I'm pretty sure 60 FPS can handle this.