Occurs on the latest version of Roblox. This can also be reproduced in Roblox Studio. It is likely something related to physics, avatars, humanoids, and collisions.
Reproduction Steps
Enter Roblox Studio on the “Baseplate” template
Raise the SpawnLocation slightly off the ground
Create an R15 NPC using the Animation Editor plugin (or just use your own player character), set the HRP’s CanCollide to false
Enter Play mode
Use the move dragger to drag your NPC or player character onto the SpawnLocation
Use the move dragger to drag your NPC or player character slightly into the SpawnLocation(about halfway)
Observe the NPC/player character enters an awkward sliding state and is catapulted off
More Repros
Falling
Fall from a high height (~16-32 studs)
Observe that occasionally you enter the floor and are flung out. You sometimes even get stuck inside the floor in a falling state until you reset.
This is more easily reproducible if you double or halve the player’s scale, but this happens on every avatar scaling size.
Jumping
Jump in the direction of a platform
Land in such a way that your torso barely lands on the edge
Observe the humanoid enters an awkward sliding state and is catapulted off
High Velocity
Fling your character (via a force constraint or BodyForce) into a platform
Land in such a way that your torso barely lands on the edge
Observe the humanoid enters an awkward sliding state and is catapulted off
This is more easily reproducible if you use lower gravity, but it happens in every experience regardless.
Related Bugs
These bugs likely compound this bug, but all are somewhat different.
Expected Behavior
The player lands normally. They do not sink into the ground and get flung. They do not slide on the ground until they fall off the edge of a platform.
Actual Behavior
If falling from a long height, there is an uncommon chance that the player is flung in a random direction.
If jumping into or from the edge of a platform, there is an almost guaranteed chance that the player slides off the structure or gets stuck in a permanent sliding state.
Workaround
N/A
Issue Area: Engine Issue Type: Other Impact: High Frequency: Constantly Date First Experienced: 2021-08-08 00:08:00 (-04:00) Date Last Experienced: 2021-10-03 00:10:00 (-04:00)
I included that it was possible they were related, but this still occurs when the HRP’s CanCollide is set to false. If the real issue is about the Humanoid and HipHeight, then it is indeed likely that these threads should be combined and renamed. I don’t feel as though I can make that call, hence why I opted for a separate thread.
The first and third video are definitely Humanoid’s “my butt is caught on a corner” panic mode. Middle video is likely caused by this too.
Replied on the older thread for reference too:
Makes sense that this might happen more frequently at lower frame rates too… Humanoid floor sensor currently only steps once per frame in humanoid state machine step, so longer frames and higher velocity = more time for root part to collide during freefall before it realizes it should be standing. If I step through the video I see the character’s legs fully submerged in the ground for a frame, so I think this is what is happening. Humanoid floor sensor is supposed to increase its range when velocity is high, so I’m not sure why that isn’t helping there, we should look into that.
What’s happening in the first repro is the Humanoid is getting the spawn part stuck between the different torso parts trying to resolve the collision in different directions. Stuck in freefall, Humanoid sees something touching its butt, freaks out, and tries to panic slide out of there. I’m not sure what your platforms look like collision wise, or how your dash move works, but something like this may be happening in the last video too.
You can easily fix that one by disabling collisions on all parts except the HumanoidRootPart, that way it can’t get stuck in a conflicting collision trap. This general “caught between two collisions” problem is continually on our minds, but will take us a long time to fix.
Appreciate your detailed thoughts on what this issue is and what may be causing it!
For context, what would happen without the panic slide state? Would the player get stuck in the structure with no chance of escape?
As for the platform and dash logic, the platform is wedges and parts - no real gimmicks there. The dash logic is setting the HumanoidRootPart’s velocity (on the client) to a high enough number to push them in the direction you’re looking in. It works consistently. I can supply a repro if it would help you identify and solve this.
Would you have a recommendation on the most performant way to properly set avatar collisions for your proposed fix? IIRC the Humanoid will automatically set the limbs back to a default collision state, meaning I would have to constantly set the limbs to CanCollide false.
The humanoid floor sensor currently fires a few raycasts in a line in front of the humanoid, from the center of the humanoid, and from the bottom four corners of the root part. If it can’t find a floor the Humanoid goes into freefall. Of course no amount of raycasts are guaranteed to find a floor under you in all situations…
In a situation like this all those raycasts will miss and the Humanoid is stuck in freefall. You might be able to slide around with air control, but it looks obviously wrong. These panic forces will automatically slide the Humanoid off of that corner and allow it to fall freely, likely without you noticing the character was stuck.
If the floor sensor used shapecasts instead we wouldn’t need this, since it would never fail to find a floor that it could get stuck on. You need some kind of volume here to guarantee you won’t miss things. Unfortunately we don’t have shapecasts yet, so until then we have this workaround. Shapecasts are something we’re working on, but it won’t be ready until sometime next year, best case…
Re: avatar collisions. Set Workspace.HumanoidOnlySetCollisionsOnStateChange to Enabled.
Then you only need to set CanCollide in Humanoid.StateChanged instead of every frame.
Sorry. I know this stuff is a little weird and hard to work around sometimes. Let me know if you keep having trouble after simplifying collisions.
If you are able to make a consistent minimal repro for the middle video would be happy to look into that more. Are you using higher than default gravity in that one?
Thank you! I really appreciate the detailed explanations. I’ll give a try with modifying the collisions with these considerations and get back to you if I run into any issues.
I’ve also sent you a DM with a place file for the middle video. The default gravity is unchanged, however the player is half of their normal size. This bug still occurs even without the smaller player scale, but it occurs way more frequently and obviously. Lower FPS also intensifies these bugs, including the middle bug.
So I applied your hypothesis, seems to check out! I decided to go for a physics-based approach at solving it, as I figured that was why R6 did not experience this bug.
This workaround works pretty well
game:GetService("Players").PlayerAdded:Connect(function(player)
player.CharacterAdded:Connect(function(character)
local humanoid: Humanoid = character:WaitForChild("Humanoid", 8)
local limbs = {character:WaitForChild("RightUpperLeg", 8), character:WaitForChild("LeftUpperLeg", 8)}
if humanoid then
humanoid.StateChanged:Connect(function(oldState, newState)
if newState == Enum.HumanoidStateType.Freefall then
for _, limb in pairs(limbs) do
limb.CanCollide = true
end
print("Legs on")
else
for _, limb in pairs(limbs) do
limb.CanCollide = false
end
print("Legs off")
end
end)
end
end)
end)
Will need to clean it up, fine-tune it, and optimize - but it reduces the occurrence of this bug by a large margin with no notable downsides.
It still frequently occurs if you go straight from the “Running” to “Landed” state unfortunately. Not sure how to work around that.
