The function used is Model:SetPrimaryPartCFrame().
The primary part rotates differently to the rest of the model. Here is a picture of them problem (this is from Gl0in2, he had the same problem)
It pretty much makes the api function useless.
The function used is Model:SetPrimaryPartCFrame().
The primary part rotates differently to the rest of the model. Here is a picture of them problem (this is from Gl0in2, he had the same problem)
It pretty much makes the api function useless.
Is this happening when you rotate a humanoid model? How do I repro? Just rotate a humanoid model a few times?
It happens when I try to rotate any model, however it seems to happen a lot when I try rotate over two axis at one.
For example: CFrame.Angles(50, 20, 0)
EDIT: After further examining it appear to happen when the amount you rotate it by changes a lot. I don’t really know of any other way to describe it. Here is an example.
EDIT2: Here is a gif
Yes please indeed fix this
Hmm what if you used quaternions to rotate the part? Since rotating two axes at once using Euler angles gets pretty wacky
“Hmm what if you used quaternions to rotate the part?”
I can verify that it’s just plain broken: It’s applying it’s matrix transform in the wrong order giving the PrimaryPart a local transform vs the other parts a global transform.
I’ve found the issue and submitted a fix for release. This should be out a week from Thursday.
…Until then, the now-deprecated methods like GetModelCFrame() still work!
I found another potential issue with this new API. I’m using it to keep a model spinning constantly, so every frame :SetPrimaryPartCFrame() is used to rotate the model. Over time, the members of the model gradually spread out, as you can see here if you skip through the video.
It seems like an accumulating floating point error? Is this something I should be doing something to prevent, or is this a fault of the API?
[quote] I found another potential issue with this new API. I’m using it to keep a model spinning constantly, so every frame :SetPrimaryPartCFrame() is used to rotate the model. Over time, the members of the model gradually spread out, as you can see here if you skip through the video.
It seems like an accumulating floating point error? Is this something I should be doing something to prevent, or is this a fault of the API? [/quote]
Confirmed, I have also been experiencing this. The faster (ie the higher rate of change in cframe values, not the speed of setting them) you set cframe values the more obvious this becomes.
It happens even on usermade cframe functions, reinforcing the fact it may be a rounding point error.
It happens even on usermade cframe functions, reinforcing the fact it may be a rounding point error.[/quote]
Bump on this any fix for it or?
Yes, if you want to do long-running animation on non-jointed models you will still need to use a hand-made function that records all of the initial offsets and re-uses those each time to prevent accumulation of floating point error.
This still seems broken. The parts all rotate together now however they don’t seem to rotate to the correct cframe.
[quote] This still seems broken. The parts all rotate together now however they don’t seem to rotate to the correct cframe. [/quote] I did some examination, it seems each part rotates relative to its own CFrame, regaurdless of the primarypart’s CFrame.
I actually LOVE the effect it gives to the spinning plumb bob above Lord of the Lesser Noobs’ head. Given that rounds won’t last long enough for them to drift far apart and they’ll reset when destroyed, it’s fine for my purposes regardless of if it is fixed.
Yup, it’s definitely still screwey. Easy test case, insert a model and a part, this in the command line:
while true do wait() game.Workspace.Model:SetPrimaryPartCFrame(game.Workspace.Part.CFrame) end
→ And this happens when you mess with the part:
[video width=425 height=344 type=youtube]rsRPxqQiyj8