Floor Sliding/Humanoid.HipHeight spontaneously set to 0

[DataBrain (Amber)]

Edit: This is likely a StreamingEnabled/client-side replication related bug; see the second post

In my game, I get user reports of players jumping/landing on the floor in certain areas, and then sliding through the floor uncontrollably and at very fast speeds. This generally gets players stuck, and often kills them in the process.

This is a very difficult bug for me to reproduce, since it happens so rarely, but it also happens enough that it’s become a problem for many users in my game, as well as NPC humanoids. This has been going on for months in this game, ever since it was released:

Dawn of Aurora🌆 RP

User reports:

Video of sliding: robloxapp-20200620-0937273.wmv (3.1 MB)

In Dawn of Aurora, the most common scenario in which this bug happens seems to be when players jump and land on floors with a thickness ~1 or less. Spontaneously, they begin sliding through the floor uncontrollably.

After searching the DevForum for “floor sliding glitch” and the like, all I could find were cases in which Humanoid.HipHeight are set to 0. When this happens, it produces the same sliding behavior that users are reporting. So I suspect that in certain, spontaneous moments, Humanoid.HipHeight is being set to 0. I have literally no code that affects Humanoid.HipHeight, so I would assume this is not caused by anything on my end.

I have also reproduced this with some NPCs in my game, and was able to confirm that indeed, HipHeight can be spontaneously set to 0. Sometimes NPCs spawn in, being stuck in the floor, and when selecting that NPC’s Humanoid, its HipHeight is 0, even though the NPC is cloned from a template with a HipHeight of ~2 or so:

I still don’t know the exact root cause of this bug, nor can I ever reproduce it consistently, but I hope this thread can serve as a starting point for finding this cause, especially if (hopefully) I’m not the only one experiencing it. I also wondering if this has anything to do with StreamingEnabled or server-side lag.

My guess at what the cause could be

• Since my game has StreamingEnabled on, Humanoid/HumanoidRootPart objects can potentially load in before a character’s legs, and said objects could be have network ownership assigned to a player who does not have the legs loaded in. This would result in a HipHeight being auto-calculated as 0 on the client.
• When the NPC is :Cloned() in, its legs are registered before the Humanoid, and HipHeight is set to 0 and never re-calculated when the legs are copied under the character model being cloned. This does not explain the cases when other users start spontaneously sliding through the floor though.
• Something to do with the custom armor sets/accouterments in the game, which can be welded to the character’s legs.

[DataBrain (Amber)]

After testing this a bit, this appears to be completely client-side for NPCs, which makes me think this is a streaming issue.

I had this code running on the server in an attempt to patch this bug for NPC/player humanoids:

local CollectionService = game:GetService('CollectionService')
local TAG = 'HIP_HEIGHT_FIX'
local PRINT_BELOW_THRESHOULD_HIP_HEIGHT = 0.3

local function correct(hum, desiredHipHeight)
	if hum.HipHeight ~= desiredHipHeight then
		if hum.HipHeight < PRINT_BELOW_THRESHOULD_HIP_HEIGHT then
			warn("Corrected hip height of " .. hum.HipHeight .. " for " .. hum:GetFullName())
		end
		hum.HipHeight = desiredHipHeight
	end
end

local function handleTagged(object)
	local hum = object.Parent
	if not hum or not hum:IsA('Humanoid') then warn(TAG .. ' objects must be parented to a Humanoid: ' .. object:GetFullName()) return end
	if not object:IsA('NumberValue') then warn(TAG .. ' objects must be a NumberValue: ' .. object:GetFullName()) return end
	
	local desiredHipHeight = object.Value
	correct(hum, desiredHipHeight)
	
	hum:GetPropertyChangedSignal('HipHeight'):Connect(function()
		correct(hum, desiredHipHeight)
	end)
end

local tagged = CollectionService:GetTagged(TAG)
for i = 1, #tagged do
	handleTagged(tagged[i])
end
CollectionService:GetInstanceAddedSignal(TAG):Connect(handleTagged)

The result was that, when the bug appeared on the server, HipHeight would remain at the level it is supposed to be, but on the client it would still be set to 0. If I selected that model on the client and set its HipHeight back to 2.3 (the value on the server) on the CLIENT ONLY, the NPC would get unstuck from the ground and start moving like normal.

Although this code reports every correction it makes from 0 (or a similar low HipHeight value) there were no corrections on the server; however, if I run this patch code on the client, hip height corrections do get reported and fixed on the client:

So I’m like 95% sure this is a StreamingEnabled-related bug, judging by the fact that most players don’t use StreamingEnabled in their games, and that this bug isn’t widely reported.

[RuizuKun_Dev (Kitsune)]

Sorry about your game being broken because of this Internal error.

I’m not an expert and I can’t be sure due to the lack of documentation however

Here’s some code to recalculate HipHeight:

@NoahWillCode

So, apparently for R15, hip height is the offset from the ground to the bottom of the HumanoidRootPart . So, the calculation is actually pretty simple. Here is a function to do this:

function recalculateHipHeight(character)
	local bottomOfHumanoidRootPart = character.HumanoidRootPart.Position.Y - (1/2 * character.HumanoidRootPart.Size.Y)
	local bottomOfFoot = character.LeftFoot.Position.Y - (1/2 * character.LeftFoot.Size.Y) -- Left or right. Chose left arbitrarily
	local newHipHeight = bottomOfHumanoidRootPart - bottomOfFoot

	local humanoid = character:FindFirstChildOfClass("Humanoid")
	humanoid.HipHeight = newHipHeight
end

My hypothesis is that due to the NPC being Client-side it won’t automatically set Humanoid.HipHeight, and Streaming doesn’t replicate that property, :l

I would assume that the engineers responsible of the new Streaming feature forgot to replicate Humanoid Properties properly?

Maybe you can try toggling AutomaticScallingEnabled on and off with a Script?

If it’s set to false and you load the characters manually it won’t set the HipHeight at all unless you turn it on then off.

Anyways, best of luck

[CodeWriter]

You can also call Humanoid:BuildRigFromAttachments() to recalculate the HipHeight (if you have AutomaticScalingEnabled), but that shouldn’t be need in the case of streaming since it should be called when new parts are added to a character.

Do the scripts in the game change AutomaticScalingEnabled? Is it turned off on the characters that are being affected by this?

[DataBrain (Amber)]

AutomaticScalingEnabled is true and remains true, according to that second screenshot, so I’m guessing it’s a conflict with streaming and the automatic calculation of HipHeight due to AutomaticScalingEnabled. The client streams in the character partially, and then calculates the HipHeight as 0, probably due to legs being streamed in early/late.

I’m assuming AutomaticScalingEnabled is on by default for every Humanoid object though? I have never messed with AutomaticScalingEnabled or HipHeight before encountering this bug, so it’s definitely not due to any of my code.

[CodeWriter]

Had anyone else seen a similar behavior with places that are Stream Enabled? Trying to narrow down possible causes to find the simplest test case to reproduce the issue.

[DataBrain (Amber)]

I managed to put together a repro in a highly contrived example, but my hypothesis appears to be correct, so I’m assuming this also applies to any StreamingEnabled game, and not just with NPCs but when players load each others’ characters impartially as well:

repro.rbxl (32.5 KB)

This place has three unanchored, stretched out characters with PlatformStand set to true so that they stay where they are placed.

It also has StreamingEnabled with the StreamingMinRadius and StreamingTargetRadius set to 10.

Lastly, to ensure that the client has say in calculating the HipHeight, I have a script in ServerScriptService that gives network ownership of each part in these dummies to the first player that joins the server:

When you first join, the upright dummy will load its parts in, and the Model/Humanoids of the other two will load in, with HipHeight set to 21.924 (as replicated from the server)

To reproduce this bug, simply walk up to the dummies until you see one dummy missing legs, and another dummy missing a torso/head (not streamed in yet). Dummy2 will load the HumanoidRootPart/Head before its legs load in, thus initiating a calculation of HipHeight for that client. This will be 0 for Dummy2 and 21.924 for Dummy3.

Finally, when you walk closer, until the legs of Dummy2 load in, HipHeight does not update after this point. on the client, so it remains at 0.

Meanwhile on the server, HipHeight is unaffected by this, so it seems to be a client-side issue only:

Seems like it’s an issue is that the client is trying to calculate HipHeight in the first place. Shouldn’t this always be server-authoritative? Makes me wonder if exploiters can glitch you into the ground at will by messing with your HipHeight if they ever get a moment of authority; seems like this also happens unintentionally without exploiters at all. I would suspect these user reports come from the fact that players are entering a popular location, and somehow entering the streaming purview of another player, and then briefly have their physics messed up by the other player, but maybe that’s a separate bug entirely. If there is a reason for HipHeight to be in any way client-authoritative, there needs to be some way for Humanoids to defer this calculation until that character is loaded in 100%, legs included. It seems like, instead, there is a single calculation event that occurs when the Head/HumanoidRootPart load in (since these are essential parts of a Humanoid’s character), while the legs being streamed in add nothing in consideration for the Humanoid’s calculation of HipHeight.

[PartHandler]

Having the same issue here within Studio. It’s definitely because of streaming enabled as the bug stops occurring after it’s turned off.

• The character has been applied with the default character package and size
• Setting the hipheight back will result in the character being in a looped freefalling animation
• Also falls in parts aside from just terrain

https://venyx.wtf/medias/fwxZls1L8s.mp4

[dragon_9086 (Sinister)]

