Server Help

Samapico · Posted: Wed Mar 05, 2008 10:13 am Post subject:

Split by Smong at March 6, 2008, 9:38 am

ball friction formula eh...

brb

_________________
(Insert a bunch of dead links here)

tcsoccerman · Posted: Wed Mar 05, 2008 4:11 pm Post subject:

i suppose you wouldn't need the formula if you were recording. just wait until the next frame to display the powerball position. or did i miss something?

Dr Brain · Posted: Wed Mar 05, 2008 4:31 pm Post subject:

You missed something.
_________________
Hyperspace Owner

Smong> so long as 99% deaths feel lame it will always be hyperspace to me

tcsoccerman · Posted: Wed Mar 05, 2008 4:58 pm Post subject:

Samapico · Posted: Wed Mar 05, 2008 5:02 pm Post subject:

Bak · Posted: 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
_________________
SubSpace Discretion: A Third Generation SubSpace Client

Samapico · Posted: 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 · Posted: Wed Mar 05, 2008 10:44 pm Post subject:

http://rshl.org/akd/balls.xls

Samapico · Posted: Wed Mar 05, 2008 11:51 pm Post subject:

whoah... it really is a step function :/
fecking weird

Samapico · Posted: 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 · Posted: 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.
_________________
ss news

Samapico · Posted: 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 · Posted: 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 · Posted: Fri Mar 07, 2008 3:18 pm Post subject:

Samapico · Posted: Fri Mar 07, 2008 4:55 pm Post subject:

Yeah I noticed several mistakes in what I posted above too

I never said it was really working either; Was just throwing out what I found out.

The *friction are very theoric too, since I only used the data with a friction = 1, so I have no idea what in the equation will change with different friction values... So for now I'm only working with friction=1. A possibility would be that sqrt(fraction) would be part of the formula...

Also, the function dSpeed/dT is clearly in steps... However, it's not 1,2,3,4 as I said before. I was kind of tired when I wrote that...
Speed ; dS/dT

[ 0 ; 1000] ; 1
[1000, 2000] ; 2
[2000, 3000] ; 6
[3000, 4000] ; 8
[4000, 5000] ; seems to average at 8 too
[5000, ... ] ; no data, but I'm pretty sure it goes higher than 8

...Can anyone figure out some kind of series that can do 1,2,6,8 ?? (and ideally, 1,2,6,8,8 )

Smong · Posted: Fri Mar 07, 2008 5:11 pm Post subject:

Samapico · Posted: Fri Mar 07, 2008 5:20 pm Post subject:

Also, when I write ballspeed/1000, I assume integer divisions. For example, 2999/1000 = 2. That's how C++ does it (by default).

Samapico · Posted: Fri Mar 07, 2008 5:20 pm Post subject:

Samapico · Posted: Fri Mar 07, 2008 6:31 pm Post subject:

So far, it seems to work relatively well with the airtime... i.e. the time before the ball reaches a speed of 0. However, there is something I don't understand in the distance travelled...

Code: Show/Hide

Init.Speed Dist Airtime
2000 1251 15000
2060 1288 15100

Speed is in px/10s, Distance is in px, Airtime is in ms.

If you travel at 2060 px/10s during 100ms, you should travel a total of:
2060/10000 * 100 = 20.6 pixels.
Right? Divide by 10000 to get pixels per milliseconds, then multiply by the number of milliseconds. (It would be a bit less, because speed goes down from 2060 to 2000 during that time, but let's forget about that).

However, in Bak's data, the additionnal 100ms of flying at ~2060speed added 37 pixels... Almost twice as much as expected. WTF?
The same thing happens throughout the whole data... Because of this, the distance travelled shown by my simulator is always much lower than in the datasheet.
However, I'm assuming that a ball fired at 2060 will act the same as a ball fired at 2000 once it reaches the speed of 2000. This shouldn't be a problem, unless the formula includes something about the InitialSpeed. It would be very surprising and stupid, but... :/
Is there anything I don't understand in the relation between speed and distance? I mean... it should work like a simple ship right?

Here's Bak datasheet with some comments and additional calculated data

Bak · Posted: Fri Mar 07, 2008 10:19 pm Post subject:

in case the "akd" in the url wasn't a give-away, that's arnk's data sheet so you'll have to bug him for the module (although I did make quite a few bots to measure it when I was after this grail)

Samapico · Posted: Fri Mar 07, 2008 11:04 pm Post subject:

oh... lol thought it was all yours

sorry

Smong · Posted: Sun Mar 09, 2008 12:11 pm Post subject:

http://www.youtube.com/watch?v=eoICmuwghDQ $$

Doc Flabby · Posted: Sun Mar 09, 2008 12:17 pm Post subject:

Does PSpace ever work out the ball friction?
_________________
Rediscover online gaming. Get Subspace | STF The future...prehaps

Samapico · Posted: Sun Mar 09, 2008 12:17 pm Post subject:

Pretty much the same problem as me it seems... the deceleration takes the same time, but less distance is travelled

Smong · Posted: Sun Mar 09, 2008 12:19 pm Post subject: