I've noticed this happens a lot, particularly in the life servers, but it also happens in wastelands etc. too where you just cannot play after the most recent MP security update because the desync spikes make everyone desync so bad.
Description
Description
Details
Details
- Legacy ID
- 1630597419
- Severity
- Major
- Resolution
- Open
- Reproducibility
- Sometimes
- Category
- Multiplayer
Steps To Reproduce
I'd say the quickest way to find it is to go into Seal Team Sloth life server and check peoples desyncs, but really most of the highly populated servers will have the same issue, just not as bad.
Event Timeline
Comment Actions
Seeing as my server was mentioned here, I figured I really should give the netconfig being used for Seal Team Sloth.
language="English";
Windowed=0;
adapter=-1;
3D_Performance=1;
Resolution_Bpp=32;
serverLongitude=-97;
serverLatitude=33;
serverLongitudeAuto=-97;
serverLatitudeAuto=33;
MinBandwidth=71457280;
MaxBandwidth=322428800;
MaxMsgSend=1024;
MaxSizeGuaranteed=1024;
MaxSizeNonguaranteed=512;
MinErrorToSend=0.020000001;
MinErrorToSendNear=0.020000001;
These settings worked flawlessly before the newest update.
To be honest we're not sure if this is an Arma issue, or a mission issue. We're using a 100mbps line on a Xeon 1230v2 with 16GB RAM.
Comment Actions
This issue was processed by our team and will be looked into. We thank you for your feedback.
Please keep the issue monitored to see when it is fixed.
Comment Actions
The issue to isolate it is related to the following commands running on the client.
clearItemCargoGlobal
ClearWeaponCargoGlobal
ClearMagazineCargoGlobal
By removing those three commands the mass desync has ended, there is still desync over time so further investigation should be looked into the engine, but to quickly see one of the issues those three commands cause desync issues when run on the client.
*EDIT* 5/17/2013
After more mission-side investigation removing the said commands above helped the early run of the mission (also clearItemCargoGlobal is broken, it's not global).
Over time with a mission using BIS_fnc_MP the BIS_fnc_MP_queue on the "bis_functions_mainscope" eventually builds up to an excessive 500+
I can see this isn't something BIS can do, maybe add a command to purge the queue that only the server can run or possibly add a limit of how far it can go.
Only real solution I guess for this is for the mission designer to purge such things.