BasePart.Acceleration Property

Feature Requests Engine Features
#1

As a Roblox developer, it is currently too hard to apply accelerations to a part efficiently and cleanly.

If Roblox is able to address this issue, it would improve my development experience because it allows for an easy way to apply forces to parts, change the effects and direction of gravity on a specific part, and create much cleaner physics code.

Here is are some brief summaries of the reasons I think that Acceleration is an important addition to Roblox:

Exploration

With the introduction of an Acceleration property the forces applied by gravity, BodyMovers and the new Constraints system may become exposed. This allows for developers to explore how these forces act on their creations and perform calculations which would not be possible without knowing a part’s Acceleration.

Less clutter & lower performance costs

This property would also reduce the need to create, cleanup, and manage BodyForces for hundreds of parts. It would also make it needless for players to implement their own acceleration code in a Heartbeat event and would allow script performance to be improved when multiple scripts need to accelerate a part. This also comes with the added bonus of requiring slightly less memory usage for these instances.

More intuitive & welcoming

Newer developers arriving on the platform may take much longer to discover and learn BodyForces. With the introduction of an Acceleration property, new developers will be exposed much quicker when they first start learning about Position and Velocity. There’s no need for them to do Google searches to figure out how to apply force to an object and it’s not piled into the hundreds of instances that Roblox has to offer.

This also means that new developers can apply concepts they learn(ed) in school to Roblox much faster and come up with new and creative ideas while Roblox is still fresh to them.

Applications to anticheat development

When it comes to developing an anticheat, having this information exposed to the developer allows them to more accurately predict the movement of players. If a player’s acceleration is known, the developer can prevent them from modifying their velocity. Since it can be written to by the developer, the developer now has full control over the player’s movements from the server and can ensure the player does not perform unwanted movements such as jumping abnormally high, falling too fast, changing their gravity, and other things.

Smaller Code

When implementing physics in games which require acceleration like forces scripts often get cluttered. This allows developers to more cleanly write their code:

-- Without an Acceleration property
local RunService = game:GetService("RunService") -- Get the RunService to make sure a force is applied
local bodyForce = target:FindFirstChildOfClass("BodyForce") or Instance.new("BodyForce") -- Create a body force if there needs to be one
bodyForce.Force = bodyForce.Force + force -- Apply the force
bodyForce.Parent = target -- Parent it
RunService.Heartbeat:Wait() -- Make sure it's applied
bodyForce.Force = bodyForce.Force - force -- Cleanup

-- With an Acceleration property
target.Force = target.Force + force
10 Likes
#2

I think that this should be done using a new body mover Instance called “BodyAcceleration”. Adding yet another property to the BaseParts will only clutter the class and having it done with a separate instance will allow us to change other advanced properties such as maximum force on individual axis or make it relative to a point in the world.

#3

This gets a bit tricky because acceleration on a body cannot necessarily be described with a single Vector3. For instance, if a revolving door is starting to spin faster, then its acceleration at the ends will be more than the acceleration at the hinge point.

1 Like
#4

I’m defining this as the acceleration of the center of the part. This is similar to how velocity can be different when a part is rotating. Maybe a RotAcceletation might be good as well?

Also, @nooneisback, having this as an instance is redundant since we already have BodyForce and F = ma. Not to mention this gets rid of all of the benefits I listed in my thread thus defeating the purpose. I don’t think that property clutter is an issue here. It doesn’t make sense that this should be locked behind independent Instances. Not to mention the performance costs I mentioned of creating and destroying hundreds of Instances.

2 Likes
#5

What do you mean by “locked”? Having this as a part of BasePart’s properties would be an actual lock that limits the actual use cases.

BodyMovers convert whatever value they are working with to a directional or angular force. BodyVelocity attempts to keep a constant velocity using a maximum force and BodyPosition tries to keep a part still.

As you said, F = m*a, which also means that a = F/m. So what’s with this force? Should it be 1 or 10 or 100 or even inf? You need to be able to define the maximum force a part can accelerate with, unless you want it to faze through every wall and fling everything into oblivion.

In other words, making this actually useful would require a MaxAccelerationForce and a MaxRotAccelerationForce property. What about applying an acceleration at a corner? Body movers have Attachments, but this won’t. What you are proposing makes no sense. The sheer amount of new properties that would have to be added to make this an actual useful property are plentiful enough to have an instance of their own.

Also, what about having the acceleration set to 0? A free falling part has an acceleration of around -190 in Roblox. Setting the acceleration to 0,0,0 will force the part immobile. An AccelerationEnabled and RotAccelerationEnabled property would be required as well.

4 Likes
#6

You can apply acceleration with a BodyForce using the formula already. That was my point. Having a new BodyMover which doesn’t give you any new use is redundant.

You don’t need maximum force, acceleration, etc properties. Acceleration would be set to zero at the beginning of a physics step and any accelerations applied internally are applied to the property instead. That means gravity will always be a part of the Acceleration property and forces applied by BodyMovers are applied to the Acceleration property. Velocity can change independently of Acceleration. The Acceleration property works exactly like Velocity already does but instead of effecting Position it effects Velocity.

