Feature request: TR2+ Jump Mechanics

[DanzaG]

Implement a config option that allows for TR2+ style running jumps i.e. you have freedom to jump at any point during a run once you start running.

[Richard-L]

Personally I'm not so much in favour of adding aspects of Laraphysics from TR2 to TR1. Just seems like the project's goals are on fidelity, accessibility, compatibility, and enhancements, whereas this feels more like an actual mod, because it mixes two games.

Just my two cents.

[rr-]

There are many players who hate TR1-style jumps (source: Twitch streams) so I think if this change is not very intrusive, such as replace animation X with Y, I don't think it'll hurt to include it provided it can be toggled. But posix is right, this has lower priority than us breaking free of TombATI.

[DanzaG]

Yes it depends on the scope of the change. To me, it is purely the jump "delay" from input to jump action that would be under the scope of this change. To me that is fairly minor compared to actually changing the jump itself which i want to remain the same. So it is more input-focused rather than actual behaviour.

Also it can be disabled by default in the config.

But I agree that this is low priority and I also agree that if a significant deviation from the original code is needed then id be happy to bin this request.

[oziphantom]

the animation change points are defined in the animation it self. So the code just says, "anim goal = Jump" then when the animation command runs that can do said jump it will switch. Looking at Tomb2Main lara_as_run isn't reversed yet so can't see if it has any other logic, or they just added more commands to the animation.

[DanzaG]

In tr3 there is additional logic for a "jump_ok" boolean in lara_as_run. When I get to my PC i'll find the snippet.

Not sure if its the actual fix, but its the only significant change in the jump logic in lara_as_run afaik.

[DanzaG]

`
​        ​if​ (item->​anim_number​ == ​6​)
​                jump_ok = ​false​;
​        ​else​ ​if​ (item->​anim_number​ == ​0​)
​        {
​                ​if​ (item->​frame_number​ == ​4​)
​                        jump_ok = ​true​;
​        }
​        ​else​ jump_ok = ​true​;

​        ​if​ (input & IN_JUMP && jump_ok && !item->​gravity_status​)
​                item->​goal_anim_state​ = AS_FORWARDJUMP;
​        ​else​ ​if​ (input & IN_FORWARD)
​        {
​                ​if​ (lara.​water_status​ == LARA_WADE)
​                        item->​goal_anim_state​ = AS_WADE;
​                ​else​ item->​goal_anim_state​ = ((input & IN_SLOW) ? AS_WALK : AS_RUN);
​        }
​        ​else​ item->​goal_anim_state​ = AS_STOP;`

[oziphantom]

that is just checking of lara is able to jump and then it sets the goal anim state to be forwardjump.

This then tells the animation engine I want to change animations, and then when "anim change" command is reached in the animation it will check to see if you goal_anim_state != current_anim_state and then it will switch animations. This way you can only enter a jump if lara has a foot on the ground for example.

[DanzaG]

Looks like it is just additional commands to animation as you suggested then? I'm doing all this on mobile so the formatting is all wonky but comparing TR1 and TR3 lara_as_run thats the only real difference I can see (at least from a jumping perspective).

[walkawayy]

TR1 state changes during Run animation:

TR5 state changes during Run animation:

It seems like TR5 animations have more freedom during the run to start the jump. These state changes are contained in the level files. If I understand this correctly which I might not.

[DanzaG]

sweet, makes sense. I can test this out by generating a level set using the TRLevelReader/Writer from rando.

[DanzaG]

https://streamable.com/phze2a - Natla's is normal jumping, caves is amended jumping using the JUMP_FORWARD state values taken from TR2 level files. I guess theres something else i'm missing? as you can see it's allowing a jump too early.

[DanzaG]

if​ (item->​anim_number​ == ​6​)​
    jump_ok = ​false​;​​
else​​ if​ (item->​anim_number​ == ​0​)​ {​​
    if​ (item->​frame_number​ == ​4​) {
        jump_ok = ​true​;
    }​
}​​ else {
    jump_ok = ​true​;
}

if​ (input &IN_JUMP && jump_ok && !item->​gravity_status​)​ {
    item->​goal_anim_state​ = AS_FORWARDJUMP;​​
} else if (input & IN_FORWARD)​ {
    if​ (lara.​water_status​ == LARA_WADE)​
        item->​goal_anim_state​ = AS_WADE;​​
    } else {​
        item->​goal_anim_state​ = ((input & IN_SLOW) ? AS_WALK : AS_RUN);​
    }​​
} else​ {
    item->​goal_anim_state​ = AS_STOP;
}

The code mentioned here will need to be implemented for it to work. I compared the animations and they match - I tested removing this logic from TR3 and it brings the same issue presented above. So I am pretty sure it's a combination of level modifications to make the animations and correct and that "hack" above to ensure the early jump is blocked.

Video of this logic enabled and disabled (first is enabled, second launch is disabled). https://streamable.com/6z9slv

[rr-]

Thanks @DanzaG for the analysis (the formatting is a bit messed). Personally I am anything but ready to implement the data injection, but I'd welcome any PR that attempts to do this.

[Richard-L]

Just please keep this optional if you can

[DanzaG]

Yeah optional is a strict requirement. I think if it wasn't possible to be an option (it shouldn't be a problem to make optional - configurable via JSON) then it'd be better not to have this at all.

I agree in that the only choice for this feature should be optional, disabled by default.

[lahm86]

Hi again @ajtudela - would you be able to translate the following new config option please?

"Title": "Responsive jumping",
"Description": "Allows Lara to jump at any point while running, similar to TR2+."

[ajtudela]

"Title": "Salto sensible",
"Description": "Permite que Lara salte en cualquier punto mientras corre, similar a TR2+."