Did anyone made real attempts to figure out that ball formula?
With some modifications on Bak's auto-fighting bot, I believe I could make it follow the ball on radar, and then I could get values of position vs time. Try that with different friction values, pull out some equations, and solve... Could throw out a few different equation forms, and see which one fits the best. If it's not linear, the most probable thing is an exponential, which could be solved from a differential equation (i.e. loss of speed is proportional to speed, much like the air resistance when something falls down).
If I'm wasting my time and this has already been tried, tell me... But I never read anything about that, so...
Bak - Wed Mar 05, 2008 8:20 pm
Post subject:
it's not linear and it's not exponential. Arnk has a nice spreadsheet floating around somewhere, or if you look in really old topics you'll see some of my spreadsheets.
using the pixel radar thing won't be very accurate since that bot only gets a few frames/second not to mention the radar is very coarse.
samapico, i'd say go for it, and if you succeed you will have trumped us all proving that you are the superior human being
Samapico - Wed Mar 05, 2008 9:03 pm
Post subject:
well, I thought maybe with a good radar zoom factor, it could be relatively accurate...
I'll try to find these spreadsheets
Bak - Wed Mar 05, 2008 10:44 pm
Post subject:
http://rshl.org/akd/balls.xls
Samapico - Wed Mar 05, 2008 11:51 pm
Post subject:
whoah... it really is a step function :/
fecking weird
Samapico - Thu Mar 06, 2008 1:12 am
Post subject:
ok...
in 1 millisecond, speed is reduced by [something that depends on speed]:
newspeed -= (currentspeed/1000)+1
currentspeed/1000 + 1 cannot be larger than 4 apparently
Here's something that 'could' maybe work..didn't test it or anything yet
Code: Show/Hide int ballspeed(int initialspeed, int time) { while (time > 0) { int factor = min(initialspeed/1000 + 1, 4); if (time*factor > 1000) initialspeed -= 1000*friction; else initialspeed -= time*factor*friction; time -= 1000/factor; } return initialspeed; } |
(feel free to split this whole ball thing topic if needed)
it doesn't really work how I want it to.. but anyway.. the idea is to take away the speed , 1000 units at a time. And "use" a part of the time each time. Taking away 1000 units of speed between 3000 and 4000 "uses" less time than between 2000 and 3000...
I'm kinda tired so my brain can't properly code that...
In theory, if you put that in Bak's excel, and ask for the newspeed of every initialspeed with a time of (the time given), it should give close to 0 for all of them
Also, it's probably possible to simplify it a lot
I don't really think Priitk would have cared to make a while loop for that kind of thing Could probably be done with a single substraction
Smong - Thu Mar 06, 2008 12:50 pm
Post subject:
Here's one of the older threads:
http://forums.minegoboom.com/viewtopic.php?t=2747
On page 2 there's a claim the formula is found. But there's 2 more pages arguing over it.
Samapico - Thu Mar 06, 2008 3:15 pm
Post subject:
I didn't see any realistic formula in there... just theories based on 1 or 2 numbers
The formula above is very ugly... however, if the speed if modified every tick, then it's pretty easy:
Code: Show/Hide void UpdateBall()
{ ball.x += ball.xspeed; //kind of... gotta convert this from pixels/10seconds to pixels/Tick actually ball.y += ball.yspeed; //same here ball.xspeed -= (ball.xspeed/1000 + 1)*friction; ball.yspeed -= (ball.yspeed/1000 + 1)*friction; //Of course, it needs to check for bounces... if (Xcollision) ball.xspeed = -ball.xspeed; if (Ycollision) ball.yspeed = -ball.yspeed; } |
This is still a theory, since I only had the data for friction = 1... Bak, do you still have that module that made you get those values in your excel sheet? Could it be re-done for different friction values? And possibly with even more ball speed... The fact that the ball doesn't behave the same over 4000 is intriguing me; I'd like to see what happens with very high speeds.
Basically, the faster the ball is, the more speed it loses
Would be nice to have a way to compare a model with the real thing too. Like the module could drop mines following the path of the model at the same time as the real ball travels.
It's quite simple to come to this conclusion with the data Bak posted
Code: Show/Hide Speed Time dTime/dSpeed 960 960 1 980 980 1 1000 1000 1 1020 1010 0,5 1040 1020 0,5 1060 1030 0,5 |
We can see that the ball takes 10 ticks to go from 1020 to 1000 speed, and then it takes 20 ticks for 20 speed units all the way to 0.
The exact same thing happens every 1000 speed. Except after 3000 it seems to be a constant 4 <speedunits> / millisecond
One question though... if all values are integers, how would a ball of speed=1 move if (speed/1000) is added every millisecond (or /100 if a tick is 1/100th of second).
EDIT: I wrote milliseconds almost everywhere... just realised they were hundreths of seconds
Samapico - Thu Mar 06, 2008 4:01 pm
Post subject:
EDIT2:
Seems like there is no "limit" on the "ballspeed/1000" thing actually...
Just threw a ball with 20000 speed, and it seems to match the model I put up above. With speed being reduced of 20 every tick between 19000 and 20000.
Smong - Fri Mar 07, 2008 3:18 pm
Post subject: