Universal Fighting Engine Forum Universal Fighting Engine (UFE), a fighting game toolkit for Unity 3D |
You are not logged in. Please login or register.
Universal Fighting Engine Forum → General → Animation and hit collision frame problem.
Let me ask you two questions.
1. Animation and collision occurrence frame seem to be different in editor preview and scene.
In both cases, a gap of about 1 frame occurs.
2. Even if the hit collision setting is 9 to 10 (Active: 1), why does it exist for 2 frames?
My environment:
Unity2019.3.3
UFE 2 SOURCE Version 2.3.0
Windows10
japan
I prepared two images.
(I'm sorry if it is hard to understand)
Thank you.
Share
Yeah, this has been an issue since UFE1. It's the reason I use CustomHitBoxMaps instead of the "where ever the character's motion is" since at that point the hitboxes are separated from the animation requirement. In my experience there can be an ambiguous 0-2 frame delay to the animation with the hitboxes by using the traditional animation-based hit boxes. And I have yet to find a pattern as to why it's 0 on some moves and 2 on another. My best guess has always been it's a delay in loading the animation to play. If you figure out why, I'd be happy to hear about it.
Share
+1
Auto maps and animation maps may cause some variations between the Editor and runtime. Like MrPonton said, if you want something more exact, I recommend using custom hitbox maps:
https://www.youtube.com/watch?v=7WHkkioBSMw
Thank you!
I will try a custom hit box.
Share
I tried using "custom hit box", but my environment didn't seem to fix the gap.
I changed the following script part as a temporary measure.
HitBoxEditorWindow.cs
898:float animTime = ((castingFrame + 1) / (float)config.fps) * (float)animatorInfo.speed;
MoveEditorWindow.cs
3898:animTime = (((animFrame + 1) - castingFrame) / moveInfo.fps) * currentSpeed;
3915:EditorGUILayout.LabelField("Animation Time:", animTime + " ("+ Mathf.Floor((animFrame/(moveInfo.totalFrames - 2)) * 100) +"%)");
I found one question during the change.
"Animation Preview → Animation Frames"
I feel that the maximum value of this value is one frame larger.
Example:
OK : 21 frames = 0 to 20 frames
NG : 21 frames = 0 to 21 frames
Share
Example:
OK : 21 frames = 0 to 20 frames
NG : 21 frames = 0 to 21 frames
Yeah, UFE should be using the "OK" example you gave, but there may be missed/old code using the "NG" example. If you have direct code references on where they need to be cleaned up to the "OK" example, it would be appreciated.
Presumably any such instance would also fix 2D animations repeating their first frame at the end of the animation issues.
I tried using "custom hit box", but my environment didn't seem to fix the gap.
To clarify, custom hit boxes won't solve the animation delay issue, but it will make the hitboxes appear on the frame you want them to in the position you want them to. So while the animation is 0-2 frames behind, it wouldn't be noticeable when playing in-game.
I should also restate that the 'delay' of the animation frame I've seen consistently for the same moves/animations that have it. It doesn't seem to happen for every animation or move, but when it does it always does by the same frame count. That's why it's been difficult in fixing this bug, because I haven't seen it being consistent across all moves. In my personal game, I have one move that is 0 delay on the animation, another that's 1 delay, and a third that is 2 delay. Never have seen one with 3 delay.
Share
Yeah, UFE should be using the "OK" example you gave, but there may be missed/old code using the "NG" example. If you have direct code references on where they need to be cleaned up to the "OK" example, it would be appreciated.
Probably the handling of "move.currentFrame" and "move.totalFrames" in "ControlsScript.cs" is suspicious.
Because it was difficult to convey it in sentences, I made it an image.
I changed the following script and it came close to what I expected.
HitBoxEditorWindow.cs
MoveEditorWindow.cs
I undone the two modified scripts.
ControlsScript.cs
1628:move.currentTick = (move.overrideStartupFrame + 1);
2153:if (move.currentFrame >= move.totalFrames - 2 ) {
I forgot to say it, but I enjoy "UFE2" very much.
Thanks for the wonderful assets!
Share
So you're saying it's jumping to frame 2 of the animation when it should be showing frame 0 of the animation? or that frame 2's hitboxes are rendering while the animation is on frame 0?
Share
The "frame" of the animation are called "keyframe" here, as they may be confused by the same name.
Animations are counted from 1 keyframe.
problem:
1. The first keyframe of the animation is not displayed during the game.
2. The timing of the hit box seems to be synchronized with "move.currentFrame", but there is a gap because "0" occurs twice.
3. It seems that the end timing of the action is seen in "move.currentFrame" and "move.totalFrames", but since it is counted from 0, it is calculated one extra frame.
4. Due to the above 1,2,3 problems, the animation stops for the last 3 keyframes.
The animation problem of the 0 keyframe and the timing of hit box occurrence are summarized in the image.
Share
Yeah, I've been trying to fix this bug for like 4 years in my game...
Share
Wow 4 years ...
The problem of frames is deadly in fighting games, so I really hope that it will be fixed.
I will post if I can find any influential information.
Share
Wow 4 years ...
The problem of frames is deadly in fighting games, so I really hope that it will be fixed.
I will post if I can find any influential information.
Yeah, every time I have tried fixing this issue it has caused numerous other issues to come out since frame counting is so integral to a fighting game. I'll try to look at it again this weekend and will let you know of any results. I'm not the dev, but I just have access to Source and it's a bug I would like to resolve on my own game as well.
Appreciate your detailed information, and thank you for any future information you're able to provide.
Share
+1
While researching this issue this weekend, I found an issue with displaying the indexed first frame of the animation in the move preview. That is a step forward I think. Previously, Frame 0 would not render, and it would just render the last valid frame set.
MoveEditorWindow.cs
L:4069
if ((int)animFrame != castingFrame) animationClip.SampleAnimation(targetChar, animTime);Remove the If
animationClip.SampleAnimation(targetChar, animTime);Share
I found out why the first frame of the animation did not play during the game.
It seems that one frame is skipped because it is forcibly updated by "animator.Update (0)".
MecanimControl.cs
409:animator.Update(0);
Share
I found out why the first frame of the animation did not play during the game.
It seems that one frame is skipped because it is forcibly updated by "animator.Update (0)".
MecanimControl.cs
409:animator.Update(0);
Did you find a solution?
Share
I found out why the first frame of the animation did not play during the game.
It seems that one frame is skipped because it is forcibly updated by "animator.Update (0)".
MecanimControl.cs
409:animator.Update(0);
That wouldn't be the case. UFE does force the update on purpose so the game can run deterministically. You can change that under Character Editor -> Move Set -> Animation Control, but for the most part you wanna have UFE take care of that for you.
Also, I wouldn't recommend changing that part of the code unless you are already very comfortable with the entire engine.
Remember that UFE has rollback netcode, and it's all tied up to a chain of events that links both animation and game logic.
Even I, who wrote 90% of the code will often break the engine when trying to fix things that go that deep.
That wouldn't be the case. UFE does force the update on purpose so the game can run deterministically. You can change that under Character Editor -> Move Set -> Animation Control, but for the most part you wanna have UFE take care of that for you.
Also, I wouldn't recommend changing that part of the code unless you are already very comfortable with the entire engine.
Remember that UFE has rollback netcode, and it's all tied up to a chain of events that links both animation and game logic.
Even I, who wrote 90% of the code will often break the engine when trying to fix things that go that deep.
I'm sorry.
Restored "MecanimControl.cs".
However, there are still some issues with frame misalignment, and we hope that it will be fixed.
Thank you very much.
I'll try to temporarily deal with it by changing the preview part of "HitBoxEditorWindow.cs" and "MoveEditorWindow.cs" while being careful not to have a bug personally.
Share
Universal Fighting Engine Forum → General → Animation and hit collision frame problem.
Powered by PunBB, supported by Informer Technologies, Inc.