Anunnaki Nibiru

Limit is mostly set by Internet providers manually to prevent flooding. Also every SOHO home routers (or ADSL modems with NAT router) have some HW limits too. No, OS (like Windows) does not have any limits as far as I know in packets per second. Arma engine use IP UDP packets, and there are not real connections created on 3. layer. Connections are created by TCP packets, and normally, you create (establish) one connection from port to port, and when this TCP connection is established, you can send many many packets per second withouth need to create another connection between different ports. I think yes, it is misleading (technically it is true in some cases). Bigger payload in packet can little increase delivery time (few milliseconds), but only in case, when there are many data to send. Because when there are not to much data to send, packets are still short (short payload) so result is the same as with low value in MaxSizeNonguaranteed . But when this value is low, and there are many data to send, there would be plenty of packets created. Overhead can be greater then line capacity is, so many short packets would be send with bigger delay, and even some can be dropped (not delivered). So lower value can create many more lags and problems, than bigger value. Low value is good, but only when server and all clients are on single ethernet LAN, no other routers in the way. 100Mbit FullDuplex LAN ethernet can send great amount of small packets withouth delay or dropping. But on internet, it can do more harm than good. Normally, packet from OS are "queued" as they are created, and than send in the same order. So there is nothing like prioritization for small packets. But, you can have QoS setted on OS level, Network card level, or your Home router, or even or your internet provider. In some cases, there are way how you can prioritize small packets over bigger, but it is not easy to do. Normally, QoS prioritization is done on source/desitnation (TCP/UDP) "ports". For MaxMsgSend, I think that current values are too big for clients, and OK for servers. But you must always consider the next variables in conjunction, because those together are creating how much packets and how big they would be. For MaxSizeGuaranteed and MaxSizeNonguaranteed , I think yes, they should set this to 1400 as default. It is how fast is your upload line in any time, even evenings, when most people from your internet provider are "on internet". Sometimes, you can upload at nights or morning at speed about 20Mbps but evening, it goes only 10Mbpps. This is your real line speed at any time, and server/client is trying use that amount of line. Sometimes, server and client can try to send more data than you set in this limit, but those data are probably not so critical, so they can be send with bigger delay or lost in the way.

This is only how big can packet be (payload), and there is no reason, why lower this value. I prefer less number of packets per second, but with longer payload. Longer packets means less (header/crc) overhead, less game/CPU utilization and more line capacity for payload (useful data). It works like this: Game engine creates every frame internal game/engine "simple messages", I think every message contains one event (one object move or state, but this is not important). Don't be confused be another term "aggregate messages", which means packet. Then engine takes those "simple messages", and starts filling packet payload with those simple messages, till limit MaxSizeGuaranteed/MaxSizeNonguaranteed. When this limit is reached, packet is send, and game creates new packet and continue fill payload with rest of simple messages in queue. There is limit, how much packers (=aggregate messages) can be created every frame (MaxMsgSend). When this limit is reached, rest of simple messages are dropped (or queued to next frame, I am not sure on this one). With lower payload and many simple messages to send, there would be much more packets (=aggregate messages) per second send, and if payload is very low, and there are more players, you can even consume upload line capacity with this overhead. Even more, many players have not only bandwidth limit, but also packet rate limit (around 800-1200packets per second per whole line (all other traffics on line not just for Arma), this limit can be even lower, when they use SOHO home routers (NAT/firewall), and perhaps they can use more computers on this line. In the case, when you have high payload, and the engine does not have many messages to send, the packet would be short (every frame there is at least one packet send, even when there are no simple messages inside). So it can't hurt, but in case when there is many simple messages (datas) to send, it can magnificently help. Difference in response (packet delivery and confirmation time) between 64 bytes payload and 1400 bytes payload on slow ADSL line is about 25ms (12,5ms to server). I think this (12,5ms) is not noticeable at all for anyone. On Ethernet lines there is even much much less difference. Example: Imagine there is 1,4kBytes of data every FPS: When ... MaxSizeGuaranteed/Nonguaranteed=1400 ... then ... ppf=1, pps=50. When ... MaxSizeGuaranteed/Nonguaranteed=64 ... then ... ppf=22, pps=750. Imagine there is 25,0kBytes of data every FPS: When ... MaxSizeGuaranteed/Nonguaranteed=1400 ... then ... ppf=18, pps=900, useful payload=10,0Mbit (1,25MByte), overhead=0,28Mbit (0,036MByte) . When ... MaxSizeGuaranteed/Nonguaranteed=64 ... then ... ppf=391, pps=19550, useful payload=10,0Mbit (1,25MByte), overhead=6,25Mbit (0,782MByte). Note: ppf ... packets per frame (game frame, maximum 50) pps ... packets per second every packet have have 38 or 42 bytes overhead (header+crc+qos)

