Tomb Raider Forums  

Go Back   Tomb Raider Forums > Tomb Raider Level Editor and Modding > Tomb Raider Level Editor

Reply
 
Thread Tools
Old 21-10-14, 14:47   #1
Joey79100
Member
 
Joey79100's Avatar
 
Joined: Mar 2012
Posts: 3,741
Default Walking backwards and descending a block...

Hi!

I'll first explain something:
When Lara is walking and there's a step of 1 click, there's a special animation playing to show that she's "climbs" it, and it's different if it's the left of the right foot first.

Quote:
Originally Posted by Fluen: Lara's animations
055 – Ascend block (1 click high) running (left foot first)
056 – Ascend block (1 click high) running (right foot first)
057 – Ascend block (1 click high) walking (left foot first)
058 – Ascend block (1 click high) walking (right foot first)
059 – Descend block (1 click high) walking (right foot moved first)
060 – Descend block (1 click high) walking (left foot moved first)
061 – Descend block (1 click high) walking backwards (left foot moved first)
062 – Descend block (1 click high) walking backwards (right foot moved first) [never played]
When she's walking backwards, it's meant to work the same way, but there's a bug: Lara will always perform the animation with the left foot first and never the right foot. And it is this way from TR1 to TR5, it has never been corrected. This is the problem I'll be talking about.

These movements are hardcoded. Why?
Well, you see, normally the animations are linked with StateID changes* (in the State Change Editor for WadMerger). It tells "If you (Lara) encounter this situation (specified by the State number), then go to this animation."
For our animations, it couldn't work with StateIDs: unlike many other climbing animations, these ones play once Lara has "climbed" this step. If you look at the animation, for example, n°61, at the beginning Lara is not at the normal level but one click upper. And at the end of the animation she's on the normal floor level. If you remove the beginning of the animation, in the game you would see Lara playing the animation already when she's down, and not while she's still on the upper level.
(I hope I haven't lost too many people... )
If StateID changes were used, we would need to check if there's a pit (one click deep) behind Lara, and then we play the animation while she's still on the real upper level. It could have been possible to make it work this way, but it would have been more difficult to design the animations because you would need to be sure Lara is at the right place when the animation ends, when Lara's real position arrives above the pit, the animation would continue playing but inside the lower floor (because her position would be readjusted to be on the lower floor).

Anyway, these movements are hardcoded. Here's how I think it works:
When her vertical position changes from around one click, it checks what animation was playing right before, and what frame. If, for example it is the walking animation, and it was playing the first half (not exactly the first half I think), then it will play animation 57 to simulate Lara climbing the step. And it works like that.
But with the walking backwards animation, something hasn't been programmed correctly, and it's always the left foot animation which is playing (animation 61). Unfortunately, even with TRNG we can't check what animation was playing before, so we can't use Animation commands with our ENV_ constants to force playing the other animation when it has to be played.


Possible solutions:
1) Maybe we could use two variables to save the number of the animation that was playing and then we check if it's correct. For example, we put the animation currently playing is the first variable, and when the next animation starts playing, we first move the value in the first variable to the second, and update the first, and then we check the second variable to know the previous animation number. And do the same with the frame number (so 4 variables in total, unless we combine the two numbers... it would be limited then, you would need to not exceed a certain number of frames or animation). It's a bit too much for this... well, it could be useful for other purposes to know this too... but after all, if it works like I think it works, the previous animation number and frame number might already be stocked somewhere thanks to some code in the executable.

2) The other way would be to send something to a variable during the walking backwards animation (with a trigger put in a SetPosition command), like 0 (for "false") at the beginning, and 1 (for "true") at the half of the animation. And when the animation 61 is playing (when she goes down with the left foot first), if the variable is true, we could force the animation 62 to play (directly at the beginning, and the player wouldn't see any problem). It would also work and be much lighter than the previous solution, but I'm still not sure it's worth doing so much for something like that.



So I wanted to know if someone has already found a way to enable this second animation? Maybe it would be possible with FLEP if someone writes something? Or someone who re-enables it in the code (like Paolone in his next update)?
If not, I'll do one of the solutions... I think I'd do the second one, and maybe tutorials for both solutions (and the first one would be useful not only for this).



Warning: State ID changes are not the same thing as State IDs! They use StateIDs but are something different. The StateIDs define some states of Lara (or enemies..), and StateID changes are what permit to link an animation to another depending on if a new StateID is true. People often tend to confuse them.
Joey79100 is offline   Reply With Quote
Old 21-10-14, 15:25   #2
Dustie
Member
 
Dustie's Avatar
 
Joined: Apr 2005
Posts: 9,208
Default

I feel confused as to whether this is about climbing, walking, or both, since you seem to use the words interchangeably in your sentences.

I don't really understand what this is about anyway, but maybe clarifying the walking/climbing difference would make it easier to understand for others.
Dustie is offline   Reply With Quote
Old 21-10-14, 15:38   #3
TR-Freak
Unverified
 
TR-Freak's Avatar
 
Joined: Jan 2008
Posts: 5,140
Default

He's talking about the animation "bug" with walking backwards and 1 click lower floor.


I wonder why this "bug" happens. Up to TR3 the animation works correctly.
TR-Freak is offline   Reply With Quote
Old 21-10-14, 16:36   #4
Joey79100
Member
 
Joey79100's Avatar
 
Joined: Mar 2012
Posts: 3,741
Default

@Dustie: Well... This is about climbing when walking...

Seriously, when I say "climbing" it's for 1 click, so when you're just going forward (or backwards) but you don't have to press Action.

See the video TR-Freak posted or mine (I waited a hour to upload it so I post it anyway ). As you see, when walking backwards, there's only one of the animation playing: always the left foot first, even when it should be the right foot.
Though the animation exists in Lara's animations, but it's just not triggered in-game.

@TR-Freak: Mmh... I think of three possibilities:
1) They typed the values wrong. Instead of Animation Frame 0 to Frame 30, they typed Frame 0 - Frame 300 for example for the left foot animation. So the other one never plays even if the condition is true, as it can't play two animations at the same time.

