Project-Hatchet
Bug: AFM Desync Causes Unusual Rotation on Ground
Bug Report
Description:
In a Multiplayer enviroment with Pilots on AFM, after the Blackhawk lands, it starts desyncing for other players (Passengers + players on the outside). Desyncing like dancing on it's tail, nose, Lowrider Moves, rolls to the side, collides with ground. As soon the Blackhawk leaves the ground, its all back to normal.
Expected Behavior
Steps to Reproduce the Issue
- Have a dedicated Server
- Have somebody fly in AFM
- Have the pilot land somewhere
Troubleshooting Steps Taken
- Repaired the Mod - Nothing
- Tested Development Version - Nothing
- Getting out / Getting in sometimes fixes it for a short time
- Lowering View Distance to Zero back to normal fixes it for a short time as well
- Tried lowering ground contacts in the AFM Config (Only improved performance, nothing to reduce lowrider)
Screenshots
Apologies, still gettin' used to Git, but after my update on Tuesday regarding the two separate tests going out well and assuming the issue had been fixed, I managed to get the updated pack uploaded onto a unit server and ran with a common load and ~15-17 players active and moving.
Unfortunately it seems the issue still exists when a high network load is present. Similar to our previous discoveries and other reports. The simple action of jumping out when an airframe is started and hot, and jumping back in while hot (or when controls are passed between pilot and copilot) caused the issue to appear in a occupied server environment.
I have a slight hunch this 2.20 update to the Stable Branch of A3 did bring around fantastic changes to the multi-threading, but I believe it also made it harder for the issue to be present in a lightweight environment (where 2 testing players are present, with only the required mods loaded [CBA_A3, Ace, Hatchet]). It basically negates my artificial 'blackfish' method that worked previously to raise the network load, which in theory is fantastic, but when under higher stresses like high player count and other taxing mods running could overload that higher cap if you will.
We re-ran the test to be absolutely sure this was the case. We had the Swiss gentleman host two separate packs, one with only the required mods by Hatchet, and one with it included running with a unit mod pack [The unit in question runs the workshop version of ACE and CBA_A3]. Both events only had two players. An observer, and a pilot.
In the first instance, with the only thing running on the server being the required mods, when we tried to artificially raise the network load via the originally functioning blackfish method, we would ourselves lag to the point of nearly being unable to fly the airframe (~2-6 FPS) and test it, and it wouldn't occur in any test we'd attempt. What we did catch was the following in this test; It seemingly began, but then stabilized. Very faint, but noticeable before disappearing.
In the second instance, we ran it alongside a unit modpack, did the exact same approach, and this time it seemingly returned in the same intensity we had seen it before. (I assume the original H60 reports channel wasn't deleted but archived, we recorded clips of when we had run the tests with just the required mods, similar intensity and cause).
Clip of the latter instance testing: https://medal.tv/games/arma-3/clips/kzkdMCUhv5lAL_RxT?invite=cr-MSwxdjcsMTIyOTAwODg5 [The lag in the initial portions I'll chalk up to just me running at low FPS, but the 'low-ridering' is nearly identical to previous testing].
I'm keen on providing as much data as possible, so hopefully we'll be able to continue running these tests, while we also figure out on an actual proper approach to artificially raise the network load to a point where I could possibly test my hunch/theory previously mentioned, alongside proper graphs like the German(?) gentleman had previously provided to assist as best we can.
Really appreciate your approach. Do vanilla afm helis behave similarly under such conditions? Also I wonder if using the server fps limit set to very low could help you reliably recreate conditions (really not sure).
Really appreciate your approach. Do vanilla afm helis behave similarly under such conditions? Also I wonder if using the server fps limit set to very low could help you reliably recreate conditions (really not sure).
From in-game events we've attended, having multiple Hatchet airframes alongside other AFM helicopters (for example the RHS MH-6M) and the TF373 MH-47G, we have not seen this issue affect those airframes in any fashion. We'll give the server FPS limit a go, we'll verify if it hopefully works in our favor.
Can you also post your server specs and server.cfg
I've forwarded the question to the folks in question, I'll hopefully have that information for ya soon enough.
Canadian-based UNIT dedicated server:
- CPU: Intel(R) Core(TM) i7-8700k @ 3.70GHz
- Mem: 32GBs of DDR4 RAM (Quad Channels(?)).
- GPU: GTX 1070Ti
- Arma 3 server is being run off a Samsung SSD [1TB].
- Internet specifics: Wired connection - 9ms Latency - 940.45 DL - 190.22 UP.
UNITDedicatedServer_Config.txt
Canadian-based testing dedicated server [separate individual]:
- CPU: Intel(R) Core(TM) i7-10700KF CPU @ 3.80GHz
- Mem: 48GBs of DDR4 RAM.
- GPU: RTX 3060
- Arma 3 server is being run off a Samsung SSD 980 PRO [2TB].
- Internet specifics: Wired connection - 13ms Latency - 738.13 DL - 170.66 UP. At the time of testing all the assets were purely dedicated to the testing.
SeperateDedicatedServer_Config.txt
Still waiting to get the information for the Swiss gentleman's server details. [Had to change the server.cfg files to txt since GitHub doesn't allow .cfg files].
Both servers run the same basic.cfg with identical settings. If the third has any changes I'll specify em'.
Both servers run the same basic.cfg with identical settings. If the third has any changes I'll specify em'.
I’d muck around with maxMessageSend (try 256, 512, 1024) and maxSizeNonguaranteed (try 256 & 1024)
Use #monitor (when logged in as admin) to monitor dropped packets
Arma 3 discord has some resources for basic cfg tweaks, although, there’s a lot of misinformation out there so take it with a grain of salt.
Swiss Based Server: CPU: Intel(R) Core(TM) i9-10900K CPU @ Stock) Mem: 64GB of DDR4 3000MHz. GPU: Intel ARC 380 Windows 11 / Arma 3 server is being run off a Samsung SSD 950 PRO [500GB]. Internet specifics: Wired connection - 2.5GBE to 10GBit Fiber (Up/Down) basic server.cfg by FASTER
I’d muck around with maxMessageSend (try 256, 512, 1024) and maxSizeNonguaranteed (try 256 & 1024) Use #monitor (when logged in as admin) to monitor dropped packets
So very early on when we were first becoming aware of this issue we did play around with the basic.cfg file heavily. We'd tweak single line values in a not-good attempt to see if it was simply a issue of bad connections to the servers at hand.
I managed to find the old basic.cfg we ran on the 2nd testing server where we ended up changing values I honestly believe had no bearing on what we were working on at all in an attempt to track down the issue. Attached for viewin', but all roads led to encountering the same issue.
We didn't really see a change back then, but I'm willin' to give it another shot soon enough.
We have run #monitor in the past, but never saw a difference above ~0.2-0.4 for both outgoing and incoming packets. I unfortunately, in my infinite wisdom, wrote the values for incoming and outgoing packets on sticky-notes I later disposed of after I noticed little change between testing changes of the basic.cfg once I averaged out the difference. I can definitely re-run the tests if those exact values would be of use.