if you happen to create a sort of vector3 value for the player’s velocity and make the script setting the RP’s CFrame you can try to make it counteract this but i doubt it would work and it would be too janky in my opinion and exploiters can use this to their advantage if not properly used
what you can do is since the root part should have a velocity value you can use this to counteract this
I’m not sure if this’ll work, I think it would just be really jittery
since my wording is weird what i mean is when the walking/jumping script(s) set the velocity the script to align the HRP correctly to make the legs not clip can use the velocity value to calculate the new position but like you said it would be a little jittery
It’s a good idea however not sure if it’ll work, Ill make the other system later and tell you if it worked
ok also i gtg hope I helped or someone else helps
ill bookmark this post to check up on it later
multiply the HRP’s AssemblyLinearVelocity by Vector3.new(1,0,1)
if the character is on the ground.
Not sure how this would fix it, could you explain?
To improve what you can do is just have a HipHeight number/int value use the raycast idea that one person had and make it so the cframe of the HRP is the exact CFrame of itself (to reduce or eliminate jittering) but add the Y vector difference together
so for example the Cframe (without orientation so basically a vector but its an example ok)
HRP CFrame = 15, 0, 10
Distance from the floor = 5 (this would be a vector but this is the Y value)
HRP CFrame + Distance from the floor (and something to do with the hip height i cant really provide that rn)
Just fyi the performance of humanoids are not as bad as many believe they are. You can try messing around with physics based or custom physics but in the end the best option is just using humanoids.
If the concern is mainly performance, you can try disabling states that you won’t need, and also make sure the code itself that you are writing is optimized if it’s running at a high rate.
If the concern is usability, id take a look at the new movement controllers by Roblox. They open up a lot of possiblities, and its all done for you.
Alright, thanks for the help btw!
No problem, hope my advice works! (And if not I hope you can find help)
It’s not just for performance, It’s also because I want to add less control when the player is in the air. I’ve tried to use movement controllers already however it was way more effective than I wanted
It fixes the velocity since it multiplies their Y velocity by 0 when they are on the ground in a frame before/after simulation. AssemblyLinearVelocity
…I was thinking: call raycast to determine the floor position in PreSimulation. Then in PostSimulation, get the position of the HRP and determine if it is less than the min height or not. If it is below the minimum height:
HRP.AssemblyLinearVelocity *= Vector3.new(1,0,1)
and set HRP y position to minimum height.
Otherwise leave it be.
- for your understanding, Roblox will call frame events like PreSimulation and then PostSimulation before rendering the frame.
So if a position is up and then down and then back up again, the result of those calculations are only rendered at the end.
For precise frame control, see BindToRenderStep
This works! However for some reason I’m able to run up walls, and when I reach the ledge I just get flung. I feel like this isn’t because of the part but because of the way I handle the velocity, I’m going to attempt to fix it but not sure how I could change it.
- Get the height that the root part is supposed to be in.
- Raycast downwards, and if it hits something, then figure out the height from there. I’m assuming you have this part down.
- Your next problem is keeping the root part at that height while maintaining momentum.
- Using AlignPosition:
- This is only enabled when on ground.
- Set the
AlignmentMode
toOneAttachment
- Set
ApplyAtCenterOfMass
totrue
- Set
RigidityEnabled
tofalse
- Set the
ForceRelativeTo
toWorld
- Set the
ForceLimitMode
toPerAxis
- Set the
MaxAxesForce
to(0, MAX_UP_FORCE, 0)
, whereMAX_UP_FORCE
is the maximum amount of force you want your rig to use when keeping itself above the ground. The X/Z forces are 0 so it will never apply any force along the horizontal plane, so any typical movement velocity would be preserved. - Every frame, set the position to the world position of the raycast + however much distance you need it off the ground. If it’s an R6 rig, this is usually
RaycastResult.Position + Vector3.new(0,3,0)
. If not on ground, just disable it.
- Using AlignPosition:
That should be about it for most normal physics-based rigs.
Now there’s another way to do this if you’re dead set on customizing all the physics yourself, by running code per frame… do this only if you know what you’re doing.
- Manually modifying the part’s
CFrame
andAssemblyLinearVelocity
:- If grounded, you wanna kill off all the root’s vertical velocity while slowly pushing it upwards.
- Idk how you plan to do this, but if it was me I’d do this every frame:
- Check if on ground (raycast down)
- If on ground, then lerp the root part upwards to where it should be when standing
- Have an
antiGravity
VectorForce
set to(0, assemblyMass * workspace.Gravity, 0)
to cancel out gravity enabled when on ground. Makes no sense to have gravity affect the player if you’re supposed to be standing on ground. - While doing that, do:
local currentVelocity = RootPart.AssemblyLinearVelocity
RootPart.AssemblyLinearVelocity = Vector3.new(
currentVelocity.X,
0,
currentVelocity.Z,
)
This preserves horizontal momentum while stopping any vertical velocity and counteracting gravity that runs in the physics frames between script frames.
This is the same as
RootPart.AssemblyLinearVelocity *= Vector3.new(1,0,1)
Guess I’ll try this now with the given properties