Server Help :: View topic - soccer ball friction

Server Help

Bot Questions - soccer ball friction

Dege - Mon May 17, 2004 9:58 pm
Post subject: soccer ball friction

i believe that VampZ made a post on here a while back asking for the soccer ball friction/acceleration formula, the topic seems to be cleared now. I remember someone posting the formula, but couldnt remember what it was. I was wondering if someone could please post it again?

this would be used mostly for HZ bots, i'm guessing.
thanks

Mine GO BOOM - Mon May 17, 2004 10:26 pm
Post subject:

Speed is in pixels per 10 seconds. So if you have speed of 500, thats 50 pixels per second.

Acceleration, I don't remember, but I would assume that it is 1 pixel / (10 seconds)^2, since SS is everything done in either 10 seconds or 10 milliseconds. Have to check with someone else.

Anonymous - Tue May 18, 2004 2:46 am
Post subject:

It's not... because what they give you is "friction". I did some tests and it looks like acceleration isn't constant... please check with your person MGB though... the real forumla would be superb

Mr Ekted - Tue May 18, 2004 9:01 am
Post subject:

Learn ASM and rip it from VIE client.

Mine GO BOOM - Tue May 18, 2004 12:00 pm
Post subject:

Hmm, so soccer is friction. Well, formula for friction is F=u*r, where F is the force, u is friction, and r is the downward weight of the object. If you would be able to record a couple of position packets that include the ball's speed/position, and tell me the initial speed/friction of the ball, it wouldn't be hard to figure out what the r in the formula would be.

Or you could go Ekted way and rip code. I still prefer my mathematical approach. If you do want me to help you out, just record the data into a nice format that something like Excel could read.

Code: Show/Hide

Time XCoord YCoord XSpeed YSpeed

Use tabs between each value.

Anonymous - Wed May 26, 2004 1:24 am
Post subject:

When I look at the packets with MERVBOT as they get received it's just the same numbers. Maybe the client uses the initial X,Y, and velocities to come up with the new position?!? What should I do then... short of learning ASM and taking from the client?

Mr Ekted - Wed May 26, 2004 11:12 am
Post subject:

You also need to implement bounces.

Anonymous - Thu May 27, 2004 12:13 am
Post subject:

So it seems like just storing the initial position and velocity would be a terrible way of doing it... since when you put friction to zero and fire a ball that never gets caught would be a growing problem...

CypherJF - Thu May 27, 2004 12:18 am
Post subject:

I'm not sure what all your talking about; but SSCX Omega Fire had the soccer ball never stop (ie: no friction); the only problems occured: you couldn't pick it back up, and goaling if the player is offline (I forget what happens)

Goldeye - Mon Jan 10, 2005 6:52 am
Post subject:

Bump

I want to calc this once and for all.
Experiment to do it:
Two ships lined up and motionless with *warpto, both with 1 pixel prox.
Log the time, ball position, and the ball velocity when it is fired; and the time and position when it is caught.
Of course, the exact time the packet is recieved is unknown to an client except the one firing it. Solution: Log the time the ball-caught packet is sent. Then do all the joyful math to calc acceleration or friction, whichever it turns out to be.
If anyone can supply an arena in a zone with unencrypted packets, or a better idea for getting the recieved time, please tell

D1st0rt - Mon Jan 10, 2005 4:33 pm
Post subject:

you could use a bot

Bak - Mon Jan 10, 2005 6:55 pm
Post subject:

the packets are NOT updated. you only get the initial spot and initial velocity.

Underlord - Mon Jan 10, 2005 7:15 pm
Post subject:

soccerballspeed = 2500 pixels/10s
soccerballfriction = 12
distance ball travels shot from stationary ship = 745 (+-5)

changed to soccerballfriction = 6
distance = 965 (+-5)

just some quick approximate measurements
coefficient of friction calculates to about 1.5 (estimate)

Mr Ekted - Wed Jan 12, 2005 7:42 pm
Post subject:

