• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

MSFS KAP 140 autopilot

Hello experts,

I am using the Lionheart Creations TB21 GT Trinidad, I love this aircraft because I used to fly its little brother IRL, the TB-9 Tampico. The problem is that the autopilot does not work as expected, I can even say it doesn't work at all. It works for maintaining altitude, which proves it is correctly intgrated in the panel, but lateral modes (HDG/NAV) do not work at all.
I know this is not a support forum for commercial products, but I was hoping that with my knowledge in panel and gauge development, I would be able to fix this by myself, especially because this aircraft uses the standard KAP 140 autopilot provided by Asobo and used in many aircraft such as the Cessna 172. I must also say the support didn't reply to me :(
This autopilot works perfectly in the C172 but not in the TB21. I checked the panel.cfg and the KAP 140 is declared as expected:

size_mm                = 512,105
pixel_size            = 512,105
texture                = $AS140_Screen
htmlgauge00=Generic/Autopilots/KAP140/KAP140.html,                           0,0,512,105

This part of the panel.cfg is EXACTLY the same as the C172, this is not a surprise.
I also checked the interior model XML and found this, as expected:

        <Include Path="Asobo\NAVCOM\KAP140.xml"/>

I also checked the sim variables using the SimVar Watcher and it was looking consistent, for example here I engaged the HDG mode, the variables look OK, but the aircraft do not follow the expected heading at all.


Everything looks normal but the AP does not work and it makes me mad because I don't understand why the same autopilot used in 2 different planes works in one and not in the other.
If you have any idea, I would be glad to know :)

Yes, I checked it and found nothing wrong. I also checked systems.cfg and obviously panel.cfg.
Do you think there something specific I should check in these files?
Not particularly. I thought about it because that's an error that I have made in the past on more than one occasion.
This sounds more like an Asobo issue than one of support anyway. I'm just barely wrapping my head around gauge implementation, but the few declarations you've identified are all that is required to enable a gauge. I can't even suggest sidestepping the addon and accessing the gauge directly, because the addon already does that. You could do a VC spoof, swap your interior model for the Cessnas to see if that enables functionality and if so, I am going to guess it is a situation of some specific node name or term which the Cessna has that the Socata lacks. A hyphen instead of a semicolon or an extra space before an ampersand maybe.

Your solution would likely be a cockpit modification addon project using your own autopilot gauge or correcting whatever mismatch occurred between TB21 and KAP 140.
I finally solved the problem. It was not an Asobo issue, it was a poorly designed panel. In the panel.cfg, I found 2 VCockpit sections that were referencing a PFD and an MFD, which were not in the cockpit. I removed these 2 sections and it now works perfectly. I believe the panel designer didn't know exactly what he was doing there... I am in contact with Bill from Lionheart Creations, I told him all this but I still have no reply from him.
Anyway, the aircraft now works well with its autopilot.
Hello Eric,

I did write you. Maybe it got caught by a Spam folder.

It was my understanding that this was a Asobo issue. My Cessna 172 Classic with the KAP 140 presently isnt working since the SU14 update and WT updates. It is still not working.
I did quite a bit of testing on Monday on this through to the evening. I posted my findings on Facebook on my Lionheart page and also on the MSFS DevSupport site where I filed a Bug report. I had noted this in a Question report on the AP and issues with NAV/GPS being broken on the update, but nothing was done. I upscaled it to Bug report (I didnt know you could do this with custom addon planes), and am waiting for them to act on it.

On Monday, I found that if I deleted the Trinidad and GNS530/430 Version 1.1.4, rebooted, redownloaded the Trinidad and GNS530, rebooted again, and then loaded a flight, the AP was once again working fine, but still not working in the Cessna 172. I ran SimStaller to verify if nothing (no other addons) were cross linking and messing up the system. I had heard that MSFS installs things in stacks, and thought, perhaps if I delete, reset, reinstall, they would be at the top of their stacks. I did and it worked. Not sure if this is a actual issue, but for me, it fully restored the Trinidad AP system and linking to the 530 and 430 perfect, but the Cessna Classic still doesnt function on its KAP 140 AP.

