Andreas79

I wouldn't load every flight plan unless you really want global coverage all the time. With AIGTC the startup time is tied to how much it has to parse, so with all world plans installed a five or six minute load would not surprise me. For FSHud, I would still use method 1 if you want the denser active traffic: AIGTC running with the FSHud integration enabled, and FSHud set to External. Then trim the AIG install to the airlines and regions you actually fly most often. To me that is a better compromise than accepting the quieter internal AIG option just to save startup time.

Simicro's way is what I would try first for anything coming from SimBrief. Set the SimBrief ID in the PMDG tablet/EFB, import the OFP from there, then load it in the FMC instead of chasing the folder path manually. For Little Navmap exports, I usually do one quick sanity check after updates: save a simple route from inside the aircraft once, then look where PMDG actually wrote that file and point LNM's PMDG .rte export to that same folder. The package layout can move around a bit between sim/update versions, so using the aircraft-created file as the reference avoids guessing.

That kind of late vectoring is exactly the part that keeps me cautious with BATC for IFR. The voices and the radio atmosphere are nice, but for me the basic sequencing and separation still matter more than how busy the frequency sounds. I can live with an occasional odd taxi instruction, but traffic appearing head-on without ATC reacting would pull me out of it pretty quickly. That's why I still tend to use FSHud for my offline IFR flights. Less flashy maybe, but the vectoring and separation behavior is the part I trust more right now. If BATC gets the enroute side as reliable as the airport-area side seems to be getting, then it becomes a much harder choice.

For me the bigger immersion breaker is when the callsign pronunciation is wrong but the traffic logic is otherwise doing the right thing. I can forgive a generic accent much easier than hearing Air France or Qantas mangled while I am trying to follow a busy arrival. That said, I still care more about good sequencing, spacing, and usable vectoring than perfect voices. If they keep improving the pronunciation side without losing the traffic behavior, that would be a very good balance.

That is pretty close to why I still don't use BATC as my main IFR ATC. The voices and general atmosphere can be nice, but once descent timing, vectoring and traffic sequencing start getting messy, reliability matters a lot more to me than presentation. If they sort out the approach logic, runway changes and the occasional silent/stuck moments, I think it becomes a much easier product to recommend. Right now it still feels a bit too inconsistent for me from one flight to the next.

That scheduled traffic part is actually what interests me most. Live traffic is nice of course, but schedules by airport could make a big difference for day to day flying. If it works the way it sounds, you should not only see aircraft passing through, but also get more believable departures and arrivals around you at the airport itself, even when live coverage is thin. That’s the part I’m really curious to test, because if they pull that off well, it could make FSHud feel much more complete on its own.

I use Tobii and I still think it’s worth having for cockpit flying, especially IFR, but I wouldn’t buy it purely because SU5 might have fixed that freeze behavior. I haven’t tested that specific pause/freeze case enough in SU5 to say it’s fully resolved now. What I can say is the general head tracking side is very usable once you dial it in, and for me it feels much more natural than hat-switch panning. If that one freeze/pause behavior is the deciding factor for you, I’d wait for a few more confirmed reports after SU5 is out of beta.

This is the kind of update I was hoping they would eventually add. For me the interesting part is not just the live side, it is having scheduled traffic in the same ecosystem so the airports do not feel empty or random once live coverage gets thin. If it works reliably in day to day use, that could be a very solid step.

If you only want one, I'd go with the 737-800. For me it's the easiest one to justify because it gives you the broadest real-world route coverage and still feels like the core PMDG experience. The -600 is great if you specifically like the shorter classic-feeling variant, but as a first buy I'd still pick the -800.

On my setup, parked only usually means the sim traffic settings and the injector sequence are fighting each other more than an FSLTL model problem. I would load into the flight first, make sure the sim AI/live traffic options are set the way FSLTL expects, and only then start the injector. If the sim keeps forcing you to re-enable planes every flight, that sounds more like a settings persistence bug after SU5 than an FSLTL issue by itself. It may be worth checking whether those traffic settings are actually being saved between sessions.

I wouldn't run both full stacks at once unless you really enjoy troubleshooting. For me the overlap is where things usually get messy first, especially with model matching and parking. If you already have AIG and you're happy with the coverage, I'd keep that as the base and only add the specific FSLTL pieces that solve a real gap. For a rebuild, AIG GA/private plus the flightplans sounds like the cleaner option to me.

Interesting one. From the brief video it looks potentially useful if someone mainly wants better traffic presentation without building a full BATC plus FSLTL setup. The part I still can't tell is whether it is mostly a model and livery replacement for the default traffic system, or whether it changes the actual injection and traffic behavior in a meaningful way. If anyone has already tested that part, I'd be curious.

