There’s a reason I’m posting: I want to make my own gravity thing and not use another module - otherwise I’d just use it without posting. Every post I come across the forum regarding this topic has the egomoose module marked as the answer and that kind of irritates me.
Hello there,
I’ve been recently working on a planetary game. My goal is simple - to make players be able to walk around the planets.
For the planet gravity part, it seems to be working, with workspace.Gravity being 0 and applying forces on the character to simulate gravity, so that shouldnt be an issue for orientation.
But, Humanoids have a built in PID controller that automatically ragdolls them on angles above 89 degrees (MaxSlopeAngle)
I was looking to somehow not end up making a custom character controller. I have almost finished one, but the controls are kind of buggy when you press two or more keys together.
I’ve seen some controllers do this - while trying to unwrap a module, I found this:
They have 2 parts - a sphere and a block inside the character. Inside the HRP they have a bodygyro and a vector force.
I couldn’t figure out what the parts and the force were doing - but it is certain that the orientation is being handled by the bodygyro.
I’m curious to how this behavior is achieved while still having a humanoid object in the character.
Please recommend anything that you might think is viable.
What I have tried:
(With raycasts to find the surface normal)
I tried to change the root Motor6D but that bugs out the meshes and doesn’t change the move direction of the humanoid to where its facing, but that makes sense as the change is just visual and the HRP isnt being affected. I’m willing to show code if needed, but I don’t think the method would work due to the above issue.
Use a bodygyro for orientation, but its stutters as the humanoid tries to upright itself.
Use AlignOrientation - prevents uprighting but still makes it ragdoll after 89 degrees.
I’m not asking for code - just what you will use or do to make such a thing.
I’m actually confused as to what you are trying to do. The title asks what’s the best way to make players walk around spheres, but then in the post you’re talking about gravity, force vectors, and the like. Is there a baseplate that the players walk on? Since you mentioned that gravity is 0 in the workspace, I am assuming not.
So, making a number of assumptions, it sounds like you need a fly module.
That’s the video that I used to make my flying module. Then I modified it for my purposes.
I want to make the players basically walk around a sphere planet. I was talking about gravity just so that people dont confuse the glitch being due to the workspace gravity. I dont need a flying module, I just want a player to walk around a sphere. Thats it… Im sorry for not being able to keep it straight, just wanted to give all info i got.
What is the player walking on when they walk around a planet? They have to walk on something or they are flying. If they are walking on nothing and you want to simulate walking, I guess you could use the information in the video to make a fly script, use the walk animation instead of the swim animation, and use an AlignOrientation constraint to keep the player vertical.
Wait…are you talking about a player walking ON A SPHERE? If that’s the case, then you need a VectorForce and AlignOrientation to point the player to the middle of the sphere. Then you need to use runService.RenderStepped to generate the new orientation. Basically, you are going to use the angles between the player position and the center position of the sphere.
There is some really complicated, Calculus level math involved in pulling this off. But it’s doable.
I didnt want any module to use. I wanted to make my own system. I think i have clarified this in the starting lines of the post.
I’m pretty sure I said “Read this” more as you could take some lines of that code or get some help for it, seeing other codes similar to what you’re trying to make could help you make it. They’ve been in a similar situation when making their code, so try to see what they’ve done about each thing. It might not be the same script, but you could easily see what they’ve done and just do something similar.
What you said here is right, I have achieved this behavior already. But, humanoids will automatically enter a ragdoll state as soon as they are tilted above an angle of 89 degrees. So when the player goes towards the equator of the planet, the angle gets closer to 89 and as soon as it reaches a ragdoll state is entered, preventing the player from moving.
It uses a lot of deprecated methods and dates to 2017. I did read the module but I didnt see any lines of code actually indicating how a bodygyro was able to override the humanoid pid controller.
You might want to play with the StarterPlayer.CharacterMaxSlopeAngle setting. It sets the Humanoid.MaxSlopeAngle when the character spawns, which is what I think you want.
[EDIT]
I was reading it, and found that it’s clamped to between 0° and 89°, inclusive. But that’s what you need to control it. The default is already 89°.
Can you post a video showing what’s going on? It might be an engine bug.
Yeah ill get it on video. Its not an engine bug, rather a limitation.
You can see how when I rotate it past a certain angle it sinks into the ground. When doing on a player object, this will sink them into the ground and not allow any movements (kind of like anchoring the player).
This “certain” angle is MaxSlopeAngle, the angle beneath which humanoids would enter a ragdoll stage and lose controls.
TL;DR: The answer is that it does not override the humanoid PID controller it disables the humanoid states. It also has a custom state system.
Here is how I reversed engineered it.
Movement is done locally so I looked in starter player scripts.
there is the centralized loader script following single script architecture which is neat.
Looking through I found the function
local function EnableGravityDrive(enable)
if not gravityDrive then
warn("Raven EnableGravityDrive called before gravityDrive instantiated")
return
end
activeCameraController = CameraModule:GetActiveCameraController()
if enable then
gravityDrive:Enable(true, activeCameraController)
ControlModule:RegisterMoveFunction(function(player, moveVector, cameraRelative)
gravityDrive:Move(moveVector,cameraRelative)
end)
Looking through the gravity drive module I found no code related to humanoid platform stand or state management.
Then I looked through the character module parented under the gravity drive module.
Bingo.
Humanoid is disabled to physics or platform stand.
function CharacterModule:SwitchHumanoid(normalMode)
--print("CharacterModule:SwitchHumanoid: ",(normalMode and "Normal Mode" or "Gravity Mode"))
--[[ Disable nearly all humanoid states for GravityDrive, enable for Normal Roblox behavior ]]--
-- The only state we need is Physics or PlatformStanding for GravityDrive mode (doesn't currently seem to matter which)
self.humanoid:SetStateEnabled(Enum.HumanoidStateType.Physics, true)
Wait, so humanoid’s functionality/behavior is completely disabled due to the physics state right? Because that’s what happened when I changed states to physics. If so, how do they make the player move around? Using a custom function?
Yes. They use a vector force. With the fly module, the humanoid state is physics while flying, so the VectorForce and AlignOrientation become important. So, once again, you are looking for a fly module because that’s what you need to control the humanoid without the default controller while in the physics state.
Yeah, but then I basically have to make my own control module too to move the player with a vector force. That doesn’t satisfy the question of retaining controls though.
For future readers: There’s no way to do this while still retaining controls, so you have to make your own controller (way easier than trying this considering that this is impossible).
I’ll be making my own too because I’ve given up on this.
This will be marked as solution because there is not an answer to this problem, and thank you everybody on the thread devoting their time towards helping me out. Have a good day.
