So that means you haven’t changed anything within the horse itself?
The current way you are doing it is going to lead to a lot of unintended side affects.
1 Like
When you create the join that connects the player and horse its created in a different spot then the one you rigged up
So I decided to print out where the CF’s positions are and it doesn’t look to good.
(rHorse is the dummy model horse)
Also based of the print the character shouldn’t even be moving like that, it should instantly teleport off into the abyss
You’re saying the connecting joint between the player and horse are different in the animation rig vs the in-game connected version? How would you remedy this?
You can use the command bar to manually change the root joint’s CFrame.
workspace.Horse.Horse_Root.Joint.C0 = CFrame.new(Vector3.new(0,0,0)) workspace.Horse.Horse_Root.Joint.C1 = CFrame.new(Vector3.new(0,0,0))
This should change the rig’s cframe.
Then for the other one you can just remove the joint.C = because it will be 0,0,0 by default
Doing this doesn’t seem to fix the issues listed in the original post.
I’m still left with the problem shown in the in-game mp4 at the top.
Could you send over a screenshot of the explorer along with a print of the horses cframes?
Also wouldn’t it be easier to get in a call, I’m in the atf discord fyi.
Everything I’m working with is the same as in the file at the top.
Print of the horses cframes would be the most impotent then
I’m saying that the horse in the file is the one I’m using. I’m not sure how obtaining the horse’s CFrames would help.
This seems to be a joint issue to me.
The motor 6d’s cframes define the position of a join (where and how it turns)
The horse + player rig:
The horse + player in-game:
I don’t see any huge differences between these sets of numbers, but perhaps I’ve missed something.
I just need to root parts Joint CFrame that connects the person with the horse which the code for is here (also very nice use of Instence:GetFullName())
The CFrames of the root parts? They’re both the exact same.
So both joints 
have the exact same cframe both the one with the player on it and the rig?
Yes, as printed above.
The issue persists
Currently running on 3 hours of sleep, I’ll reply later. Sorry for having to make you wait.
So I have managed to replicate the bug and all I have to say about it is that, something unnatural has been angered and we are all doomed.
Everything I can think of is exactly the same yet the animation is almost twice as exadurated as the original.
I’m off to call in some backup (You know an issue is really bad when the backup calls in backup)
Reducing the player’s hipheight seems to fix the bug, I’m not certain why, but it seems to have a large effect on the rotation between the hip part + HRP, I’d imagine this has something to do with player scale being altered by the height.
Yep, you can see the effects live in-game;
disabling Automatic-Scaling toggles the problem.
Enabled, it adjusts the animations via some amount, based on height.
With AutomaticScalingEnabled disabled, you can set the height and no issues occur.
Server Code change
local char
local mount = game.Workspace.Horse
game.Players.PlayerAdded:Connect(function(plr)
plr.CharacterAdded:Connect(function(char1)
char = char1
end)
end)
while not char do
wait()
end
for i = 1, 5 do
print(6 - i)
wait(1)
end
char:SetPrimaryPartCFrame(mount.PrimaryPart.CFrame)
mount.Parent = char
mount.Humanoid:Destroy()
mount.Head.Name = "Horse_FalseHead"
mount.HumanoidRootPart.Name = "Horse_Root"
local joint = Instance.new("Motor6D")
joint.Name = "Joint"
joint.Part0 = char.PrimaryPart
joint.Part1 = mount.PrimaryPart
joint.C0 = joint.Part0.CFrame:toObjectSpace(joint.Part1.CFrame)
joint.C1 = joint.Part0.CFrame:toObjectSpace(joint.Part1.CFrame)
joint.Parent = joint.Part1
char.Humanoid.AutomaticScalingEnabled = false --< all that needs to change
char.Humanoid.HipHeight = 4.6
results with
https://i.gyazo.com/a79d5935afe5c256689ec89478ae00b0.mp4
5 Likes
All that time, that one setting was causing this.
Thank you for taking the time to look into this. I’ve been stuck on this for a week.
1 Like
Remember though, you’re still going to be fighting against other animations. I’d look at changing the animation priority to something higher unless you want something else playing over the top.
This is still a bizzare problem.
2 Likes