I think that is really the split here. For a planned IFR flight, BATC can still be perfectly usable for me because I care more about the ATC flow, spacing and vectors than whether every nearby airport is populated. But for ad hoc VFR flights or short hops, I agree it starts to feel too dependent on SimBrief just to make the world look alive. That is also why I tend to separate traffic and ATC in my head. If I want better airport life and model coverage everywhere, I would rather solve that with the traffic layer first, then judge the ATC side on its own merits.

For me the default MSFS live traffic still feels like a compromise rather than a real solution if model matching matters to you. At some larger airports it can look decent at first glance, but once you know the routes and airline mix the wrong types and liveries start to stand out pretty quickly. I have not seen enough movement yet to trust that Asobo is going to turn it into a really accurate traffic layer in the near term. If your main goal is visual live traffic, I would still look at PSXT first. If the goal is having AI traffic that an ATC add-on can manage more coherently, I still get better results from scheduled models and flightplans than from the default live feed.

Q3 2026 is fine by me if they use the extra time to get the flight deck details and handling right. Tom's point about the ailerons is exactly the kind of thing that matters on a 757. I'd rather wait a bit longer and get those small technical details correct than have it rushed out just because the market is impatient.

Yes, that is basically how I would separate it right now. If you want traffic that FSHud can actually sequence and talk to, I would go with AIG flightplans and models. If you want to mirror real-world traffic visually, PSXT with RealTraffic can still do that, but I would treat it as a separate goal rather than something FSHud will manage end to end.\n\nSo for me it comes down to what matters more on that flight: realistic live positioning on the screen, or having the ATC side actually own the traffic picture.

I don't think FSHud will automatically populate its own traffic picture from PSXT/RealTraffic the same way it used to when people were relying on the older FSLTL flow. If the aircraft are visible in the sim and in RealTraffic, but not really showing inside FSHud, that sounds more like PSXT is driving the visual traffic while FSHud is not the system controlling it. If your goal is traffic that FSHud can actually manage, I would try the AIG route first. If your goal is just having live aircraft around you visually, PSXT can still do that, but I would not expect the same handoff inside FSHud.

If you mainly fly third party IFR add-ons, I’d probably go Standard and put the price difference into the aircraft you know you will actually use. The higher editions make more sense if you specifically want the native 2024 versions of the included aircraft, or if you know you care about the Local Legends and Famous Flyers discount. For me it would come down to one simple question: will those bundled aircraft become part of your regular flying, or just hangar filler?

Same here. SU5 is the first 2024 build that has felt consistently smooth for me in the kind of flying I actually do. I’m mostly in airliners and business jets, and the big difference is that busy airports finally feel predictable instead of turning into a stutter test. Not perfect yet, but it finally feels more like flying and less like troubleshooting.

In my experience FSHud is more the ATC and traffic-management side than the model package itself, so yes, you can pair it with FSLTL models. If you want the easier setup, FSLTL models are fine. If you want deeper airline coverage, I still think AIG is stronger, but FSHud plus FSLTL is absolutely a workable combo.

AIG is still worth it for me if you want broad airline coverage, but I’d avoid the full OCI dump unless you really need every region. I usually keep it focused on the airlines and areas I actually fly, then let FSHud work with that traffic setup, because it stays a lot easier to manage and update later. If disk space is your main concern, trimming the OCI install is the cleaner route than trying to move a giant install after the fact.

I think part of it may just be that some of these smaller business jets can feel heavier than people expect once you start flying them like an actual IFR platform instead of a sporty GA aircraft. For me that usually becomes much more obvious in the descent and in tighter speed and turn management. I notice it even more when I’m flying offline IFR with FSHud, especially if there’s a fair amount of traffic and some sequencing or queuing involved, because then you really feel how quickly the airplane responds, or doesn’t. So I’m not sure I’d call it broken just from that feeling alone. It may be more that the HondaJet doesn’t match the lighter, more agile impression people expect from it.

I think the weak point with these ATC tools is usually not the voice side, it is what happens once the flight stops being straightforward. Descent timing, transition handling, approach sequencing, spacing, traffic flow, that is the part where it either starts to feel believable or it falls apart quite quickly. So I do get the criticism, especially if the approach phase went sideways. At the same time, I also think some of these situations are easy to misread. If it gave you a published transition, that is not really the same thing as vectors, and traffic can feel very different depending on route, region and time of day. For me that is why I would not call it useless, but I also would not call it mature yet. It still feels like one of those tools that can be quite convincing on one flight and then expose its weak spots on the next one.

I play with FSHud ATC

FSHud made some changes, voices are now much better!