Since I've been getting this question a lot I will post my findings here concerning character tracking, animations and the problems therein: most importantly animation fall-through and snap-back.
An important thing to keep in mind is that there is a difference between location tracking and model tracking. As an animation is played, the game tracks the TransN node in order to update the character's location. How does the game know which bone/node is TransN? I believe this is stored in the action script somewhere but I'm not entirely sure. Here is an example of the two types of movement:
The expectation then, of course, is that the character location and model location (TransN) end up in the same place at the end of the animation. If they do not, then you have 'snap-back', which is caused when the model's TransN node isn't tracked properly by the action sequence. The TopN node will then be moved to the character location which doesn't match the real TransN movement, which causes a 'jump' in the model location/animation. Notice how when this happens, the player indicator (Player 1, names, etc) doesn't jump around like the model does. This is because it represents the true character location.
'Fall-though' is when the character model drops through the floor, and usually occurs along with snap-back due to the same reasons.
The cause of these two symptoms? Most likely you're using a character model that was imported (trophies or assists) that doesn't belong to that action script. More specifically, when you import an assist model into the zakogirl set. Although the model and animations will work, the node tracking does not.
Why? Because the action script references bone indexes (possibly node ids?) during an action sequence. If you're using a model where the root nodes are in different indices than the original (TransN, XRotN, YRotN), the action script will track the wrong nodes.
As many of you have found out, a simple fix is to change the animations to reference the wrong nodes. This has NOTHING to do with the animations themselves because they DO move the right nodes. By moving the wrong nodes, what happens is you're tricking the game into tracking the improperly-indexed nodes instead of the real ones.
If you experience animation glitches, do the following:
What you've just done is tricked the game into tracking properly by animating the bones at the proper INDEX. The animation will play through like it should regardless, because moving any parent node will move the child nodes/geometry.
Because the game thinks the bone at index 3 is TransN, you treat that bone AS IF it were TransN regardless of what it is actually named.
I imagine a person could edit the action script to reflect the proper node indices, but this is a quick fix. Until we can add/remove bones this will have to do.
Happy modding!
An important thing to keep in mind is that there is a difference between location tracking and model tracking. As an animation is played, the game tracks the TransN node in order to update the character's location. How does the game know which bone/node is TransN? I believe this is stored in the action script somewhere but I'm not entirely sure. Here is an example of the two types of movement:
- Ground movement. As ground movement occurs, the game leaves the TopN node in its current location and allows the model to be moved by the animation. At the same time, the game tracks the character location separately using the TransN node. At the end of a ground movement, the TopN node is THEN moved back to the character location so that the animation(s) can continue.
- Air movement, which is governed by the physics and is more free-form. The TopN node is moved every frame as animations are played to reflect the character's current location.
The expectation then, of course, is that the character location and model location (TransN) end up in the same place at the end of the animation. If they do not, then you have 'snap-back', which is caused when the model's TransN node isn't tracked properly by the action sequence. The TopN node will then be moved to the character location which doesn't match the real TransN movement, which causes a 'jump' in the model location/animation. Notice how when this happens, the player indicator (Player 1, names, etc) doesn't jump around like the model does. This is because it represents the true character location.
'Fall-though' is when the character model drops through the floor, and usually occurs along with snap-back due to the same reasons.
The cause of these two symptoms? Most likely you're using a character model that was imported (trophies or assists) that doesn't belong to that action script. More specifically, when you import an assist model into the zakogirl set. Although the model and animations will work, the node tracking does not.
Why? Because the action script references bone indexes (possibly node ids?) during an action sequence. If you're using a model where the root nodes are in different indices than the original (TransN, XRotN, YRotN), the action script will track the wrong nodes.
As many of you have found out, a simple fix is to change the animations to reference the wrong nodes. This has NOTHING to do with the animations themselves because they DO move the right nodes. By moving the wrong nodes, what happens is you're tricking the game into tracking the improperly-indexed nodes instead of the real ones.
-Pay attention because this will solve a TON of your animation problems-
If you experience animation glitches, do the following:
- Open the original character model and look at the bones. What you're interested in is the order and index of TransN, XRotN and YRotN.
Notice how in this example the indices are 3, 4, and 5 respectively.
- Open the modified character model and check these bones again.
In the new model the indices are 2, 3 and 4 respectively.
- What we now have to do is make the bones at indices 3, 4 and 5 move just like the original model would. In this case, XRotN has now become our TransN, and YRotN has now become our XRotN. We won't touch any others in this example, but I hope you get the general idea.
- Open up the FitMotion and find the animation you want to fix. What we want to do is essentially shift the animations so they move the appropriate bone.
- Using the example image, follow from left-to-right renaming the entries:
- Delete YRotN (because it's unused, you can do this differently if you like)
- Rename XRotN to YRotN.
- Rename TransN to XRotN.
What you've just done is tricked the game into tracking properly by animating the bones at the proper INDEX. The animation will play through like it should regardless, because moving any parent node will move the child nodes/geometry.
Because the game thinks the bone at index 3 is TransN, you treat that bone AS IF it were TransN regardless of what it is actually named.
I imagine a person could edit the action script to reflect the proper node indices, but this is a quick fix. Until we can add/remove bones this will have to do.
Happy modding!
