Warping/Stuttering of AI in Multiplayer

[thy_raven 0]

Dear Community

I have been searching the forums for an answer to my question for some time and have still found nothing that actually stops the problem. I don't know if its just something hardwired into the code and i just have to live with it or if its a fixable problem.

The problem of which i speak is the Warping/Stuttering of AI experienced by clients (but not the host) during multilayer games. I am sure a large number of your are aware of what i mean, I have tried the various advice present on the forum about altering my arma.cfg etc but although in some cases this can ease the problem it is never eliminated or reduced to an acceptable level.

What i would like to ask is how are other members of the community coping with this problem? is there a work around i haven't heard of? Any advice anyone can offer is welcomed. This problem has been plaguing my coop games for a long time and has turned a number of people off the game as Long range gunnery and sniper play is almost laughable.

My server.cfg is;

language="English";

adapter=-1;

3D_Performance=1.000000;

Resolution_W=800;

Resolution_H=600;

Resolution_Bpp=32;

MinErrorToSend=0.0000001;

MinBandwidth=76800000;

MaxBandwidth=100000000;

MaxMsgSend=512;

MaxSizeGuaranteed=1024;

MaxSizeNonguaranteed=64;

MaxCustomFileSize=1600000;

Any Help offered to this would be wholesomely appreciated, even suggestions and guesses are welcomed.

Many thanks

Raven

[blackspirerider 0]

Dude i know exactly what you're talking about. i have been dealing with that ever since I have had the game. It becomes impossible to snipe people from over 150 meters. Just a real pain in the ass. i would love a resolution for this.

Cheers

[cross 1]

I guess you have 100 mbit connection. Unfortunately, there is a confirmed bug in the server that it does not utilize the whole bandwith available due to a measuring issue in the logic.

Announced and hopefully will be solved in teh next patch.

1 - increase minerrortosend to 0.001. There is no point in flooding clients with info.

2- reduce MaxMsgSend=256 again no need to flood clients.

3- reduce MaxSizeGuaranteed to 512

4- Lower MinBandwidth to 10.000.000

5- reduce custom file size ...its in Kb. No need to have 1.6 MB of customfile. redoce to 100000 = 100kb

Suggestion..dont max out everything so that you don't flood clients who probably have low performance computers compared to the server, reduce the stress on client CPU as they need to use it both for running the game and communicating with the server.

Try them out and post the positive/negative outcomes.

See here as well..

http://www.flashpoint1985.com/cgi-bin....1;st=15

Quote[/b] ]Thank you for detailed repro steps - this most important part of any bug report, and this is much more important than things like if the bug report is submitted via BTS or a forum.

Thanks to your repro steps we were able to identify the problem and I hope to have some solution available soon. A little bit more information follows:

The "bandwidth balancing" is already implemented and it should work in such a way than one player is never getting extremely disproportional traffic. The problem we have found is in a different area, and surprisingly simple:

For bandwidth control the game needs to know approximate frame duration, so that it knows how much information it should try to send in one frame. What we do is we ask rendering subsystem to tell us average fps for last 16 frames, as this is something rendering already knows. Now the problem is on the dedicated server there is no rendering done at all, and the fps returned by the rendering subsystem is wrong - often numbers like 5 seconds are returned when in fact server is running at 50 fps. We will fix this by not relying on rendering when quering fps for this purpose. We are convinced this fix should not only greatly reduce the JIP caused lag and desync, but hopefully improved bandwidth control and balancing overall.

If someone wants to test meanwhile how balancing code works without this problem, you can try the repro steps above with a normal non-dedicated host. One important gotcha: when testing, make sure the host really is rendering, e.g. by letting someone to really play at it, as once the host loses focus (by alt-tabing or in a similar fashion), it would most likely show the same buggy behaviour again.

[thy_raven 0]

Thank you everyone for their replies

@crawler75; I have implemented the new changes you suggested, this may have slightly reduced the warping effect but it is still makes sniping over 200m a joke (unless target is stationary).

I'm very heartened to read that the problem has been recognized and is being addressed. Now I'm going to ask the fabled question, Does anyone know when this patch/fix will be released? I'm assuming the answer will be "When its ready" :P but thought i might ask just in case.

[cewing 0]

i'll give this a go on my server too. I've just accepted warping as a part of a poorly made game, since ofp days.