It’s enabled in all live games
What determines whether or not the player is being involved in the physics solver? Also, is there a way to set a player to a simulated or non-simulated state?
1 Like
It’s determined by the HumanoidState, the RunningNoPhysics state means the humanoid is not being simulated in the solver.
Although a bit hacky, you might be able to use Humanoid.StateChanged event and Humanoid:ChangeState to keep it out of this state.
4 Likes
Adding a dev hub page for the impulses will make it more straight forward, though this is a great update to Roblox. I’ve been using it for a few days, and I can see how it makes builds much more flexible than the old system.
Any updates on this? I was applying this feature to my project just to realize this is an issue. Hope there’s news on this soon. This is an exciting feature nonetheless.
1 Like
Instead of doing :ApplyImpulse, I just set AssemblyLinearVelocity, works fine for me
I have noticed that AssemblyLinearVelocity and AssemblyAngularVelocity can’t be changed on any BasePart unless said object is a descendant of workspace. Is this intentional by any chance? I have only noticed this after switching from Velocity and RotVelocity to those.
The impulse-applying functions also don’t have any effect too.
1 Like
It wasn’t necessarily intentional, just that since the assembly doesn’t exist outside the workspace it wouldn’t make sense to have an assembly velocity. However I think we can change it to have the same behavior as the Velocty and RotVelocity properties for ease-of-use. The current behavior of those properties will let you set velocity on parts outside of workspace, but only the resulting root part of the assembly will take once in the workspace.
The impulse functions will only work on parts that are in the workspace.
2 Likes
Oh, that clears it! I was sort of confused about that, and this mostly resulted from me changing velocity-related properties in parts before I parent them to workspace.
To be honest, it’s not that much of a deal, but I guess it would be better if those properties could be changed outside of workspace.
Can someone explain to me how to use the new ApplyImpulse to fire projectiles? There’s absolutely zero documentation on any of these properties on the devhub
Here’s my velocity code:
Projectile.Velocity = Projectile.CFrame.LookVector * 200
Projectile.BodyForce.Force = Vector3.new(0, Projectile:GetMass() * 196.2, 0);
Here’s my ApplyImpulseAtPosition (it doesn’t work for ApplyImpulse either, and I’ve tried flipping the arguments)
Projectile:ApplyImpulseAtPosition(Projectile.Position, Projectile.CFrame.LookVector * 200)
Projectile.BodyForce.Force = Vector3.new(0, Projectile:GetMass() * 196.2, 0);
Anyone gotten something working? I’d like to avoid using Impulse from now on as ApplyImpulse is almost definitely better for performance but right now it’s pretty hard to figure out without any proper documentation.
Setting AssemblyLinearVelocity doesn’t work either.
I think I need more information to give you the best answer (what do you mean “not working”?), but there are some things I am noticing right away:
It looks like you have the arguments backwards for ApplyImpulseAtPosition. From the original post:
However, since it does look like you are attempting to apply it at the Projectile’s center of mass, all you need to use is ApplyImpulse.
Also, it looks like you are trying to use the same value you used for velocity, now with an impulse. These are different units, impulse is a force value, not a velocity. You probably need to use a much higher value.
I’m also questioning your BodyForce… do you have Workspace gravity set to 0?
Vector3 BasePart:GetVelocityAtPosition(Vector3 position) is now available to use!
As such, BasePart.Velocity and BasePart.RotVelocity are deprecated in favor of this function and the assembly velocity properties.
3 Likes
Wait, does this work on Humanoids yet? If not, what workarounds are there?
I want to use this to knockback players
It looks like you have the arguments backwards for
ApplyImpulseAtPosition. From the original post:
My bad, I just copy and pasted them the other way around but I tried both ways as well as trying with ApplyImpulse - it produces the same result, the projectile doesn’t move forward at all. Same thing happens when I use an absurdly high number.
As for the BodyForce, there’s probably a better way to use it but the 196.2 is used to simulate bullet drop, not every one has it. In this specific example there’s none but gravity isn’t set to 0 in workspace.
Here’s a screenshot (ignore the weird colors on it)
I’m assuming there’s more setup involved than with velocity but I’m not sure what exactly I need.
Thanks!
I think the best way would be to use newton’s first law. Just apply a force that would cause the assembly to stop. In general it’s best to avoid setting velocity directly.
2 Likes
I tried doing this both on the client and on the server, and I can’t get it to work.
currentCar.Weight:ApplyImpulse(-currentCar.Weight.AssemblyLinearVelocity)
currentCar.Weight:ApplyAngularImpulse(-currentCar.Weight.AssemblyAngularVelocity)
On the client it just flings the car.
https://gyazo.com/d4b1ce82e8acabf5c8c46c61aeb2c9e6
Should I be doing this another way?
Applying an impulse to a moving vehicle may not be an ideal way to stop it. This is all going to depend on how you are making the car move right now.
Also, ApplyImpulse takes a force value, as in force = mass * acceleration. It works in the same way that the VectorForce and Torque constraints work.
I suggest making a post in Scripting Support if you need more assistance.
Somehow I overlooked this😳
Thanks for your help, I managed to fix it
local fetchMass = function(model)
local total_mass = 0
for index, part in pairs(model:GetDescendants() ) do
if part:IsA("BasePart") then
total_mass += part.Mass
end
end
return total_mass
end
currentCar.Weight:ApplyImpulse(fetchMass(currentCar) * -currentCar.Weight.AssemblyLinearVelocity)
3 Likes
Could you post a reply here / in the update thread when this fix goes live? This bug has caused me quite a few headaches. 
1 Like