Alyria when I have the mixduration (or delay, they both seem to have the same problem) on the Add/SetEmptyAnimation set to a very small number say below 0.5, the animation seems to rapidly transition between the two states (seems like every frame) and it seems to do this for about half second before resetting to normal.

I'm not sure what is going on here. The video doesn't help because I'm not familiar with your project or how it is supposed to behave. It looks good to me! It seems like when you shoot twice, two recoil animations happen.

If there is a problem with the recoil animation, you'd probably need to create a simple app that ONLY shows this problem so we can take a look. Please don't send an entire app. Make an SSCCE.

Alyria The second problem is that my aiming logic is completely invalidated by the setToSetupPose being processed every frame

Calling setToSetupPose should not wreck your aiming. Every frame, after you setToSetupPose and apply your animations, then you adjust your bones for aiming.

    Related Discussions
    ...

    I can send you my project files, like I said the rapid switching is harder to see on the vid but it also illustrates that the aiming is malfunctioning.

    Nate Every frame, after you setToSetupPose and apply your animations, then you adjust your bones for aiming.

    I'm not totally sure what you're even saying here, I tried putting setToSetupPose higher in PhysicsProcess() (above the SetAnimation for my aiming animation) but it doesn't seem like it's changing anything. I have 1 frame aiming animations where the weapon bones are rotated based on the position of an IK constraint bone that's being driven by my mouse position in godot.

    • Nate replied to this.

      If it's necessary to send us a project showing the problem, you need to make a simple project that only shows the problem and doesn't have anything else. If you send your whole project, we won't have time to look at it. That said, you can send it here: contact@esotericsoftware.com

      Every frame:

      1. setToSetupPose.
      2. Move your IK target bone to the mouse position.
      3. Apply animations (eg call AnimationState apply).

      If calling setToSetupPose messes up your aiming, it's because you are doing 2 and then 1.

      Alyria I tried putting setToSetupPose higher in PhysicsProcess() (above the SetAnimation for my aiming animation)

      This is confusing because you should never be calling SetAnimation every frame. You set and add animations only when events occur, like the player jumps or shoots.

        sent my project files over, I was able to fix the weird stuttering on the recoil by using a different method for the input singleton, but I'm still having trouble with the aiming being broken.

        You sent a 226MB ZIP file. Sorry, but it is not reasonable to for us to debug your entire application.

        Nate This is confusing because you should never be calling SetAnimation every frame. You set and add animations only when events occur, like the player jumps or shoots.

        for my application that's too limiting as I need the player to be constantly updating their animation based on the position of their mouse cursor (front and back views are different animations). I changed how the SetAnimation functions as it checks to see if the same animation is already playing and if it is it won't be reapplied.

        Nate EDIT: I see you sent a 226MB ZIP file. It is not reasonable to for us to debug your entire application.

        oh wait sorry, I just realized I've been sending my export templates for no reason, I thought the mono/godot files we're taking up most of the space.

        • Nate replied to this.

          Alyria for my application that's too limiting

          It is never the right solution to call set or add animation every frame. It doesn't make logical sense, so however you think it works must be flawed. After setting an animation, it is applied every frame from then on, without you needing to set it again.

          Alyria I changed how the SetAnimation functions as it checks to see if the same animation is already playing and if it is it won't be reapplied.

          That is a reasonable way to do it. It sounds like that solves your recoil problem and my post above solves your aiming problem.

            6 days later

            Nate my post above solves your aiming problem.

            I don't see how it does, I already said that moving the setToSetupPose method higher in Process() doesn't seem to do anything even though all my aiming logic is written after it. Admittedly I don't have code that says to move the IK bone to my mouse position in that script as I accomplished that in the editor with the SpineBoneNode and it's drive property as instructed in spine's tutorial. Should I do that through code instead then as it seems to be processed first if the problem you're describing is true?

            The order of processing when using SpineBoneNode can't be guaranteed. For your case, where you move an IK target AND also apply additive blending, you will have to implement the entire logic of moving the IK target in your process() method.

            Alright so I finally seemed to have gotten everything working but was wondering if this is the best solution. Currently I have a Node2D that's dedicated to following my mouse position that I then take the transform of and set it to my specific IK bone. Using SetX/Y or SetWorldX/Y seems to cause some problems, I'm guessing because of how godot's coordinates work where -Y is up and Y is down. The runtimes doc/api is a little confusing with all the different properties for specific bones (in godot's case set methods) so not sure if I could be doing something better.

            Here's what I have for my code currently

            SetGlobalTransform() is exactly what you should use. Setting x/y on the bone is also possible, but as you found out much more involved.

            Glad you figured it out!