I'm certain VIE/Cont calculate ball position discretely. Every 10ms the ball is moved some amount based on its current dx/dy, and then dx/dy is decreased based on friction. Internally, all units are * 1000 so speed and position can be handled smoothly without all kinds of rounding errors. This also saves you from having to recalculate possible bounces and/or catches every tick.

Mr Ekted - Fri Mar 24, 2006 7:17 am
Post subject:

I did a quick look through subspace.exe. There's only one place Friction is accessed in the entire file:

Code: Show/Hide

0043FFC6 0FBF4301 movsx eax, word[ebx+01]
0043FFCA 8D4CED00 lea ecx, dword[ebp+8*ebp+00] // ebp is ship type
0043FFCE 8D0480 lea eax, dword[eax+4*eax]
0043FFD1 C1E104 shl ecx, 04
0043FFD4 8D0480 lea eax, dword[eax+4*eax] // fancy way to do settings.ship[type].friction
0043FFD7 0FBF9190D84700 movsx edx, word[ecx+0047D890] // friction loaded from settings
0043FFDE 8D0480 lea eax, dword[eax+4*eax]
0043FFE1 895337 mov dword[ebx+37], edx // stored here

This value is then only used from this new location in one place:

Code: Show/Hide

0043FBB9 2BFD sub edi, ebp // friction is substracted from a single value

All coords internal are *1000 so that sub-pixel motion can be performed without using floating point math. In PB, friciton is 4. So my guess is every iteration (10ms) 4 is subtracted from the motion vector, not dx and dy separately. In PB, ball speed is 4000. If my guess is right, and 4 is subtracted from this 4000 each iteration, then the ball would come to rest in 10 seconds. Even if I'm wrong it seems pretty close.

I didn't spend the time to figure out the exact formulas for everything. It's pretty messy since I think this is the main physics code used by all objects.

Underlord - Fri Mar 24, 2006 8:06 pm
Post subject:

did a few tests in ss to confirm

soccerballspeed=4000
soccerballfriction=4

ball stops 10 seconds after passing it

soccerballspeed=4000
soccerballfriction=10

ball stops 4 seconds after passing it

used a combination of ballpassdelay setting, stopwatch, and bot timers to measure it within a few milliseconds

both results match the 'subtract friction from ball speed every 10ms theory'

BlueGoku - Fri Mar 24, 2006 8:38 pm
Post subject:

Awesome, thanks Ekted and Underlord. There were more than a few cool things we couldn't do before without the formula. Proper offsides tracking, for one.

Anonymous - Sat Mar 25, 2006 7:01 am
Post subject:

unless my math is totally rusty i dont think thats 100% accurate. the ball has some weird behaviors when its close to stopping. for some reason when the ball is fired diagonally the smaller velocity seems to reach 0 sooner than the other. it is hard to see with standard settings but it does happen at the very end. however in hz is really easy to see. im wondering if this happens because the values go too low for continuum and it converts them to 0? still kinda weird.

Mr Ekted - Sat Mar 25, 2006 7:15 am
Post subject:

Of course. I would expect that. Remember the math is being performed in interger space, not floating point. Rounding at the 0.001 level is done every iteration.

Smong - Sat Mar 25, 2006 8:57 am
Post subject:

Ok so by your theory:

Quote:

soccerballspeed=2500
soccerballfriction=12

ball stops 2 seconds after passing it.

When you can easily see it takes about 7 seconds.

Edit: Also I wouldn't expect friction to remain constant. It has to be relative to the speed of the object or terminal velocities wouldn't exist.

Mr Ekted - Sat Mar 25, 2006 9:09 am
Post subject:

Are you sitting still when you shoot it?

Smong - Sat Mar 25, 2006 10:17 am
Post subject:

Yes. And facing directly down too. I used the default settings that came with asss, which are mostly SVS.

Mr Ekted - Sat Mar 25, 2006 11:10 am
Post subject:

Are you making these changes in-game on an asss server? I tried testing these in PB (asss) and setting changes to friction have no affect. I think there's a bug in the creation of the settings packet. Likewise, many prize weights are all messed up.

Smong - Sat Mar 25, 2006 1:19 pm
Post subject:

