Arma 2 : OA beta build 84984

[EugenyKrag 10]

...

This patch is for OA/CO, not A2.

Because you said your waiting for 1.11 means to me that you don't have OA/CO.

lol, I have CO, but usually I'm setting up patches for oa2 too.

Edited September 30, 2011 by EugenyKrag

[conKORD 10]

MinErrorToSendNear is used differently from MinErrorToSend. When computing the error for MinErrorToSend, the error is divided by (distance_in_m/20m)^2. Because of this, when MinErrorToSend is small enough so that distant units move smooth, the near units move "supersmooth" (the updates are sent even when the movement is so smooth it makes no gameplay difference). MinErrorToSendNear gives a way to give another absolute (not distance dependent) limit ("never send update smaller than 1 cm, even if MinErrorToSend would allow it to be sent").

Is it correct?

For example

MinErrorToSend = 0.001;

Real error to send

20 meters: 0.001/((20/20)^2)=0.001m=1mm

1000 meters 0.001/((1000/20)^2)=0,0000004m=0,0004mm WTF?

Or did you mean multiplied by (distance_in_m/20m)^2 ? But here is also something wrong

Real error to send

20 meters: 0.001*((20/20)^2)=0.001m=1mm

1000 meters 0.001*((1000/20)^2)=2.5m

3000 meters 0.001*((3000/20)^2)=22,5m looks too big

[Party3AH 0]

Suma,

have just the same qusetion that conKORD, I cant clear understand that system.

Show us please an example and its result, for correct understanding.

[suma 8]

20 meters: 0.001/((20/20)^2)=0.001m=1mm

1000 meters 0.001/((1000/20)^2)=0,0000004m=0,0004mm WTF?

Or did you mean multiplied by (distance_in_m/20m)^2 ? But here is also something wrong

You have got the division on the wrong side of the equation. If the object is to be sent, its error (difference compared to last sent state - included position change, but other state changes contribute as well) needs to be higher than MinErrorToSendNear, and its error divided by square distance needs to be higher than MinErrorToSend/20 (20 is an arbitrary constant selected while the game was developed, it could be eliminated, but it would require rescaling MinErrorToSend on all servers accordindly).

Edited February 8, 2012 by Suma

[conKORD 10]

You have got the division on the wrong side of the equation. If the object is to be sent, its error (difference compared to last sent state - included position change, but other state changes contribute as well) needs to be higher than MinErrorToSendNear/20, and its error divided by square distance needs to be higher than MinErrorToSend/20 (20 is an arbitrary constant selected while the game was developed, it could be eliminated, but it would require rescaling MinErrorToSend on all servers accordindly).

So MinErrorToSendNear is not absolute value and to measure what minimal error (I mean position change here) will be sent we need MinErrorToSendNear multiply by 20?

For example we have high loaded server with 150 players on it. 100mb/s bandwith is not enough to handle it with default server config. So we need to reduce data amount sent to players.

I think that accuracy of position sent to players 0.1 meters is enough with new visual state interpolation. What value should I set in MinErrorToSendNear to be sure, that moves smaller than 0.1 will be not transmitted?

Same thing with MinErrorToSend

At which distance will we have minimal error to be transmitted greater than 0.1m with MinErrorToSend=0.001 ?

Condition to be sent is

and its error divided by square distance needs to be higher than MinErrorToSend/20

(0.1m/dist > MinErrorToSendNear/20)

0.1m/x^2 > 0.001/20

2/x^2 > 0.001

2/0.001<x^2

x<(2/0.001)^.5

x<44m => so at distance greater than 44m error lesser than 0.1m will be not sent. Am I right?

Edited February 8, 2012 by conKORD

[suma 8]

So MinErrorToSendNear is not absolute value and to measure what minimal error (I mean position change here) will be sent we need MinErrorToSendNear multiply by 20?

I am sorry, the 20 should not be here, a mistake on my side. The 20 is the denominator for the squared distance division only. MinErrorToSendNear is an absolute value (position change + other state changes measured as well).

At which distance will we have minimal error to be transmitted greater than 0.1m with MinErrorToSend=0.001 ?

The formula can be derived as:

error*20/dist^2>MinErrorToSend

dist^2/20<error/MinErrorToSend

dist = sqrt(20*error/MinErrorToSend)

Which is equivalent (and gives indentical result for error=0.1 and MinErrorToSend=0.001) to what you have calculated.

[conKORD 10]

Thanks :)

But, again ( :) ), for example

MinErrorToSend = 0.001 means that min. error that will be sent at distance 1km is 50 meters.

2 km - 200 meters

It's common enough distance for vehicles and, for my game experience, everything at this distance moves smooth and without 50m -200m jumps.

Is here another hm . . . optimisation?

Edited February 8, 2012 by conKORD

[suma 8]

But, again ( :) ), for example

MinErrorToSend = 0.001 means that min. error that will be sent at distance 1km is 50 meters.

2 km - 200 meters

It's common enough distance for vehicles and, for my game experience, everything at this distance moves smooth and without 50m -200m jumps.

Update sent approximately once per each 50 m of movement at 1 km seams reasonable to me. The values in between are provided by a simulation based on last known values (including not only speed, but also other state values, like throttle settings) and smoothed by interpolation (introduced in 1.60, before that you could see the jumps caused by the estimated simulation not matching the real object position).

Note: let me repeat, the error is not only a position change, but other values are included (with different weights). This means if other values are changing, the update can be sent sooner than after 50 m position change. Velocity, for example, has quite a high weight (which is even growing with time for this particular value), as it is very important for a position prediction to match the velocity right.

I hope that is enough for you. The system is complex and I do not feel like describing every minute detail of it.

[conKORD 10]

Yeah . . . enough. Thanks for your time.

[.kju 3239]

conKORD can you please add your new insights to the BIKI now. Thanks :)