My guess is that what actually happens is that the static animation table is not reset when all actors are reloaded. We use reset functions to reset static actor data. It may be best to try to fix it there. Further, the cvar could wrap the code in reset to apply the spin.

I'll try to take a look into that, but I don't think the data that seems to be responsible for the spin is static. The morphFrames I mentioned actually get applied to calculations to a particular actor's skelAnime->morphRate and morphWeight further down the line. I could have also constantly reset those to 0 during some of the action functions, but that came off messier than the fix I supplied here.

I'll see about resetting some of these values in the reset function and see if that does anything.

Yeah I'm not seeing any static info I can reset in the Goron's actor in order to prevent this spin from happening. It's gotta be something about the morphFrames, and I'm pretty sure they've been spinning since the very beginning, even before we implemented matrix interpolation. This is the only fix I'm aware of.

Yeah I'm not seeing any static info I can reset in the Goron's actor in order to prevent this spin from happening. It's gotta be something about the morphFrames, and I'm pretty sure they've been spinning since the very beginning, even before we implemented matrix interpolation. This is the only fix I'm aware of.

Static data reset would have nothing to do with frame interpolation. :)

So in the authentic game, actor code was loaded similar to how a dll is loaded in modern programs. They'd be unloaded when all actors are removed. This loading and unloading of code would clear anything in the .data section of the overlay code.

Since Ship does not use actor overlays, the static data is by default not reset and never has been.

Oh I thought I remembered your first comment mentioning something about interpolation so that's why I was confused, so we're on the same page about this having nothing to do with interpolation. Must've gotten my wires crossed.

By resetting static data, you're referring to something similar to what I did in #639 right? Or something else? If the latter could you point me in the right direction on where this data reset needs to occur? If it's the former there is no static data in the Goron actor that I can reset that has any effect on the spin. Believe me I've tried.

Yeah, it'd be the same thing. I don't see the anim array getting changed in the code, though, so it's unlikely to be static data reset problem.

In the initial PR you mention something is errantly set to -8.0f. What is that, and can you determine why?

It's just what's in the code in the sAnimationInfo array declaration in z_en_go2.c. I'm not sure if it's exactly "errant" or if it's something that just behaves differently on N64 due to some quirk, but it's the morphFrames attribute of the AnimationInfo struct in some of the elements of that array. These values are the same in decomp that they are in our codebase currently, without this PR, which is why I wouldn't say they are errant, just causing an issue on our end. I should probably try to build a decomp rom at some point and verify that it isn't an issue there but I doubt it is.

For the first video I posted in Discord I had changed the basic Goron Wake Up animation to the 0 index of that array instead of 1, but I later realized that the only difference between those two AnimationInfo entries was the morphFrames, where the 0 index had 0.0f for the morph frames and the 1 index had -8.0f. They both referenced the same AnimationHeader (and so does Biggoron with index 10 of that array). So I created two new AnimationInfo entries for the fixed morphFrame versions. One for basic Gorons, and one for Biggoron. Biggoron's animation was also referencing the same AnimationHeader but had a different value applied for it's mode attribute to enable interpolation, since his animation plays slower and would look choppy without it. Additionally, Biggoron had one frame where he seemed to "disappear" and pop back in when the morphFrames were set to 0.0f, so I set the startFrame to 1.0f to sort of skip that frame. I could probably re-use the 0 index animation for basic Gorons instead of creating a new one, it just seemed right to create a new one in the spirit of keeping our changes separate from the base decomp project wherever possible.

Maybe there's something waaaaay deeper in the code we could change but every other animation in the game I'm aware of plays fine as is, so changing anything there would require a lot of testing.