[image: 06ca91cc-1d56-4421-9b97-ea5cb34614ab.png] [image: dada85dc-d29d-46aa-a5e9-5082d946aa3e.png]

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.

@eracer1111 said in I'm confused about some of the BKSQ variables.: I own 13 Black Square aircraft I'm glad someone is keeping count Thanks again, and let me know if there is ever anything else I can do for you!

Many thanks for the update. I’ll be glad to get my affected JF planes back.

Controller profiles are something that is handled entirely by the simulator, and we don't have any influence over. MSFS 2024 allows you to have separate control schemes for each aircraft, which may cause the difference in controller profiles you're seeing. I believe there is also an option to "Apply to all aircraft" when creating a controller profile, which will apply the same profile to all aircraft, like how MSFS 2020 handles it. Mark - Just Flight

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.

Enroute to Eagle CO with a setting sun. There just is no bad angle to take a pic of the Starship. [image: 9c8aed1c-3a42-4a13-9da6-4952e7a7bc8f.jpg] [image: 31496acf-8423-41d8-b33f-1d9fc9640bc1.jpg] [image: af4c6d16-f5de-4d08-b6be-50c80a64c826.jpg] [image: 60834b36-8759-45e4-b760-d0d77e16a2ed.jpg] [image: 8db7bc74-80a6-4a65-8d6b-7e2082571e2f.jpg] [image: afbb3a97-fbe1-44bf-9b10-ba1e28dd0605.jpg] [image: 6281c7b0-61b9-401e-bef2-04caf1c97092.jpg] [image: 0c447610-1afb-4b04-bf96-9a1e34e0afa3.jpg]

It certainly does sound like a control binding problem. Since the Velocity is a relatively simple aircraft, I would expect the virtual switch position to match the hardware position, but anything is possible with software. Have you tried disconnecting all hardware to see if everything works correctly when triggered from the cockpit?

Any updates?

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!

Oh OK, thanks. Would be much better if you could assign unique registrations to each livery (as you say, the UI definitely gives this impression). Odd, because before you change the number to one of your choice, all the original reg numbers are different livery to livery (from memory). Cheers.

Glad it's working well for you, and glad that my suggestions were over the target. Thanks for letting us know for anyone else who might search with a similar problem! A great weekend to you, as well