I didn't change any settings and I just tested it on subgame with the same results. (If this is an april fools joke you're pushing it a bit far...).

You have to be careful when changing settings and include'd files in asss, the settings only reload when arena.conf changes, but you can use "?reloadconf ar" to force a reload (the second parameter is a filter).

Mr Ekted - Sat Mar 25, 2006 1:24 pm
Post subject:

I'm talking about changing settings by command.

Goldeye - Sun Apr 02, 2006 4:22 pm
Post subject:

Anonymous wrote:

In HZ, I just tested shooting 4 balls in a circle. One vertical, one horizontal, one 45 degrees and one around 10. They all ended up equidistant from the center.
Can conclude from this that the velocity vector magnitude is reduced, not the components.
What you see as weird is perfectly normal, that velocity component is so low that you don't notice it any more. Keep in mind that the ball is probably still moving at a subpixel level.

I will try to experiment with the position sometime soon, either finding a program to take screenshots of a moving ball at regular intervals or writing a module for recording start and end ball positions (and approximating the time)

Mr Ekted - Sun Apr 02, 2006 5:01 pm
Post subject:

Yes, but even with sub-pixel movement, eventually the numbers trail off to zero in one axis before the other. For example, cos(80) = 0.173648, sin(

= 0.984807. When velocity gets small enough, movement in the X direction will round to zero before the Y direction. However, this is a VERY tiny issue.

Smong - Mon Apr 03, 2006 10:06 am
Post subject:

Goldeye wrote:

I will try to experiment with the position sometime soon, either finding a program to take screenshots of a moving ball at regular intervals or writing a module for recording start and end ball positions (and approximating the time)

Not many people realise this but only the client knows the end position so a module wouldn't be able to do that directly.

What I suggest is use a ship with a known ball prox, fire a ball directly at it. Move the ship gradually further away from the fire point until it no longer picks up the ball - this will be where it stops. You can use the ball fire/pickup callback to time it.

To overcome the glitches in moving ships per pixel, you can decrease the ball prox gradually. When you have decreased it by 16 pixels, move the ship 1 tile further away and reset the ball prox.

Anonymous - Mon Apr 03, 2006 10:11 am
Post subject:

Goldeye wrote:

[..]
What you see as weird is perfectly normal, that velocity component is so low that you don't notice it any more. Keep in mind that the ball is probably still moving at a subpixel level.

nah, the ball does a perfectly visible "curve" when a velocity reaches a certain value, and that definately isn't "normal" in vector math. it is really easy to see in hz. while not moving, shoot the ball at 181 degrees (or 21 continuum degrees.. anyway one pixel more than facing down/up/left/right) and the curve i'm talking about is really easy to spot.

Goldeye - Mon Apr 03, 2006 4:46 pm
Post subject:

Anonymous wrote:

[..]

nah, the ball does a perfectly visible "curve" when a velocity reaches a certain value, and that definately isn't "normal" in vector math. it is really easy to see in hz. while not moving, shoot the ball at 181 degrees (or 21 continuum degrees.. anyway one pixel more than facing down/up/left/right) and the curve i'm talking about is really easy to spot.

If this is true, how does the ball still land along the circular arc?
The trail does "curve", because the small component becomes too small to draw. However, it's seems to be a perfectly correct vector.

Goldeye - Mon Apr 03, 2006 4:53 pm
Post subject:

Smong wrote:

[..]

Not many people realise this but only the client knows the end position so a module wouldn't be able to do that directly.

What I suggest is use a ship with a known ball prox, fire a ball directly at it. Move the ship gradually further away from the fire point until it no longer picks up the ball - this will be where it stops. You can use the ball fire/pickup callback to time it.

To overcome the glitches in moving ships per pixel, you can decrease the ball prox gradually. When you have decreased it by 16 pixels, move the ship 1 tile further away and reset the ball prox.

Of course I realize that!

I would use a ship with 1 prox to get the position, and just guesstimate the time with a stopwatch or the like.

Getting a video of it would be the best way, either with constant fps or a reliable timer on the screen.