While experimenting with a Linear Velocity, I found a strange things that I can’t explain to myself.
First one:
When you put Linear Velocity into random part in your workspace, it will be still affected by physics: let’s imagine it’s is going right with velocity and there’s a cliff. The part will fall down.
When you put Linear Velocity into HumanoidRootPart of a character from that moment it’s not affected by game physics. Even if you put no velocity ( (0; 0; 0) vector ) and enable it while your character is not on the floor, it will immediately freeze it in the sky. You won’t be able to move with WASD and so on.
Why it doesn’t work the same?
Second one:
How can I get the second one behaviour in the first case?
I turned off ForceLimitsEnabled and even with that part is affected by phisycs: I move it right with velocity and it starts to spin: seems like even without a limit I can’t fully ignore physics…
HumanoidRootPart is controlled by the Humanoid, which overrides Roblox’s physics like gravity, making it unaffected by other forces when LinearVelocity is applied. Normal parts on the other hand are fully influenced by physics unless you disable gravity and other forces using properties like Anchored, CustomPhysicalProperties, or BodyPosition.
To replicate this behavior, I believe you could like, combine LinearVelocity with BodyPosition to control movement while preventing Roblox’s physics interactions
I don’t get it. When I change the gravity, it affects all humanoids, for example. You said it like gravity disappears at all and the humanoid itself controls the physics of all parts of characters and changes the CFrame of each part.
The reason a LinearVelocity on a HumanoidRootPart can “freeze” the character mid-air is not because gravity disappears, that’s really not what I meant, it’s because of how the character controllers work in Roblox
When you add a LinearVelocity to a character’s HumanoidRootPart then you’re basically interfering with the built-in movement and physics logic of the Humanoid. It acts like a physics override, as so even if gravity exists, the character stays frozen because Roblox’s physics treats it differently
If you add LinearVelocity to a normal part, Roblox doesn’t treat it specially because it is just a physics object, gravity is still going to apply normally
Humanoid will perform a raycast towards the ground, and as soon as it hits the ground it will set the HRP to be 2 studs above it. LinearVelocity also overrides existing velocity, but the Humanoid still controls the rotation. Humanoid doesn’t touch velocity or positioning except for the ground repositioning.
Does it mean that it’s impossible to add Linear Velocity without overriding it?
For example, add Look Vector Linear Velocity to a player that jumped and enable it until the moment when the player landed. It will be a long jump. It was my idea in the beginning.
Yes it IS possible to use LinearVelocity to make a player perform a long jump without freezing them mid-air, you just have to attach it to the HumanoidRootPart then set VectorVelocity to their LookVector * speed and then use RelativeTo = World, and only enable it while they’re airborne, then disable it when they land so gravity and Roblox’s physics still apply
But as we discussed before, it totally blocks the movement of a character, so it won’t work – you will be in the sky forever. I put (0; 0; 0) as an example, but any other vector also will still block the character in the sky.
local player = game:GetService('Players').LocalPlayer
local character = player.Character or player.CharacterAdded:Wait()
local humanoid = character:WaitForChild("Humanoid")
local velocity = Instance.new("LinearVelocity", character)
velocity.MaxForce = 10000
velocity.Enabled = false
local attachment = Instance.new("Attachment", character.HumanoidRootPart)
velocity.Attachment0 = attachment
stateConnection = humanoid.StateChanged:Connect(function(oldState, newState)
if (newState == Enum.HumanoidStateType.Jumping) then
velocity.VectorVelocity = character.HumanoidRootPart.CFrame.LookVector * 10
velocity.Enabled = true
end
if (newState == Enum.HumanoidStateType.Landed) then
velocity.Enabled = false
end
end)
No he’s saying change the mode to VectorVelocity XZ or 1,0,0 and 0,0,1 for the axes (I don’t what is looks like).
And then use the LookVector to determine the Vector2 value.
That way it does not effect the height (Y value)
The problem with that is that is non-linear. In cinematics when you throw an object, it has a constant vector that affect the object on surface xOz, that’s why I wanted to use Linear Velocity.
LinearVelocity DOES apply a constant force, so it should create a straight-line motion on the xOz plane. The issue here is that the Attachment is in the character’s HumanoidRootPart, which moves with the character and can cause unwanted effects
Try setting velocity.RelativeTo = Enum.ActuatorRelativeTo.World so the direction stays constant, and ensure LinearVelocity isn’t being overridden by other forces like Humanoid movement or PlatformStand, you might also need to set PlatformStand = true during the jump to fully prevent interference
Platform Stand disables the default character movement controls, allowing the character to be unaffected by forces like gravity or walking, which can interfere with custom physics. When PlatformStand is enabled, the character won’t respond to player input, making it easier to apply custom movement forces, like LinearVelocity, without them being overridden by the humanoid’s normal behavior as without it the humanoid can override or conflict with the velocity you’re trying to apply
If we talk about ragdoll, I get your point. But with Platform Stand my character turns into a brick, why would I want to use it? I can turn off controls instead and get standard behaviour, but without player’s input.
Yes PlatformStand is useful when you want full physics control (like for ragdolls as you mentioned) but it’s overkill for things like long jumps because it completely disables character movement and animations making your character act like a brick. If you just want to keep normal humanoid physics but stop user input then it’s just better to disable controls manually (like using ContextActionService) because that way you keep natural behavior like gravity or collisions or animations without the player interfering