This is great - the ability to apply an impulse is huge for game development and was always a much-needed feature on Roblox. There will be so many applications to this, and now everyone’s physics code can be much cleaner. Huge step in the right direction, so thank you to everyone involved!
2 Likes
Finnaly. i waited so long for this to get fixed. I am getting so confused by the old behaviour.
1 Like
Is there any idea on when this will be re-enabled again?
Whats the targetted date?
3 Likes
An ETA would be greatly appreciated on this please.
My team has already implemented a feature relying on this API and that is now broken until you flip that Flag again. We were not experiencing Studio crashes so this is creating an inconvenience for us by disrupting our workflow.
Maybe we shouldn’t be so eager and early at adopting new Roblox features.
4 Likes
Haven’t been able to try this out yet. Does this resolve the issue with humanoid velocity? Previously setting the Velocity property on a humanoidrootpart did not give the intended impulse effect. Does using the new functions work properly with humanoids?
But otherwise cheers this is great!!
2 Likes
Welp ima have to rewrite my ant exploit now because deprecating RotVelocity and Velocity
3 Likes
My man he literally said ETA one week.
2 Likes
Will it be possible now to get the velocity of an object that’s anchored if its being moved via CFrame etc?
1 Like
Why would an anchored part have a velocity? Anchoring a part indicates that the part should not be influenced by physics; it is supposed to be stationary and cannot be acted on by an external force.
Also, moving parts by adjusting their CFrame values isn’t physics-based motion, it’s just a long chain of short-distance teleports. That has nothing to do with the upcoming properties.
1 Like
I know that, but im currently working on a game that uses cframe to move characters however i need some velocity to do certain things with them. Ive tried multiple things to get the velocity but it doesnt work.
I was just hoping this could make that possible.
1 Like
Alright, well, expecting new physics properties to help you is a pipe dream, to say the least.
This is probably out of the scope of this thread, but if you need the effective velocity of whatever you’re moving, then I can think of two ways to go about it:
-
If the parts are being moved at a constant rate, then you already have the numbers you need to calculate the velocity since you’re the one defining how far the part is moving and for how long.
-
Else, you could just have a function bound to
RunService.Heartbeat(see here) that keeps track of the position of the part you’re moving. Use thestepvalue thatHeartbeatsends into your function to help you calculate the velocity.
1 Like
If you’re moving the parts via CFrame changes, then you already know the velocity! The velocity is whatever you’re adding to the position when you update the CFrame multiplied by the frequency with which you’re doing the CFrame updates.
So you’ll just have to calculate the velocity via that method, and store it somewhere where the code that needs to know the velocity can read it. Unfortunately the physics engine can’t do anything to help in that regard, because it runs at a higher rate than script logic, and is just seeing jerky instantaneous movements, not smooth simulation.
8 Likes
When will the force application functions be available? And yes, this is wonderful for projectiles and vehicles where precise and accurate control of forces will be necessary. It would also be wonderful to be able to GET impulse data as well, useful in detecting things such as vehicle damage when either you collide with a wall, or a car collides into you. Both change the vehicles momentum but in different ways with different reactions, making it difficult to estimate just by checking changes in velocity. Would be great if like Touched, there was an event to get a contact point and the impulse force applied, along with the momentum of the object that collided so you could see if it was absorbed.
1 Like
Do you have an update for us yet?
2 Likes
I have a feeling that this may break some scripts that uses BasePart.(Rot)Velocity. Will using these legacy properties automatically set the newer properties?
EXAMPLE: Velocity will set AssemblyLinearVelocity and RotVelocity will set AssemblyAngularVelocity instead.
2 Likes
You’ll most likely have to manually go through your scripts and reconfigure them to this new operation. That’s the reason why the staff tells us about these things, so we can prepare our scripts for a future update the staff puts out.
Scripts will definitely be broken once BasePart.Velocity and BasePart.RotVelocity are fully deprecated, but I don’t think they’re going to be deprecated right after this release. (They’ll just have the status of ‘deprecating’ so other developers won’t utilize it anymore.)
They usually make a separate post talking about deprecating certain operations and functions from Lua, so I wouldn’t worry too much yet. But I would definitely keep an ear out.
I was corrected by one of the staff members that took the time to answer any questions or misconceptions so I’ll leave it to you to read their response.
1 Like
Unfortunately there were some unrelated issues with this weeks release, and I won’t be able to re-enable this feature. There are no more releases this year so we will need to wait until January. Thanks for your patience.
I’ll answer the latest questions about the new API in my next reply
9 Likes
Position is in world space!
Scripts will only be able to apply an impulse to parts that it owns. A client can only apply an impulse to parts owned by that client, you’d need to use RemoveEvent/Function otherwise.
This is an issue with humanoids, not the velocity properties. So applying an impulse will not make a difference in this case.
However, we will be solving this on the humanoid side next year.
No, anchored parts have no velocity. If you are updating its CFrame every frame, then you already know the “velocity”, it’s just the rate you are changing its position.
Yes this stuff would be nice, maybe one day 
. The upcoming GetVelocityAtPosition function should help with a lot of this though.
No, this is not true. We would never cause old scripts to break by removing a frequently used property. Deprecation does not mean deleted, it just means there is a better replacement you should use for all future work. In this case, they will be hidden from the Property window and not show up in auto-complete.
15 Likes
Thank you for responding and correcting me. I just assumed that you guys wouldn’t go through all the trouble of doing that. I will edit my comment accordingly.
3 Likes