Andreas79

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.