How to fix this extreme marble glitching?

Help and Feedback Scripting Support
#1

Hey, Im using @EgoMoose’s marble controller and it works great. I have it set the player’s cframe to their marbles cframe ON THE CLIENT. This causes this behavior which is quite terrible to look at:

What you see in your marble:


What others see:

I tried putting characters on the server’s network ownership but everyone was outside of their marbles. Could anyone tell me why this happens and how to fix it?

Edit, not sure if this is important but the marble’s network ownership is the client.

#2

Hm, can you try making the bubble the Adornee of the player?

#3

Is Adornee a property of the bubble? If so, I will try whatever I can to get this to work!

#4

It depends what material the bubble is made out of, take a look at the Properties.

#5

Its a sphere made of glass.

I also got this error when trying to set it’s adornee:
Adornee is not a valid member of Part

#6

Hm, that’s super weird. I’m unsure then, sorry. :frowning:

#7

Are you sure that parts have a property named Adornee? Adornee is a property of guis and stuff, I don’t think that its with base parts

#8

Mhm, they probably don’t. That’s why I’m unsure.

#9

use welds created on a Server Script

local character = nil
local marble = nil
local hrp = character:FindFirstChild("HumanoidRootPart")
local w = Instance.new("Weld")
w.Part0 = hrp
w.Part1 = marble
w.Parent = hrp
#10

You could try making everyone’s clients update their character cframes. For example, when someone’s client updates their positions, you could make the server fire an event to every other player’s client to update the positions and you wouldn’t have to wait for the server. The only issue with is that you would probably reach the rate limit for the remotes.

example

-- client
UpdatePositionRemote:FireServer(Character:GetPrimaryPartCFrame())
-- the only down side with this is that exploiters can modify this and their character will appear different for everyone else

-- server
UpdatePositionRemote.OnServerEvent:Connect(function(player, cframe)
  for _, v in pairs(game:GetService("Players"):GetPlayers()) do
    if v == player then
      continue
      -- this skips the iteration if the current player is the player who fired the remote because their screen is already set up
    end

    ClientRemoteToUpdatePlayerPosition:FireClient(v, player.Character, cframe) -- this sends an event to tell the clients to update their screens
  end
end)

-- client again
ClientRemoteToUpdatePlayerPosition.OnClientEvent:Connect(function(char, cframe)
   if char then -- checks if the player's character exists
     char:SetPrimaryPartCFrame(cframe) -- update their position on your screen
   end
end)

This has a very high chance of not working, this is just what I personally think could solve the issue. But again, there are multiple factors that could mess it up.

They don’t.

1 Like
#11

Welds cause me to fly across the map and makes the marble uncontrollable. Tried this already :confused:

#12

Already constantly updating the character’s cframe on the server connected to RunService.Heartbeat. This gets rid off the glitchy, seizing behavior but the players just kinda float to their ball rather than sticking inside it.

I will make sure to try this method tommorow though.

#13

try enabling Humanoid.PlatformStand and maybe set the Marble.RootPriority to 10
im pretty sure welds would work if you do them right

1 Like
#14

Humanoid.PlatformStand is set to true. I think I’m just going to go with the solution I have now although I will be down to try this in the future! My current method is to update the positions on the server every heartbeat + updating them on your client so it looks smooth. The only issue is that sometimes players aren’t completely in their ball.