2) They typed other values wrong. Instead of Play Animation 58 they typed Animation 57 for both.

3) They have triggered only one animation while they were creating the system, and forgot to add the other one.

Maybe it's something else too, only them can be sure.
What we can be sure though is that they never really see it or they forgot to correct it.
But are you sure it worked before? I haven't checked in TR2 and TR3 but in TR1 there's the bug (and the video you posted shows it).
Joey79100 is offline   Reply With Quote
Old 21-10-14, 17:43   #5
Dustie
Member
 
Dustie's Avatar
 
Joined: Apr 2005
Posts: 9,208
Default

Ah, that's the bug... I don't think I ever noticed it before, but you're right, there's an animation skip. It looks like this simply wasn't coded right.


As for game numbers - I've just checked it with TR3 and TR2, the animation bug/skip is there too.
Dustie is offline   Reply With Quote
Old 21-10-14, 17:55   #6
Krystian
Member
 
Joined: May 2010
Posts: 1,187
Default

I've noticed this bug before, and it had me puzzled when I first saw it.

I honestly think it isn't worth using precious (and limited!) variable slots for fixing this issue, though.
I wonder if it could be solved without using variables, such as some unconventional animation scripts . I'll try experimenting with it when I have some free time.

Putting scripting aside, Paolone could be asked about the possibility of registering the previous animation in the future (when he isn't busy with more important things, of course). Obviously, the TR engine appears to have this, it would take figuring out how to access it.
Krystian is offline   Reply With Quote
Old 22-10-14, 01:35   #7
Joey79100
Member
 
Joey79100's Avatar
 
Joined: Mar 2012
Posts: 3,741
Default

Right now I'm not using a lot of variables, only LBA1, LBD4 & LSB1, so I'll do it this way for now (with LBA2 that I could use to store other informations about the animations I think) I'm quite picky with animation transitions and I don't wanna leave this buggy thing.

He figured out how to access the current animation number (it's in the Item Memory zone), so I think it's possible. And if he can't directly find it, maybe he could create another variable especially for it?
Oh, by the way, it's making me think about something... With 1.2.2.8, TRNG will be open-source (so no more new functions by Paolone I think, or only in the early days... anyway we'll see). So theorically, we will have an unlimited amount of variables, right? If yes then it's no more a problem. =D
Joey79100 is offline   Reply With Quote
Old 22-10-14, 17:49   #8
PhantomPain
Member
 
PhantomPain's Avatar
 
Joined: Dec 2012
Posts: 1,049
Default

Had no idea about this bug, but I have noticed that the 1-step ascending animation always starts when Lara's leg is already in the "new" block so it doesn't look that seamless unless you go at an angle.
PhantomPain is offline   Reply With Quote
Old 22-10-14, 19:15   #9
Joey79100
Member
 
Joey79100's Avatar
 
Joined: Mar 2012
Posts: 3,741
Default

Indeed. I think it was made this way simply because technically speaking, the animation starts when she's already on the next block. Maybe they were afraid that with a "beginning" part on the animation, you'd see Lara walking and then suddenly appearing backwards before the ascending animation because it would have to start a bit before she's on the next block.
Though I'm sure it's perfectly possible to make it without looking that weird. I've already started working on these animations on my side.
Joey79100 is offline   Reply With Quote
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off



All times are GMT. The time now is 20:50.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.
Tomb Raider Forums is not owned or operated by CDE Entertainment Ltd.
Lara Croft and Tomb Raider are trademarks of CDE Entertainment Ltd.