I know this is taking a while so sorry for the wait, its a relatively big project

So far Ive managed to make:

A rodeo:

And a crazy cube:

The main fault of the current system Im trying I think is that I was thinking of it as a single action (for a single movement it works like butter)

(the part gets anchored at the end of this for cosmetic purposes, but you can see how it slows down as it reaches the desired position)

Moves it to a perfect stop

The system works by applying a force for a certain amount of time, which is calculated by a very long formula

After that, it lets gravity take care of the rest for a very specific (also calculated) amount of time, bringing it to a complete stop exactly where you want it

The black line is the velocity of the part over time

The purple line is the position of the part over time

You can geometrically “derive” the formula to make this thing work through some really low level calculus

Basically:

The slope of the black velocity line is the acceleration

The area under the black velocity line is the total distance traveled

So we can use the area of a triangle formula and some other math to start working on it

So say you have a max acceleration of 10 studs/s/s and gravity is 196.2 studs/s/s like in roblox

Theres the two times, the time you apply the force and the time you let gravity slow you down to reach it at the perfect time

You can use the slope and those time values to find the area of the function, and the total area under the function should be the final distance you want (lets just say 5 studs)

You can find the shared height using both

`a * t_f`

and `g * t_g`

This is because slope is rise/run, so if you multiply it by the “run”, or x value, you get the “rise” over that distance, or the height

You can start on a formula because they share the same height:

```
a * t_f = g * t_g
```

The next formula would be the relation of the areas, and that the two areas have to add up to the distance you want to travel

The area would be height * base * 1/2, or, simplified:

```
(a * t_f^2)/2
```

and

```
(g * t_g^2)/2
```

You can then add those two together and set them equal to d

```
(a * t_f^2)/2 + (g * t_g^2)/2 = d
```

You now have two equations:

```
(a * t_f^2)/2 + (g * t_g^2)/2 = d
and
a * t_f = g * t_g
```

You can use this system of equations to solve for t_f and t_g

Theres still an issue that has to be worked out though

If theres a starting velocity of the part, you have to account for that in the movement of it

For example, if theres a starting velocity of -10 and you have to get up 5 studs, youll have to apply the force for much longer

Luckily its not too hard to fix it, but it makes the formula so much longer its almost ridiculous

You can simply adjust it to:

```
(a * t_f^2)/2 + (g * t_g^2)/2 + v * t_f = d
and
a * t_f + v = g * t_g
```

Where v is the starting velocity

In the first equation, you add on v * t_f because when you start with a velocity, theres a small “box” of velocity which has to be accounted for, which cant be accounted for in the triangle formula

The same applies to negative velocities but opposite

As for the other formula, the height of the left triangle is now lower than the right by exactly the starting velocity, so you just add it on

This new system ends up with two formulas:

t_{f} is t_f, or the time you apply the force to reach the peak velocity

t_{g} is t_g, or the time you let gravity slow you down

a is max acceleration, which is related to the max force applied according to F=ma

g is gravity

v_{i} is the initial or starting velocity

d is the distance you want to travel

I think the main problem is that this system is catered towards a single action, where something is moving to a point once

Nothing before or after that timeframe matters to the formula which I believe is the main problem

If you want to mess around with it a bit Ill drop off my little bit of really badly written testing code just to see how it would work

```
local p = script.Parent
local bf = p:WaitForChild("bf")
local force = 500
local m = p:GetMass()
local target_height = 5
local g = workspace.Gravity
local a = force/m - g --f = ma, gravity acts against it so you subtract gravity from the acceleration
function t_f(v,d) --function gives you the time to apply the force
return (-a*v - g*v + math.sqrt(2*a^2*d*g + 2*a*d*g^2 + a*g*v^2 + g^2*v^2))/(a^2+a*g)
end
function t_g(v,t_f) --function gives you the time to let gravity take over
return (v+a*t_f)/g
end
wait(5)
while true do
local v = p.AssemblyAngularVelocity.Y
local d = target_height-p.Position.Y
local t_f = t_f(v,d)
local t_g = t_g(v,t_f)
if t_f == t_f then --check if its undetermined/no solution
bf.Force = Vector3.new(0,force,0)
wait(t_f) --apply force for t_f seconds
bf.Force = Vector3.new(0,0,0)
wait(t_g) --let it slow down by gravity for t_g seconds
else --if it is no solution (it means its above the target position, because it only applies an upwards force), it will wait and let gravity take it downwards
wait()
end
end
```

This is really badly written and not meant to be anything final

I didnt even intend to show it to anyone so dont judge

Its set up with just a simple 1x1x1 cube arranged like so:

Where bf is a body force directly inside the script

(I used a bodyforce instead of a bodythrust because body forces wont go crazy if the part isnt directly vertical)

Ill be on tomorrow afternoon, Id appreciate any input from you or anyone else

The most likely next course of action would be to change the system entirely to something more “continuous” and built for constantly balancing something, not moving something nicely to a position a single time

If you think you can mess with this system and get it to work to constantly balance something thatd be awesome, but I dont know if its a reasonable possibility (unless youre making a rodeo)

Ive had a lot of fun making this system though, these kinds of problems I find very interesting

Anyways, good luck messing with it if you decide to, or if you just want to wait for a better system