View Single Post
Old 17-01-20, 08:52   #19650
Joey79100
Member
 
Joey79100's Avatar
 
Joined: Mar 2012
Posts: 3,741
Default

The game engine uses StateIDs two ways.
First, the "current" State, which is usually exactly the one in the animation properties. For example, animation 103 uses StateID 2, which is the "standing" state.
And the Next StateID to determine what she should do next.

A function is attached to every State. That means there's a function for StateID 2, and it's where the game decides what to make her do next. Depending on conditions, a new StateID is put in queue, the "Next StateID", which tells what she should do next.
For example, in the Stand state, if the Up cursor key is pressed, and Lara is on dry land, and there is no wall in front, the game will set the Next StateID to 0, ie. the Run state.
That's where the State Changes you see for each animation come: every line says "If Next StateID A is called, and the current frame is between frame B and C, then switch to animation D and start at frame E".

Actually now I'm going to correct what I've said: there is not 1, but 2 function for each State. One is for normal logic, the other one is related to collisions, and the latter will often force animations (and new current and next StateIDs) depending on the situation, and it will have priority over State Changes. For example, when Lara is jumping forward, and she hits a wall, that's the collision function that will takeover and force the wall hit animation. Why? Because it has to happen immediately even without a State Change, and because it also sets the value for other variables like the speed and direction at the same time.
So you won't see a State Change that leads to the wall hit animation in this case.

All that also means that every possible sotate change must have been planned in the code by Core to be possible. For example, the Swim forward state won't ever be triggered during the Stand state, Core didn't plan it because it made no sense. There are also things they forgot some times.
What I mean is some animations have special States. While the landing animations usually have the Stand state to allow the regular actions Lara can do while she's standing (provided the State Changes exist of course), some animations have different states for some reason. The Stop sliding animation might be in this case, and the issue would be that the corresponding function has no code that will trigger the Run state. Probably just because they forgot, nothing more. That means that even if you put the correct State change in the animation to trigger animation 246 (stop sliding to run), practically it won't ever be triggered.
(I've seen your EDIT after typing this, so in this case there's no issue but it's still applicable to other animations)

Sometimes the only difference some StateID have is that they have different camera behaviors, or even nothing specially important.
Since we know the Stand state can trigger the Run state, you could try changing the Stop sliding animation's state to 2 (the Stand state). If there is no side effect, then that means you can safely trigger the Run animation using a simple State Change, and it will work. So I'd say: try it.

Note that I haven't got in too much details, but it happens some times things are hardcoded. For example, during the Run state, if Lra started running frim standing (so playing animation 6), the Jump state won't be triggered until frame 19 of the run animation is reached at least once, even though the animations have the necessary state changes for the jump animations. They did that to mke her jump at the very last minute when doing a 1-block run jump, but it can be helpful to know when things don't work as they normally should.
Joey79100 is offline   Reply With Quote