Unlike Velocity, Acceleration doesn’t have a “momentum.” That’s why Acceleration can be set to 0 each step and forces and accelerations are applied internally. If acceleration was applied and not reset you would run into issues.

Without using the Acceleration property yourself all physics would remain the same. When setting acceleration it will immediately be reset on the next step after it is applied. That means the velocity will increase by the acceleration once before it is reset.

If you want to apply Acceleration per step you use Heartbeat, just like how you apply a Velocity, and just like how you implement custom Acceleration. The reasons for merging it into one property instead of relying on developers to implement their own Acceleration are discussed in my post.

The only function difference between the two is you can modify and use accelerations applied internally.

1 Like
#7

You can use the BodyForce, but you would have to change the force in case you add/remove mass. This is the main use I see, maintaining constant acceleration which is stable physics wise with variable mass. Using this, you can easily add artificial gravity.

I really don’t see a single use-case for your request though. Nearly no customization, questionable stability and I really don’t see any part of this being “simple”. Literally the only way to use your “simple” acceleration is to apply it each frame, something which is obviously not a good idea on a large scale.

How is applying something each frame because of the way it internally works in any way friendly to new users? Applying velocity each frame to keep it constant makes perfect sense given that there is gravity and friction. Increasing the velocity each frame to simulate acceleration also makes sense physics wise. But this? Unless they explicitly state inside a red notice box in the hub that this property resets to 0 each frame, you would have a lot of confusion as people rarely fully read of the documentation.

Also, the perfect use for this would be as a read-only value for developers to see how much acceleration is being applied to the body, but this is impossible with your request.

#8

Applying acceleration on Heartbeat isn’t going to have any effect on performance… If you’re worried about the performance cost of setting properties on Heartbeat, remember that TweenService sets properties on Heartbeat, and does semi-complex math with no noticeable performance cost. Acceleration is already applied per frame internally otherwise a lot of physics stuff just wouldn’t work. I find it very annoying that I need to create a whole new instance just to apply some simple movement when I could be doing it in one line and more intuitively.

Velocity sort of has the same issue you brought up. Velocity is adjusted every frame, and it’s not something you can just simply assign and forget about it. You have to apply it for two frames to notice anything. If acceleration is reset after physics calculations take place there is no longer any issue. You can set the property and it will occur on the next Heartbeat. However, you should still be using Heartbeat for anything physics related. That’s what Heartbeat is for.

When I said this is friendly to new users I meant it is friendly in the same way that other physics properties are. It’s an easy concept to understand and it shows people what’s going on behind the scenes in terms of physics without them needing much prior knowledge. It’s easy to learn how it works and offers a lot of useful information and functionality to new and experienced developers that BodyMovers don’t have.

Having this exposed as a property gives experienced developers full control over physics and introduces the concept of acceleration much earlier than it would otherwise. I honestly don’t see what the issue is with an Acceleration property. Developers are not required to use this property if they don’t want to. If you want a simple interface for something like this, you can still use the ones we already have, BodyMovers. Creating, destroying, modifying, etc new instances (not to mention the fact that you have to make several function calls just to check if you’ve already made one) is much more performance costly than simply exposing one property and updating it per frame.

Like I said, a separate instance just doesn’t have any of the benefits I listed. If you’re worried about clutter it just seems weird to me that you’d rather be creating an instance, parenting it, changing properties, etc when it could be fit into one line and have the same exact effect.

#9

You still didn’t point out a single benefit of not having a sepparate instance.

As I said, it will have impact on a large scale because Lua is Lua. Applying this to 1k parts every frame will be an issue. An instance would act as one of the internal accelerations, not requiring any additional work on the CPUs side.

Using TweenService makes no sense for this. You are basically telling that it is user friendly to have a service that is supposed to gradially change a value suddenly turn into a physics manipulator.

If the players really want to know why the velocity works the way it does, they could just read an algorithm’s explanation on Wikipedia.

You don’t need to destroy a body mover. Disabling it would give the same result and it is easily reusable later on. The memory footprint is barely noticeable.

Also, why the hell won’t you just do the same as you said? Make one body mover, parent it to the part and apply all the accelerations you want to it.

#10

i feel like something like this would be more useful

part:ApplyForce(localOffset, force)

could be used to act like an instant BodyThrust, applying to velocity and rotvelocity, and would be pretty useful for making physical projectiles

7 Likes
#11

I told you before, I listed a bunch of benefits and explained them in the original thread. One Heartbeat connection does not cause lag. TweenService does make sense. TweenService sets a value per frame. In my example I even showed that you don’t necessarily have to destroy the bodymover. My code example reuses the BodyMover. Making a BodyMover for 1k parts and then checking if it exists every frame is much laggier than setting one property, it results in messier code, etc. Please read my post again, and please DM me if you’re going to argue with me about my own suggestion.

#12

This is the API I want.

Force = Mass*Acceleration so we can use this to impulse our parts properly for knockback and other effects.

Right now getting mass is relatively a slow process. There’s weird performance stuff with tracking mass.

An instance that counts assembly mass (and center of mass) would be useful. As well as just the mass of a welded group.

3 Likes