Autopilot After SIM Update 14
-
Unfortunately, changing the WT code as described above did not fix the issue for me. When the GNS 530/430 is selected in the plane, I still am unable to engage NAV to use VOR navigation . Altitude and VS did work.
Swapping in the PMS50 GTN to the first slot allows NAV to work properly. -
Did you encounter this issue immediately after updating to SU14? Given that I've seen this work for so many people now, I think we've likely found the sole issue introduced by that update, but that doesn't mean you're not experiencing one of the known GPS incompatibilities our outdated files. Feel free to share more details with me, or contact JF support. They've gotten quite good at tracking down the regular GPS product issues. I'm all ears.
-
I find that I cannot setup the AP to intercept and capture a VOR radial by putting the AP in HDG and ARMing NAV. NAV will not turn on when the CDI indicator is not in the active range (that is, when the CDI is all the way off to one side or the other of the HSI).
-
I to am in this Autopilot mess. Absolutely nothing works ie HDG NAV ALT, HSI is completely bonkers. however I discovered that if I load the way points from the MSFS world map it’s all good.
I’ve only had the aircraft 2 days so I’m a bit annoyed it’s not working really. Although I do admit it’s a beautiful thing to hand fly.
Am I supposed to install WT stuff myself? I assumed it would already be within the sim.
Cheers -
If you use any other GPS or none at all, the AP works fine... only the current 530 has this bug.
Im using the the PMS 750 currently and having no issues.@Lemny said in Autopilot After SIM Update 14:
If you use any other GPS or none at all, the AP works fine... only the current 530 has this bug.
Im using the the PMS 750 currently and having no issues.Ok thanks, unfortunately I'm not a fan of the 750 so hopefully the fix will be out soon.
I'm pretty sure V1 simulations had the 750 play funny a week ago, the AP flew ok but the HSI was completely bugged out. -
Just a reminder to anyone coming to this thread later, but you can fix the current GNS 530 bug with one copy-paste edit to one file on your computer right now.
I know that's not the most convenient solution, but for anything better, I would have to post the entirety of WT's work. I also worry about generating yet more "compatibility" mods in the wild for people to further confuse their installations with.
For those following along, I have not heard back from Working Title yet, as I suspect they are off for the holidays. I have heard that this solution is being discussed with the developers on their Discord, though. I will let everyone know when I hear back from them.
-
Thanks so much... My A36 Bonanza panel was broken... I could not even move the left GPS options switch and my GPS was missing. Now it is back!
-
I'm glad it's working for you guys. Sorry I didn't look into this problem myself even sooner. Trust me, it doesn't benefit me to have broken autopilots in any way, so I'm looking forward to an official fix from Working Title just as much as you are.
-
Thank you all for providing more information, and for the votes of confidence. I've dropped everything else I'm working on to focus on this right now.
I have good news! I was able to replicate what you were seeing, and I have found a single line to be the culprit in the new WT GNS. I don't fully understand why, but I am able to produce the bug with 100% reliability by toggling that line on and off. You were right that this could be avoided if the instrument was loaded as the primary on startup, and never unloaded by the aircraft's state saving. I'm very confident that this is the culprit, and the TDS issue was only a side effect. Luckily, this is very easy for you to fix locally, but I will obviously have to contact Working Title for a patch to be made. Please make the following change to...
...\Official\OneStore\workingtitle-instruments-garmin-gns\html_ui\Pages\VCockpit\Instruments\NavSystems\GPS\WT530\WT530B.js (and WT430B.js)
Search for "Update loop for the main screen", and replace the existing update function with the following:
update() { var _a, _b; const isPrimaryInstrument = this.props.options.navIndex === 1; this.clock.onUpdate(); this.props.backplane.onUpdate(); if (isPrimaryInstrument) { (_a = this.autopilot) === null || _a === void 0 ? void 0 : _a.update(); // Planner update const now = Date.now(); if (now - this.lastCalculate > 3000) { this.planner.hasFlightPlan(msfsGarminsdk.Fms.PRIMARY_PLAN_INDEX) && this.planner.getFlightPlan(msfsGarminsdk.Fms.PRIMARY_PLAN_INDEX).calculate(); // SimVar.SetSimVarValue('K:HEADING_GYRO_SET', SimVarValueType.Number, 0); this.lastCalculate = now; } this.gpsSynchronizer.update(); } (_b = this.vnavController) === null || _b === void 0 ? void 0 : _b.update(); if (this.currentPowerState === PowerState.On || this.currentPowerState === PowerState.OnSkipInit) { this.gpsSatComputer.onUpdate(); } }Once you have seen if this solves your problem, please tell me asap so that I can contact Working Title. Thank you all for working with me. I hope this is the solution. Good luck!
@Black-Square
Thank you for the code. Look like it fixed the AP. Working now. Thanks again...and wishing you a Happy and prosper New year. -
@Black-Square can you please give me a little description of where we would change the code
-
From my post above:
Search for "Update loop for the main screen", and replace the existing update function with the following:
This function should begin on line 22326 of WT530B.js, if you have the exact same version as I do.
Still waiting to hear back from WT, everyone... I'll let you know when I hear something. This timing with the holidays has been very unfortunate, I think.
-
Small remark. I can confirm that his modifcation definitely works for the BSq TBM 850. All AP problems were solved after replacing the two files. The downside is that the tablet of the A2A no longer works after doing so. Putting the original WT530B.js and WT430B.js back made the A2A tablet work again.
So make sure you store both the original and the modified files, so that you can use the appropriate ones for the plane you want to fly at that time. -
From my post above:
Search for "Update loop for the main screen", and replace the existing update function with the following:
This function should begin on line 22326 of WT530B.js, if you have the exact same version as I do.
Still waiting to hear back from WT, everyone... I'll let you know when I hear something. This timing with the holidays has been very unfortunate, I think.
@Black-Square Hello Nick, Thanks for the continuous support.
Does this also have effect on the state saving?
It does not seem to work currently with SU14.
I always close off MSFS by returning to the main menu and then exiting, but fuel state and avionics selection are still reset to default.Kind Regards, Andre
-
I'm glad it's working for you guys. Sorry I didn't look into this problem myself even sooner. Trust me, it doesn't benefit me to have broken autopilots in any way, so I'm looking forward to an official fix from Working Title just as much as you are.
@Black-Square the saving grace is how wonderful it is to fly 😁👌
-
I cannot imagine how that one line edit could affect the A2A tablet. Anything is possible with software, but I suggest that it is extremely unlikely.
No, this should have no impact on state saving. I have also noticed no change in state saving behavior since SU14, nor has any been reported to technical support. Trust me, I would love a magic bullet for state saving, as well. I have no idea why the Asobo recommended approach works so poorly for some users. For the record, it's not that the state does not get saved, it's that the saved variables get detected as valid, but load all zeros.
I am moving many of the most important features over to a different state saving technique that I have found more reliable for the Dukes. If it works well there, I will move over to that system for all aircraft. The TBM already uses this method for some features, which should make it slightly more reliable than my older aircraft.
-
I cannot imagine how that one line edit could affect the A2A tablet. Anything is possible with software, but I suggest that it is extremely unlikely.
No, this should have no impact on state saving. I have also noticed no change in state saving behavior since SU14, nor has any been reported to technical support. Trust me, I would love a magic bullet for state saving, as well. I have no idea why the Asobo recommended approach works so poorly for some users. For the record, it's not that the state does not get saved, it's that the saved variables get detected as valid, but load all zeros.
I am moving many of the most important features over to a different state saving technique that I have found more reliable for the Dukes. If it works well there, I will move over to that system for all aircraft. The TBM already uses this method for some features, which should make it slightly more reliable than my older aircraft.
@Black-Square said in Autopilot After SIM Update 14:
I cannot imagine how that one line edit could affect the A2A tablet. Anything is possible with software, but I suggest that it is extremely unlikely.
I just tested it. Made the changes in the 530/430 files and jumped into my Comanche. No problems with the Tablet. Neither with or without active 530/430.
EDIT: And just tried out the TBM and the AP is working as intended again.
-
Thank you for sharing. I hesitate to much such a strong declaration without testing it myself, but as I've become more knowledgeable about the WT GNS while making some of my own improvements, and that line really should not cause any external problems like that. Thank you.
