So, this was fun. I spent most of my waking time over the last 24 hours troubleshooting this issue.
TL;DR: The specific VATSIM problem is not an LoD issue. It’s some strange interaction between various simvars that only became a thing in MSFS 2024. (It may also be an issue in more recent versions of MSFS 2020, not sure, didn’t test that.)
I implemented a workaround in version 3.11.3 that is available in the Beta channel. I’d appreciate it if a few people here (that are familiar with the problem) could give it a try and report back here send me a DM or post a thread in the VATSIM forums with any feedback.
For those interested in the nitty gritty details, read on:
I started by trying to reproduce the issue using my test server with a very basic SimConnect test application that I wrote years ago to test various bits of SimConnect functionality. This app creates a single airplane floating in space at a designated lat/lon/altitude. It has buttons where I can turn lights on/off, start/stop the engines, extend/retract the flaps, and extend/retract the gear. I can use this app to send the gear up/down events or set the gear position explicitly with any value that I choose, from 0-100. (This value represents the percentage of gear extension, with zero meaning the gear are fully up, and 100 meaning the gear are fully down.)
I started by placing an aircraft about 10 miles away from my own aircraft. I then set the gear extension to 0%. I then sent the “gear down” event. This simulates a new aircraft coming within range with the gear up to begin with, then dropping the gear a bit later when established on final.
I then moved the camera up close to the aircraft, expecting to see no gear, but the gear were down, so I was not able to reproduce the issue this way. I tried moving my camera even further away before creating the aircraft object, but still could not recreate the issue.
I also verified that I could raise and lower the gear both by sending the events and by setting the gear extension percentage explicitly. Both worked every time, no matter how far away I was from the aircraft.
I then figured that there was probably something different between vPilot and this simple test app, and that this difference was somehow obscuring the issue. So I then tried using a target generator that I use for testing vPilot and my ATC client software, along with running vPilot to observe the traffic generated by this target generator. I was able to reproduce the problem right away with arriving aircraft starting at various distances from my own aircraft. As long as the aircraft started far enough away that its gear was up to begin with and then dropped the gear later as it got closer, the problem would occur and I would see no gear. If the aircraft started close enough that its gear was already down to begin with, then I would see the gear down. At this point the issue could still be related to LoD, so I kept troubleshooting under that assumption.
I then tried implementing my proposed workaround of sending the gear down event continually (every 5 seconds) assuming that the gear would come down once the arrival got close enough to my own aircraft such that the active LoD included the gear. However, the gear never showed up, even when the aircraft was right on top of my own aircraft. The only way I could get the gear to come down is if I set the gear extension percentage to 100% instead of sending the gear down event. This worked, but was not an ideal solution since this causes the gear to instantly snap down into position, which would look terrible for other nearby aircraft such as aircraft following close behind on final, or on a parallel final. (Though, because of other LoD issues that we’ve discussed here, you might not see the gear anyway, in those cases, but that’s a separate issue.)
It was bugging me that the gear up/down events worked fine for distant aircraft created by the simple test app that I used first, but not for aircraft created by vPilot. So I went through a process of elimination to see what was different between the two apps. Surprisingly, it all came down to the “airspeed” value that was set when the aircraft object is first created. SimConnect requires that you provide an airspeed value when creating an aircraft, but you don’t have to update this value continually after the aircraft object already exists. In my simple test app, I was using a value of zero for the airspeed. In vPilot, I use the aircraft’s reported ground speed (since we don’t have access to the airspeed of other aircraft on the network … that value isn’t sent through the server to other pilots or ATC … only ground speed is sent.)
Once I set the initial airspeed value for the object to zero in vPilot, the problem went away. I immediately thought maybe I was triggering some logic deep inside the sim where if you try to extend the gear with too high an airspeed, it would consider the gear to be damaged and wouldn’t extend the gear any longer. I remembered that earlier sims (P3D and possibly also FSX) had logic like this at least in some aircraft.
I then started experimenting with different speeds and found that the magic number does indeed vary by aircraft type. The maximum value for an A320 model from FSLTL was 209 knots. Setting it to 210 or higher caused the gear to no longer extend when sending the gear down event. (Explicitly setting the gear extension percentage still worked, regardless of the airspeed value.) A value of 185 was the max for the FSLTL dash-8 model. There may be other variables that come into play here, but I didn’t try to test all possible permutations.
Based on this, my assumption is that if the airspeed is greater than this magic number at the time the aircraft is first created, then it will prevent the gear from dropping using the “gear down” event later when the aircraft is established on final and the pilot drops the gear. (Remember that SimConnect only requires you to set the airspeed once at the time the object is created, and not continually as the aircraft moves around.)
If this theory is correct, then the gear should be down for any aircraft that is flying at a speed that is below this magic number at the time it is created, but still has its gear up. (Because if its gear was already down, vPilot would set the extension percentage to 100% to snap the gear down into place.) In other words, the problem would occur for the vast majority of aircraft that you encounter online, and it would only NOT occur for a few aircraft that coincidentally happened to be moving slowly enough when you first encounter them but the pilot had not yet dropped the gear. (Like maybe an aircraft being vectored onto the final approach but yet established on the glideslope.)
I then checked the SDK docs to see if there was a way to read the max gear extension speed via SimConnect, so that I could tune the airspeed parameter appropriately for each aircraft. I found a simvar called `REFERENCE SPEED MAX IAS GEAR DOWN` but that var was returning much higher values, such as 280 for the A320. I also found two variables that I could use to test this theory, which are called GEAR DAMAGE BY SPEED and GEAR SPEED EXCEEDED but neither of those were being set for these aircraft, so that kinda killed that theory.
I considered modifying vPilot so that it would set the airspeed simvar continually, not just when the aircraft was first created, but I had no way of knowing if this technique would work well for all aircraft, or at least a majority of aircraft, since I had no reliable way to read this magic number through SimConnect. So I discarded that workaround as an option.
I also considered just setting the airspeed to zero when creating the aircraft, regardless of how fast the aircraft was moving at that time. However, I was concerned that this could have unknown negative side effects in other parts of the sim.
Luckily, during the course of all this trial-and-error, I accidentally discovered that if I set the gear extension percentage to 1% just before sending the gear down event, it worked fine. So at this point I could choose from one of the questionable workarounds described above, or I could just set the gear extension percentage to 1% just before sending the gear down event, and hope that this would work for all models.
In the end, I decided to go for the latter workaround, since it seems like the option least likely to have unintended negative side effects. This workaround is now available in v3.11.3 in the Beta channel. I implemented this workaround for both MSFS 2020 and 2024, just in case the same issue finds its way into MSFS 2020 as well.
Again, please give the beta version a try and let me know how it goes by sending me a DM or posting a thread in the VATSIM forums. Thanks, all.