Quelques infos sur le netcode de arma:
You must make difference between:
1. local game, that includes SP game or MP game when you are hosting the game (so you are server and player at the same time)
2. remote game, that means MP game running on dedicated server or someone other "playerserver" (so you are not server and player at same time)
Because INTERPOLATION works perfectly GREAT in case 1., even in MP game, when you are serverPlayer (hosting the game), but only for you! Other players objects will be still laggy.
In case 2 (MP game on dedicated server), there you must also make difference between:
2a. server AIs and objects (this can be partially solved by settings in base/basic.cfg )
2b. players AIs and objects (own AIs or other players AIs) ... there is no way how to solve this
In CASE 2a, there INTERPOLATION also works nice.
Problem is and always was (from OFP times) in CASE 2b. There INTERPOLATION can't help (would be described below). This is not BUG, this is how is game network engine using player's upload line.
In other words, how often are clients (players) sending their positions (player and his AIs) to the server.
Well, interpolation is possible only when you have enougth positional updates. They must be periodical and often as possible. In SP mode, this is not problem, because all objects are LOCAL, so "SP server" have/knows precise positions of all object at any time.
But in MP, "MP server" knows positions only of its own "controlled" objects. Positions of remote objects (player object positions) must be received periodical and often as much, as is possible. And this is problem, because as far as I know, game network core is working in the same way, as it was in old OFP game (same problem in all BIS games).
To me it seems, that INTERPOLATION works great even in MP, but the current network game engine simple does not have (can not provide) actual players and his AI's positions to game engine (specially in way from clients to server).
Simply sad, current game network core can not fully utilize players upload line to provide the best positional updates to the server, as it should be (or as it is possible on player upload line).
I think, that BIS have recognized this, that it is not possible to make MP smoother (INTERPOLATION can't help here too much), so they temporally turned this OFF for MP, after releasing 1.6final, i hope that they would start on changes in game network core, that game can use full upload capacity on players computers, so the server should have smooth positional updates from clients as their upload lines can provide.
Personally, I have lose about 40 hours of clean time to try "play" with all server settings in base.cfg (basic.cfg).
I was comparing what different I will see between DEDICATED server and HOSTED server ("playerserver"). This was done on 100Mbit FD LAN.
There is simple no way, how to make better smooth game by playing with those settings, even when server generated traffic around 12MBit per player from server on LAN game. In case of so much positional updates, clients see all objects just standing on place (not cause by server line or CPU overload, usage was very low compared to HW limits).
Of course, there was some improvement in smooth move, but this was only on server controlled objects. Other players AI was still laggy and not smooth (perhaps clients should sets its own base.cfg too with better values ... I would test that next time).
Anyway, by setting in base.cfg on server, where was problem to determine, what is the best. When I set it too high, it was looking smooth, but when other players was connecting and game was expanding, traffic was too big to handle for clients, and it was back laggy.
When I set MinErrorToSend=0.00001; , engine will create great amount of positional updates internally (i think BIS call this "frames" as "frame update").
But then how set optimally MaxSizeNonguaranteed ?
In case MaxSizeNonguaranteed=64, game was nice almost smooth, but with more players and objects, the amount of packet was very high and there was packetloose i think, because game starts be laggy again.
In case MaxSizeNonguaranteed=1400, there was no packet lose even many players was connected, but packets was sending no so often (very rate I could say) so game was still not smooth.
So as you see, those two main parameters are useless, because they are STATIC. What we need is that those parameters should be calculated "on the fly" dynamically by game network engine. When there is not so much objects and clients, there can be MaxSizeNonguaranteed=32 and packets can be send very very oftly. When UPLOAD is hittig his limits, game should dynamicaly linear adjust MaxSizeNonguaranteed to MaxSizeNonguaranteed=1400. So, there should be less frequent updates, but no packet lose.
There is also some hard coded frequency, how often should updates be send for objects (related to distance from player). This frequency is I think linear with MinErrorToSend=0.00001; . At this values, closer objects are send too often (big overhead, not necessary), and distant objects are still not send as often, as it would be smooth.
I hope I have expressed my self clear, English is not my native language (Czech).
D'autres infos: http://forums.bistudio.com/showthread.php?t=124316