So i have these 3 characters, all of them work fine except the noob one. First time you change to the noob it works fine but if you change to another character and go back to the noob he gets stuck in the floor

[JasonTheOwner]

If its some odd, occasional streaming glitch, maybe try spawning items in a two step method - first spawn near, but within the minimum radius in your streaming settings, to some arbitrary spot on your map (out of view of the players), but within that radius… then perhaps do the Humanoid:BuildRigFromAttachments() that @CodeWriter suggested, and then finally spawn the NPC to where you calculate it should be. … It’s just an idea.

[MrChickenRocket]

The ragdoll package you’re using has a bug in it

What you need to do is make sure your HumanoidRootPart has its collision enabled after spawning.

[DataBrain (Amber)]

Interesting… I didn’t even think about the ragdoll system. I’m not sure if this really is the sole cause, but it looks like @EchoReaper designed the ragdoll system I use to disable HumanoidRootPart collision while the rig has been built on the character, even while the ragdoll isn’t in use.

That being said, this bug is inconsistent enough for me that I don’t know the best way to test whether the ragdoll system was the cause, or if it was a StreamingEnabled issue.

[MrChickenRocket]

R15 / Rthro Ragdolls

I have the solution for the “Phase through object” bug. You need to disable/enable the collision on the humanoidRootPart when the ragdoll is active/deactive. It’s set to always disabled when the ragdoll is created, but this is not correct. function setRagdollEnabled(humanoid, isEnabled) ... local rootPart = humanoid.Parent:FindFirstChild("HumanoidRootPart") if rootPart then rootPart.CanCollide = not isEnabled end end

Should have just linked my other post on it

[uhi_o (HAT3UBERALLES)]

Been having the same issue. Solved it by setting the collisions between characters to InnerBox in game settings. But then there’s that issue where I don’t want players colliding into eachother. Tried a few other ways to disable collisions on characters but they all lead to that bug of the character freefalling on the ground.

It also occurs sometimes which is the worst part and never occurs in studio. So when play testing on studio I don’t get the bug, but on the actual game when spawning as character I get stuck almost 3/4 of the time.

Not sure about the streaming as I don’t have that enabled.

---

Edit: Found a workaround after all this time. Not the best, but it still works how I want it to.

Script workaround

Since this occurs while freefalling I check for freefalling then set their HipHeight to what it’s supposed to be. But sometimes that doesn’t fix it so I add an extra .5 then set it back. Might be better to place it in a .CharacterAdded event but I don’t have major issues on memory and I’m not too sure if it would work.

local function isFreefalling(char)
	local State = char.Humanoid:GetState()
	if State == Enum.HumanoidStateType.Dead or State == Enum.HumanoidStateType.Jumping then return end
	if State == Enum.HumanoidStateType.Freefall then return true end
	if char.Humanoid.FloorMaterial == Enum.Material.Air then return true end
end


while true do
	for _, v in ipairs(game.Players:GetPlayers()) do
		pcall(function()
			local Res = v.Character.HumanoidRootPart.Size.Y * 1.2

			if v.Character.Humanoid.HipHeight ~= Res then
				v.Character.Humanoid.HipHeight = Res
			end

			if isFreefalling(v.Character) then
				v.Character.Humanoid.HipHeight = Res + .5
				print('Was stuck, perhaps fixed.')
			end
		end)
	end
	wait(.1)
end

[cxmeels]

I’m also having this issue in my game if I set StarterPlayer.LoadCharacterAppearance to false. It only seems to happen in Studio the first time you spawn in; resetting seems to fix it.

In relation to this, I have Players.CharacterAutoLoads set to false, and am spawning and applying a HumanoidDescription to the players manually. Haven’t tested in a live game, as I will not publish my game with bugs like that.

[UnrelentingOwl (Owl)]

this issue is still ongoing after months, I myself and experiencing this too

[MagikTheWizard (MagikManz)]

This is still happening Weaponcraft [DEV] - Roblox
With streaming enabled, it seems to set the HipHeight of certain player’s characters to 0 on their client and they clip through the ground and slide.

[DevJanick]

The bug is still happening, only with Streaming Enabled our characters bug when spawning into them. The hipheight gets bugged, we tried even force hipheight and that doesn’t fix it.

We tried StreamingPauseMode on Default, ClientPhysicsPause and Disabled.

Example:

Here’s the game link but we disabled streaming enabled temporarily in the game. Sadly with streaming enabled disabled the game is often laggy for mobile players.

We also noticed that you get weird leg glitches with streaming enabled when morphing:

If there’s any more information required, let me know.

[AbstractAlex]

I tried copying & pasting a character into startercharacter yesterday, and it was permanently stuck sliding around the floor despite the hipheight being set.

It’s like Humanoids are storing some internal properties that devs can’t access

[IISato (Sato)]

Has this been fixed? Or is there a solution someone is able to script until its fixed?