EXT community: Server (100Mbit full duplex): MinErrorToSend=0.001; MaxMsgSend=2048; MaxSizeGuaranteed=1400; MaxSizeNonguaranteed=1400; MinBandwidth=50000000; MaxBandwidth=100000000; All clients (basic ADSL with maximum 512kbit Upload + some reserve for TeamSpeak communication): MinErrorToSend=0.001; MaxMsgSend=128; MaxSizeGuaranteed=1400; MaxSizeNonguaranteed=1400; MinBandwidth=256000; MaxBandwidth=480000; We were using those settings about 4 years on our servers (A1,A2,A2OA). Only MaxSizeNonguaranteed was 32 later 64, and about 3 months ago we switch to 1400 after some hard tests. Around this time, we start using similar settings on all our clients too. MaxSizeNonguaranteed=32 was creating too much small packets, with many players on server it was too much packets = very big packet overheat. It is best to have bigger packets to prevent header overheat and save line bandwidth from server. Some clients can have also some limits from internet providers, how much packet per second they can accept, and any more packets about threshold can be dropped. We are playing Domination with ACE, about 8-14 human players, some with AIs on clients. FPS on server is around maximum for all time, after "MaxSizeNonguaranteed=1400" there is not too much traffic, compared with 32. I was not playing on any other servers on internet, because I was not able to find any other server for YEARS, with good settings like was on our server. So on other server was too much jerky motion compared to ours. PS: I have fixed some terms in text in WIKI to use correct terms like "packet" instead "message" (putted to bracket) or "frame" (confusing with 2. layer Ethernet frames) http://community.bistudio.com/wiki/basic.cfg#Performance_Tuning_Options .

Hi SUMA ... congratulations! It looks like from build 84554, finally after so many many years, all motions in MP is smooth as it never was before. Sorry but at this occasion, I must put here some lines with my feelings here: I have founded clan/community in times of release the OFP, one from the first dedicated servers for OFP/A1/A2 and it survives till today. We have bought all BIS's games and almost all data-discs. We was hoping for so many years, that one day, BIS would be able to fix MP game and make them widely playable. But after releasing first A2OA, we was almost sure, that game shifted mainly on SP arcade players, and we was loosing hope that it would be ever fixed. Some of our members was so angry, because they was paying money for MP game, which was not playable for them and they was not interested in SP. Some have promissed, that they will never buy any game from BIS in future. But perhaps now, when I see it with my own eyes, that MP game is nice smooth, I am sure that they will return back, and perhaps I convince them again, to buy also A3 :). Thank you very much for fixing those main problems for Arma community, and I hope that from now, Arma2 Multilayer game would be finally gaining on popularity around players across the world. But back to reporting results: From build 84554 there is no "jumping back when stopping", but when they stop, they go to slip. This is very noticeable in 84554 build, less noticeable in 84580. I am testing every build for any kind of jerky motion in MP. Results and example videos are in this ticket: http://dev-heaven.net/issues/24252

Yes, that is "1. BUG: non-driver passenger" from this ticket: Trouble ticket here: http://dev-heaven.net/issues/24252 Video of this bug: It was introduced in build 82901.

Non-local objects (in MP game) are moving jerky. This BUG have 3 parts: 1. BUG "non-driver passenger" ... NOT FIXED 2. BUG "observer outside vehicles" ... FIXED ... "[84464] Improved: MP: Remote units should move a lot smoother." 3. BUG "stop jump" ... APPEARED AGAIN ... "[84285] Fixed: MP: Remote units jumping back when stopping" Other informations and VIDEOS of those BUGS are here: http://dev-heaven.net/issues/24252 .

