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:
tf is t_f, or the time you apply the force to reach the peak velocity
tg 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
vi 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
