AeroMaster12

Happy to help contribute wherever I can!

Took my second flight with PSXT 14.5 and the new RT 11 update (assuming it's been pushed). When I landed at KATL, I saw an unexpected Ryanair B38M aircraft taxiing. Looking at the logs, somehow an aircraft registration (belonging to Egyptair) was being treated as a flight number, and then it decided to spawn a Ryanair aircraft with a route label completely on the other side of the world... sorry to report this one-off if it's noise, but wanted to raise awareness in case something like this is happening to others. When I pulled these logs, both the aircraft EI-IGY and SU-GEH were currently positioned in Egypt and Portugal IRL, respectively Restarted PSXT and it shows up in a fresh session (lol). Something I'm noticing is that there are some models that are connecting the aircraft type with an invalid variation name, like N963DZ: AIGAIM_Delta Air Lines Boeing 737-900SSW - SN ex-Lion Air B739. =2= AIGAIM_Delta Air Lines Boeing 737-900SSW - SN ex-Batik-Malindo Air

I believe landing gear is impacted by OLOD. In my case with VR on a 3080 GPU, both my OLOD and TLOD are automatically set to below 100 at busy hubs in order to get stable performance. Actually, let me try forcing the minimum to 100 to see if the landing gear bug is a problem, or if I can deal with that performance hit.

Yeah, that's very possible. Since I fly in VR with AutoFPS, my LOD could dynamically be set to a much lower value (like ~10-30).

Hey Nico, I know that AIG and FSLTL models suffer from a bug in MSFS 2024 where planes look like they are floating due to a low LOD on the landing gear polygons. However, I was stumbling around the MSFS forums and came across this post from a vPilot dev where he discovered a workaround. By setting the simvar for gear extension percentage to 1% before sending a gear-down event, he claims that this workaround has mitigated the problem. Others claim they now see landing gear from that workaround in the vPilot beta release. * https://forums.flightsimulator.com/t/too-strict-lod-rule-on-aircraft-landing-gears-culling-of-aircrafts-gear/709715/231 Just curious - is this a value/workaround something that PSXT can set on planes that are just about to land (or apply to those that are on the ground), or would this have no effect?

Pretty much any add-on that operates outside of the sim has to use SimConnect to make calls for the simulator to do something, so yes, LittleNavMap, ActiveSky, Navigraph, any traffic injector, etc. also uses SimConnect. I actually had CTDs only when I was using an outdated version of LNM, where if I had left LNM open at a large airport for a long period of time, I'd get a CTD. Those went away when I updated LNM though (but I rarely use it for my flights) I primarily only use GSX, PSXT, and Navigraph. PSXT has been very stable for me for months at this point, and it works for me for airports large and small. My recent flights have been to/from: EBBR, KIAD, LSZH, KLAX, KSEA, KMIA, LTFM, KDEN with no stability issues

Do you know what other addons/modules you have that would heavily rely on SimConnect (e.g., FSUIPC)? Just speaking from my personal experience, I only use GSX and PSXT never had crashes either in 2020 or 2024 (not to discredit your experience at all). But if the problem started in MSFS2020 and carried over, it sounds like there's some other addon that's causing SimConnect conflicts, and since GSX is fully disabled, it probably is something else that isn't playing nice. If you do have other SimConnect addons, try disabling all of those and use PSXT exclusively. Then slowly add them back in one by one until you find the one that's causing problems So when PSXT "restarts" even though the application still runs, it creates a new log file. I think you sent in the freshest log file from when it restarted, which didn't highlight the problem (it looks normal). Could you find logs from Log0, or Log00 that shows the SimConnect issue?

Something you might want to also check just to be sure. I think AIG references a specific soundai file/package for many models, and to save disk space having duplicate files in every folder, they use a symbolic link (symlink) that points to the file. Even though it might be present in the file directory, try to check if you can navigate to it. If you get an error when trying to open the soundai folder, that can also be a culprit. I ran into this issue when I was trying to move some folders around; moving folders that contained the soundai symlink folder caused that link to break

Ooh, I missed this update - good to know. Let me recreate the file from scratch. I also remember that if an invalid spot was selected before, that it would warn about an error when reading the file, but for some reason I no longer see that warning. Regarding numbers, which UI do you use to identify the parking number (GSX, LittleNavMap, MSFS SDK)?

Hi Nico, I'm wondering if the Reserved Stand (my_park_airports) feature is still supported. I noticed that shortly after the archived airports were reconfigured that there were times where a gate that I had put into the my_park_airports.txt file were not being honored. LSZH,26 Even though I added the airport and stand in the file and clicked "Re-read", PSXT wrote "parking and stands okay", however upon arrival at the airport, there was an AI aircraft parked in that spot. The only way I can "remove" the plane is by taxiing into it, or using GSX's "remove AI traffic from gate" feature (which sometimes causes PSXT to immediately respawn the aircraft) Here are some logs if they help (problematic line in bold): When at the active airport in PSXT, it also didn't indicate the reserved stand in the status bar.

Hi Nico, Happy new year! This is just a minor ask, but I was wondering if you would be able to implement an exclusion of BGLs within a specific path. As an example, I have the BlackSquare Real Taxiways addon, and it looks like they use BGLs to place taxiway signs on default airports (or if a third-party airport does not exclude taxiway signs). As a result, my TBLO folder has ~2000 XML files, and I think a lot of that would be noise for you 🙂 These BGLs do have parking spots for some reason though, and because of this, it is treating it as a "TBLO" airport, even though I don't think it's necessary, since the parking should fall back to the default airport. Are you able to implement an exclusion list by either developer or folder path that would prevent these from being scanned? If so, then I would have a cleaner TBLO and can send you those results. BGL paths within ~/Community/*/*/*.bgl: bksq-scenery-realtaxiwaysbcde bksq-scenery-realtaxiwayeuro bksq-scenery-realtaxiwaysmil Example logs: Example XML output header:

For anyone else having a CTD at KSEA or other Pacific Northwest airports, keep your eyes on these threads - looks like an issue with the latest Navigraph nav data cycle. Workaround for now is to disable Navigraph for the time being until they can identify the root cause of the CTDs and roll out a fix Selecting KSEA causes CTD (2501.1) - Navigation Data / General MSFS Data - Navigraph 2501 rev.1 CTD's at default KSFB - Navigation Data / General MSFS Data - Navigraph

Hi Nico, Just reporting a minor file hygiene bug that I believe this started with 10.1.0 - on startup, when PSXT looks at airports for offline learning, it identifies some stock airports where they are not suitable for offline learning. In this process, it generates empty XML files, one for each airport, however it doesn't seem to clean it up afterwards when hitting this condition only. Here's what my directory listing looks like after PSXT starts:

A couple of drawbacks and concerns on losing the local archived airports: Unable to verify if a parking spot exists (depending on AFCAD, gates are numbered differently than what's published on Navigraph or other sources). We have to guess and test parking spot IDs if we want to reserve a parking spot at the destination airport in advance Unable to make adjustments or local changes to XML files to suit parking preferences (+1 to @vonSzuli) Now dependent on internet connection for statics traffic with no fallback in the event of a server or local internet outage For those who have a standard RT subscription, the price to upgrade to professional is prorated at the monthly cost. This is expensive for those who just started a new subscription and pre-paid for a full year of data. What was once available to all users is now being paywalled by a premium tier subscription is concerning. While PSXT's mechanism was built to help traffic history files using RealTraffic data, it opens the question of who is the custodian the data - PSXT or RealTraffic? If PSXT is storing and maintaining parking data, I feel that this shouldn't be paywalled.

Just as a sanity check, when you added the AIG package into your Community folder, did you also have PSXT rescan all of your aircraft liveries? If you had loaded PSXT once where it ran a model scan, but then added AIG models after that, PSXT wouldn't have picked it up