For your case try removing the third parameter within the module script since for your usage case you don’t need to worry if the base of your CFrame will tilt (Most likely the humanoid will stay upright unlike other turret types).
Edit: Another method is to move the turret attachment a bit further back instead of putting it right at the gun barrel, put it behind the gun body.
One question, since I cannot parent the turret attachment to the tool handle, I am looping it’s world position to another attachment in the tool barrel. Could this be causing the issue? None of the solutions that you proposed are working for me.
Edit: Moving the attachment behind the gun fixes only the part where it rotates like crazy, but it still doesn’t point the gun where it should.
With turret controller only the part that is further away from the root part will move which usually is the Part1 if rigged in that manner according to Motor6D Transform rules (check out how the R15 and R6 rig is structured Part0 is the Humanoid root part, Part1 is the torso then continues in another Motor6D joint Part0 is the torso and Part1 is the arm for R6). Consequently, this shouldn’t happen by using turret controller by itself check for other possible causes like body movers and such.
I believe if I deactivate the Motor maybe it’ll work? But then i’d have to use a weld which doesnt. I might put an animation on so it doesnt use the Motor. I’v done the same thing with a normal character and it works so im not sure why its not working.
Hey, there is a bug when trying to limit the rotation. I was making my own turret rotation system when I noticed the turret would rotate through a prohibited angle when the limit is higher than 90, so I came here to see how you handeled that but I’ve noticed it happens here too.
In the vid you can see how the turret rotates around a prohibited area.
The issue is the lerping method as CFrame lerp takes the shortest path hence crosses the prohibited zone. This is fixed in my private version of the module.
I found out that converting the CFrame to orientation then lerping the three numbers individually worked as the numbers respect the range.
local function lerp(start, goal, alpha)
--we can use our super simple equation at the start, using the 3 values
return start + (goal - start) * alpha
local x1, y1, z1 = (currentRotation):ToOrientation()
local x2, y2, z2 = (goalRotationCFrame):ToOrientation()
local x3 = lerp(x1, x2, l1 or self.LerpAlpha)
local y3 = lerp(y1, y2, l2 or self.LerpAlpha)
local z3 = lerp(z1, z2, l3 or self.LerpAlpha)
This respects rotation as it takes the longest path from -180 to 180 instead of skipping it as the numbers.
However I also encountered an issue if the C0 or C1 is rotated as C0 needs to have no rotation at CFrame.new() hence I did not update the module with it yet. I believe this will be fixed with my better C0 formula but I will see what happens later.
I have also developed a newer method using Springs which is like the CFrame :LookAt() but bounces a bit for visual effect. I will include it in the newer version once I fix the orientation bug.
First, for some reason, the torso seems to go a little bit “off” of the centre of the mouse position, you can see that in the gun’s laser. I dont know if its because of the player animations or is other thing.
Second is not a problem at all but is there a way to fix the torso’s horizontal movement when the player walks? That causes my gun to move to the sides and this module fixes vertical one (gun moves down) so im wondering if its possible with horizontal one