This is my findings I published on my FaceBook LHC Page;

This is my bug report at the MSFS DEV page;

Thanks for finding the posting the bug on the dual entries of the G1000's (MFD and PDF) that are WT. We were surprised to find those two entries in there. I do not care for WT due to quite a few bugs in the past. But in going through the (now ancient) Panel config, we found some other issues which are left over Legacy code from FSX. Cleaned that up... But how did those get in there??? Doesnt make sense. There is not a G1000 screen set in the plane, and I 'never' use WT. odd.....
Glad you got yours working.

You can see screenshots and notations of the testing I did on the Trinidad and also Cessna 172 AP's and GNS's and NAV/GPS linking. I noted that if the Version 1.1.4 version GNS screens were deleted the AP worked. If it was reinstalled, the AP's were offline (both planes). But when I deleted and reinstalled the Trinidad 'and' GNS, the AP was restored. But the Cessna continued to not function. strange....
Hi Bill,

Indeed, I received your message on messenger, but I added the information also explained here with additional questions :)

Anyway, I am very surprised because what I have on my MSFS is very different. On my system, the C172 and its KAP 140 always worked fine, which is why I was wondering how the same autopilot (the same code) could work fine in an aircraft and not in another. This is what pushed me to find a solution. Then I realized some parts of the panel.cfg were looking useless. I may be wrong, and I would be glad to have a confirmation from you, but it appears the TB21 now works perfectly.

In addition, I would like to share an experience with you: during my tests, I set the developer mode to easily switch between the C172 and the TB 21 using the "select aircraft" function. I started a flight with the TB21, the AP was failing. Then I loaded the C172 and the AP was failing too. Then I stopped the flight, back to main menu, and started a new flight with the C172. Then the AP was working well. It means that when you start the flight with the TB21 (before fix), I guess it screws up something in the sim so that the KAP 140 does not work in any aircraft. This is why I told you in my Messenger message that you should restart a new flight each time you make a change.

Anyway, please have a look at the fix I proposed here because it solved the problem on my system. I can't believe it is different on your system, unless you have other add-ons that may impact the AP behavior. If so, you should test it by keeping only the TB21 in your Community folder.

Hope this helps...
I would like to share an experience with you: during my tests, I set the developer mode to easily switch between the C172 and the TB 21 using the "select aircraft" function. I started a flight with the TB21, the AP was failing. Then I loaded the C172 and the AP was failing too. Then I stopped the flight, back to main menu, and started a new flight with the C172. Then the AP was working well. It means that when you start the flight with the TB21 (before fix), I guess it screws up something in the sim so that the KAP 140 does not work in any aircraft.
Another equally valid interpretation, is that TB21 fails to initialize the start of the flight plan, preventing C172 or any other aircraft autopilot from completing the flight plan. I absolutely would have tested the inverse expecting the reverse; starting an autopilot flight with C172 and then switching to TB21 allows the autopilot to function as intended.

Also, I am all for sterile environment testing, but suggesting that interference in a developers Community folder is causing his addon to behave unnaturally better, or misbehave differently due to file conflicts in the VFS, is kind of reaching. The other side of it is that developing is boring. I spend hours just dialing in one suspension strut or whatever and if some yahoo buzzes me in a Top Gun F-18, I sometimes want to be able to jump into Waverider and go run him down. As to the Community folder interference, two things to consider: conflicts are entirely name driven. All this means is that if two addons are using the common directory "modellib," the directory belonging to the addon with the highest alphabetical priority might be used, instead of the one intended. Nothing is overwritten or modified, all "manageable" conflicts arise at the Community folder level, the deeper ones are all Microsoft/Asobo creations. The second thing to consider is that scanning for these naming conflicts is extremely easy for conflict prevention tools and if someone is using one, you can consider that possibility to be accounted for.
Hey Eric,

Roger that, and I just found out about this through another person at our Discord, I was posting it here and its the same as what you just posted. Rebooting the flight fixes the AP.