MSFS Products

Hi Mark... Uninstalling and reinstalling worked... no message about out of date nav data... thanks, Rob

I found the POH online that I believe this procedure is from, and it describes a 1970's Baron. I see no reference to this system in the late model Barons after the 1984 redesign. If I'm reading between the lines correctly, I think this is also an antiquated safety system, which requires the pilot to manually disable the autopilot and/or trim servos via another switch on the panel while simultaneously holding the disconnect switch, as the yokes equipped with this trim disconnect button do not have the now common two-stage AP/FD disconnect button. I imagine this is still somewhat common in 60's and 70's airplanes today, but I have yet to encounter one. You learn something new every day!

WORKING FINE NOW

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

Nothing further to share on this at the moment. It remains something we would like to add to our aircraft in future updates, but there is no timeframe we would be able to share for that. Mark - Just Flight

Hi Mark, thank you for your reply. I just tested for about 2 hours. It seems, that GSX might be responsible as I was only able to reproduce this, when I was boarding the plane via GSX. If the APU is running the EGT spikes from 400 to 600 almost as soon as the first passenger visibly boards the plane. From there it jumps around a few times. This stops when the APU EGT goes down to about 100-200°. Then only a change in the APU load restores the correct EGT. It doesn't matter, if the APU Air/packs/recirculation/grnd air/ground electric/ is on or not. It is reproducable every time. Also I was able to also induce these spikes while boarding with GSX, when pressing F1 to get to the outside view, press right mouse button to move the view around and then press F1 again. Then the EGT also goes crazy. I made a video of this. But this can only be done, when the first passenger has boarded. When I wasn't using GSX, everything was ok and as expected. So now I'm wondering, how GSX could have an influence on the APU EGT and if this issue can be solved without the GSX team. @Mark Should I still open a ticket with Just Flight Support? Thanks in advance. Best regards, Chris

Another one missing which is a unique livery SunExpress ICAO Code SXS IATA Designator XQ [image: 36d0818f-b00a-4945-a4ad-23c204fdd3b6.jpg]

Please see: https://community.justflight.com/post/46913 Mark - Just Flight

@Mark said in Aircraft Configuration Not Saved in MSFS2024: All of the items listed are included in our state-saving logic (and I have seen them save/recall correctly in the current build), but there is something which is causing discrepancies with the state saving with each load of an aircraft in a session. It's something we are actively investigating across various products. Mark - Just Flight @Mark Thanks for the heads up about the other thread. I have commented on that one as well and put in on watch in hopes something will turn up one day about it being resolved, or at least a work around of some sort. Although, as things tend to trend with MSFS from version to version, it might just be broken the next update. It's interesting that you mention you have seen them save/recall correctly in the current SU4 build; I would believe that. When testing earlier, there was an inconsistency in the behaviour of state saving, as not all items saved and recalled correctly on the first try. During the initial tests mentioned previously, the Fuel Pump Switch state reset back to OFF, even though it was switched ON before exiting the flight. However, all of the following tests it would remain in the ON or OFF state as expected upon save and restart. Likewise, the Transponder Code wouldn't always reset back to 7000, but would rather reset back to another value such as 2000, 7004, along with the standard 7000 - it would never set back to the pre-save value of 1200 though. The inconsistency adds to the frustration and makes it more difficult to debug, especially if the person trying to debug it doesn't have the code in front of them. Question for you and others on this thread: Have there been any workarounds that seem to result in an improved state recall, or has it just been inconsistent no matter the method? Thanks.

@Derek said in PA-28R Turbo Arrow IV FS 2024 displayed wrong: Have you tried contacting Just Flight Support about this? It sounds like the kind of problem they could advise upon. https://community.justflight.com/topic/2/product-support Thanks, and sorry to the forum, I have sent a ticket, maybe this post can be closed.