I’m really liking the :GetVelocityAtPosition
. This could mean that things such as launching projectiles and whatnot can be easily read from when trying to calculate how much damage a player should take based on velocity when the “mortar ball” hits the player.
Oh I get that, my point was mainly why have both that do the same. But now that I know :GetRootPart()
might be deprecated in the future, I see why they introduced the property. And I agree with it being easier to find.
This look great, I’ll definitely experiment in a bit! Question: what happens when applying impulses over a network? (e.g a server applies an impulse to a part with a client network owner)
The reason I ask is that setting the velocity of a part from the server with client ownership is unreliable, and therefore considered a bad practice.
I’ve actually just tested this and it acts the same as if you set the Velocity property directly. In other words it doesn’t do anything if you don’t have network ownership.
Question: For the Position arguments in each of the methods, are those relative to the world or the root part?
Really liking this update. This’ll clean up some of my code
How will scripts using Velocity and RotVelocity work? will they still be supported as long as possible despite deprecation? because conveyors use Velocity, and i know a game that uses Velocity and RotVelocity alot, so it would be nice if both the new stuff and the already existing stuff were supported.
Hello everyone my apologies but this is causing some new studio crashes. We need to disable this until the bug has been resolved!
EDIT: No more releases this year - check back in January!
This is so cool! Really removes a lot of cases where you have to do odd workarounds and makes the physics engine feel much more… complete?
You can now do a lot of things without making & destroying an object. Stuff like jump pads, punching objects with knockback, making a domino fall over, etc.
Awesome! This will all be extremely useful for my game (which uses the physics engine + body movers to simulate flight) and I look forward to making the switch. Currently, I had to go through a bunch of hoops to get desirable behaviour; this should simplify a lot of mechanics in my game (as well as introduce some new ones)!
I only ask that while deprecated, the Velocity properties are not removed. I know this is probably what you mean by “deprecated” anyway, but just so that our needs are clear; those properties are useful (when doing some tricks), and I will without doubt forget to switch over to assembly velocity at least somewhere in my code base.
Hype!
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!
Finnaly. i waited so long for this to get fixed. I am getting so confused by the old behaviour.
Is there any idea on when this will be re-enabled again?
Whats the targetted date?
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.
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!!
Welp ima have to rewrite my ant exploit now because deprecating RotVelocity and Velocity
My man he literally said ETA one week.
Will it be possible now to get the velocity of an object that’s anchored if its being moved via CFrame etc?
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.
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.