Non-local objects (in MP game) are moving jerky. This BUG have 3 parts: 1. BUG "non-driver passenger" ... NOT FIXED 2. BUG "observer outside vehicles" ... FIXED ... "[84464] Improved: MP: Remote units should move a lot smoother." 3. BUG "stop jump" ... APPEARED AGAIN ... "[84285] Fixed: MP: Remote units jumping back when stopping" Other informations and VIDEOS of those BUGS are here: http://dev-heaven.net/issues/24252 .

Remote objects motion in MP is jerky in A2/A2OA http://dev-heaven.net/issues/24034

Motion in MP is jerky (laggy) ... I am sure now, that real problem with jerky MP comes with first release of Arma2. Last not affected version is latest Arma1. There is also some work-around to minimize jerky in MP. All you can find here: http://dev-heaven.net/issues/24034 I hope that BIS solve this "few years old MP issue" very soon, other-ways it would be also in Arma3, and that would be disaster for MP community.

We just discovered that this BUG: Shortly after the remote (non local object) stops moving, it will jump to adjust (fix) its position. http://dev-heaven.net/issues/24034 Is present also in first release of A2OA and also in A2 1.05! Can be this issue, causing strange behaviour of Interpolation in MP? Or can this leads to situations, when REMOTE objects in MP are unable to avoid each other on roads or in some small space, because their positions are "shifting" in time? I try to test this latest beta 84223 shortly.

http://dev-heaven.net/issues/23241

About "laggy" AIs in MP, you must make difference between: 1.) server AIs (this can be partially solved by settings in base/basic.cfg ) 2.) players AIs (own AIs or other players AIs) ... there is no way how to solve this In CASE when you reffering to case 2., 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. I created ticket for that issue, you can VOTE for it: http://dev-heaven.net/issues/23241

This BETA is better in speed than was few previous betas. All looks nice smooth, even in MENU i have feeling that it is smoother. So far, no crashes. Tested with modes CBA, ACE, SMK, ACRE. We (about 8 people from our community, CPU Intel/AMD, GPU Nvidia/AMD, OS all Windows7 32/64bit) was never experiencing something like is in that picture above in BETAS for very very long. We have very long ago very simmilar experience, but it was from broken 3D model from addon, and one time have someone broken some game files (detected by BIT comparison with clean install patched files). We will test it more in MP today, and let you know. CPU AMD X4, RAM 8GB, GPU AMD 4890 1GB

GREAT !!! I was waiting for this since Arma1 !!! But i loose confidence in Bistudio programmers, when this was not implemented in Arma2, and i loose hope, that this would be implemented even in Arma3. But when if you really implement this to the A2/A2OA, i will buy Arma3 and all A2 DLCs as great thanks. There also remains 2 more thinks to do in Arma3 engine: a) be able to have multiple independent "views" in one main "view" in game. That allows to use real working displays/huds/instruments in cockpits (cabin) in vehicles. b) the same approach can be uset to have rear "mirrors" in game on vehicles. This gives great reality and real looks to the games (real mirrored environment on optics, or driving by mirrors) About physix: I think, that PHYSX is not needed, because it is used only on NVIDIA cards, so half players of A3 game would be not able to enjoy PHYSX. So why spend effort and time on something, which will not be used on all players ? Perhaps better way is to use DirectX 11 physics (http://en.wikipedia.org/wiki/DirectCompute) as a base (works on all DirectX 10 and DirectX 11 capable computers). The same is used also in Futuremarks 3Dmark (http://www.3dmark.com/wp-content/uploads/2010/12/3DMark11_Whitepaper.pdf). They are usin "Bullet Open Source Physics Library C++". So i think, that is the way to go, to use common interface/api avaiable on all computers capable to run Arma3 (Nvidia, Amd, Intel ...any DirectX11 capable graphics card), and also using open-source Physics Library when needed. Have a nice day and thank you for great and i think bigges revolution in those latest betas.

BIS please, provide some connection for ACRE modification (contact Jaynus) to EXE code. We are unable to test any betas, becuase they are not supported by ACRE, and we are not willing to play anything withouth ACRE. Jaynus is not willing to spend his time for "searching address for hack" new betas, this take too much time. So, can be there some support from your side ? Or just everytime when you release new BETA (exe file), send him correct address (which he need), for you is that only few second to see into source code (dobug output). Thank you.