@Mark Thank you! I'm going to try and map them to raw buttons first, then I'll see if I can go through FSUIPC or something to get them onto my axis. If I get this working well, I will see if I can make a blog post or video for other users

In addition to the @GroverJ41's fantasitc reply above, we also have a tutorial flight from Page 153 of the F28 Professional Operations Manual that will walk you through an entire flight in the aircraft: https://downloads.justflight.com/products/JFF003039/F28_Professional_MSFS_Manual_v2.2.pdf We also have a 4-part video series on our YouTube channel that covers that tutorial flight: https://youtu.be/zZQf0yjYHtw Mark - Just Flight

Thank you for taking the time to provide some detailed feedback. I have logged all of this feedback on our internal trackers for our flight model developer to take a look at ahead of the next flight model update to our PA28s. Mark - Just Flight

That's not a behaviour I recall seeing reported before, and it shouldn't be possible to deploy the lift spoilers in flight, so it sounds like something that could be caused by a controller conflict. The first thing I would recommend checking is if you have any "SPOILERS" control assignments being inadvertently triggered by your external hardware (TOGGLE SPOILERS, SPOILERS AXIS, EXTEND SPOILERS, etc.). For reference, the conditions for automatic lift spoiler deployment are listed on pages 79-80 of the RJ Professional Operations Manual: https://downloads.justflight.com/products/JFF003765/RJ_Professional_MSFS_Operations_Manual_MSFS2024.pdf Mark - Just Flight

Unfortunately, as you say, I believe this will be a limitation of using Chaseplane with some of our products. The Vulcan, and a few of our other products, rely on the core MSFS camera system to move the user to certain locations in and around the aircraft. As Chaseplane overrides the default camera system, the cameras that we trigger in the code no longer exist, so the camera will not change. It's something we have logged on our internal trackers for further investigation, and to see if there is any form of a workaround we can find for Chaseplane users. In the meantime with the Vulcan, it should be possible to create custom Chaseplane cameras inside the AEO/Navigrator compartment and then trigger those via the Chaseplane interface. Mark - Just Flight

This isn't something I recall seeing reported previously, but if this happens again, could I kindly ask you to raise a ticket with Just Flight Support via the following link: https://www.justflight.com/support In the ticket, if you could provide further details on when this behaviour is observed, then we can begin to log any further instances of this to see if a trend starts to emerge. Mark - Just Flight

I will do. Thank you, Derek.

For a 1985 p baron?

@Voice-of-Reason i contacted Microsoft and i have the 2020 version now.

OK solved it.

I was wondering this as well

That makes sense, and I appreciate the reply. I'm only using the 750 or 530 versions, for reference. However, I believe the problem is something like not having all the AIRAC data properly pushed to the sim (I don't know the proper terminology for this, so...) The reason I say this is because I ran the same type of LPV RNAVs into several different locations and found no issues, went back to the airports near my home, and found issues... tried to reset the plan while in the plane, tried a simple ESC, RESTART the flight -- and suddenly it works as intended! So it seems as if some approaches simply don't populate the sim/GNSS system properly on start up, and sometimes they do. I suppose this may, or may not be something that you have any control over.

I am flying across Australia with the Baron currently so I will be testing it out more in the coming days. I departed Perth and discovered that my auto pilot had failed so I got to hand fly the Baron at lower altitudes for a couple hundred miles. It hand flys like a dream, like it should. Honestly, I didnt think of this as being a bug since there was a backup that I used for a bit while I tried to troubleshoot. I got to see the pulse oximeter and the ear discomfort in action as I dump pressure and finally when the rate knob started working correctly. I did take a couple of photos but next time if it ever happens again will get video footage. Since I was on AP at cruise and I follow ARROW, I do have both a printed out BS Baron manual (my boss would thank you for the printer friendly version if she knew I used the company printer for it) as well as I pruchased an actual B58P manual in my simpit. So I tried to trouble shoot while in cruise. I also tried to use your YouTube videos to trouble shoot it. (Crazy how great cell service is at FL190 in the Australian outback as if I had Starlink internet ). Heres some pics from the flight that shows what I saw. https://imgur.com/a/FitL40J There should be 4 pics to that link.

@jmarkows All aircraft except the Analog Series and the Velocity have this code. That's what allows me to do the gyroscope physics simulations that you may have seen in my YouTube videos.

Thank you for the kind words. For future reference, you may be interested to know that there are tools within MSFS Developer Mode that can help you find LVARs for any control in any aircraft. With Developer Mode enabled, if you move your mouse to the menu bar at the top of the screen, and navigate to: Windows > Behaviours > Local Variables. Entering instrument names or abbreviations into the ‘Filter’ field will vastly speed up the process of finding LVARs. For example, if you are trying to find the LVARs used for the transponder, you can search for ‘XPDR' and you will find the following LVARs: "PED_AFT_XPDR_MODE". With the Behaviour debug menu open, it is also possible to automatically populate the "Filter" field with the LVAR name of a specific control. With the Behaviour debug menu open, move your cursor over any control in the cockpit and then press [CTRL]+[G], to populate the "Filter" field with the LVAR name. Hope that can be of some use. Mark - Just Flight

If anybody is wondering. The problem went away when switching from TAA to DLSS (both the old and the new version). Not sure if I will stay with DLSS, but for now that's what I'm using either way, so it's fine.

Cruise climb it is ;). Another quick question - what's up with Vr in the Turbine Duke (102)? The other airspeeds are relatively close to the piston Duke. The only thing I could think of it being able to counteract the torque in an engine failure needing the higher airspeed but it's even higher than Vmc. Tried finding a POH or info for the conversion but couldn't find anything out there (outside of your manual).

@Mark It was well within crosswind limits. I don't have tiller hardware. But there was no dead zone, so I'll try adding that to see it it helps.

Thank you, @gazdav787 , you've given me the clue I needed! Besides those variables, I've identified these ones: The buttons can be toggled using R_TRP_Climb, R_TRP_MCT, R_TRP_TOGA and R_Mstr_Climb. Send a 1 to those values and button will change state if it's possible. State of the buttons can be read using R_TRP_TOGA_redu_il1, R_TRP_TOGA_redu_il2, R_TRP_TOGA_redu_il1, R_TRP_Mstr_eng1_il1, R_TRP_Mstr_eng2_il1, R_TRP_MCT_il1, R_TRP_Climb_norm_il1 and R_TRP_Climb_max_il1. Each variable maps to a different state. Value of the display can be read using JF_RJ_TRP_Display_Value. Thanks!