Andreas79

I see the predictable comment in the comparison above, and for my kind of flying that is actually one of the stronger points. When I do procedural approaches at smaller European airports with the 737, FSHud keeps the traffic behavior consistent through the whole descent without suddenly doing something unrealistic just to create variety. That matters more at regional fields where you are not getting full radar vectors from ATC. For busier airports the traffic flow is obviously more complex, but even there I have found the predictability helps me plan the approach phase better instead of reacting to random traffic movements around the field.

That chart is a useful comparison. I would not call FSHud rudimentary exactly, but I get the point - it is more limited in scope than something like SIAI or BATC with their full ATC simulation. Where it works for me is the traffic flow around the airport itself. One thing I have not seen mentioned yet is how the turnaround cycle plays out at busier European hubs. When I fly low-cost routes into places like EGKK or EDDM with the 737, I notice that the arriving aircraft actually park, sit for a while, and then depart again later in the day. It is not just instant spawn and go, which makes the ramp feel less artificial during a typical short-haul turn. The subscription question really depends on the flying you do. For my regular 737 routes at major European airports, the difference in how traffic sequences and flows around the airport is noticeable enough to justify it. For GA at smaller fields, I can see why it might not be worth the extra cost.

On the ground traffic side, what I notice most is how FSHud follows the airport configuration. When you set which runways are active, the departures and arrivals adjust their flow accordingly. The whole taxi and ground movement pattern changes too, not just which direction planes take off and land. That makes a big difference when you are doing offline IFR and want the environment to feel consistent. I keep the subscription mostly for that reason. The traffic around the airport just feels more connected to what you have configured, which matters when you fly the same routes regularly.

I'm another subscriber here. The airport operations side is what keeps me renewing. I fly mostly low-cost routes around the UK and Europe, and what I notice first is whether the departures and arrivals actually match real schedules. FSHud Traffic does a pretty good job with that in my experience, especially at the busier airports I tend to use. The airport configuration control is a big part of it too. Being able to set which runways are active and seeing the traffic flow adjust accordingly makes the whole offline IFR session feel more coherent. I've tried running without the subscription and going back to AIG alone, but the overall airport environment just feels less connected. For the kind of flying I do, the combination of FSHud and the traffic add-on works well enough to keep the subscription going.

This is one of those things that has a bigger impact on the whole ATC and traffic experience than most people expect. Clean airport data doesn't just help the taxi phase - it shapes the entire arrival and departure flow. When the runway assignments, taxi routing, and gate positions are right, tools like FSHud and AIG can produce a traffic pattern that actually feels like a working airport rather than a random scatter of aircraft. For the kind of flying I do, mostly short-haul low-cost routes around the UK and Europe, having the right airport setup matters a lot. The turnaround and next departure sequence depends heavily on getting those details right, and default airports often don't cut it. It's good to see someone addressing this directly instead of just treating it as an ATC problem.

Good to see them chipping away at the WASM issues. The panel state crash on load was one of the more frustrating ones for me, especially with saved flights you have been using for a while. Will grab this update today and see how it goes.

That is the practical problem with this more than the visual one, I think. For IFR I don't expect the sim to match every radar return perfectly, but when a large convective area is missing completely, route planning becomes awkward because the cockpit picture, external radar and what other traffic is doing no longer line up. I usually end up cross-checking an external radar or Meteoblue before departure if the weather looks active, then treating the in-sim weather radar with a bit of caution. It is workable, but it is not ideal when you are trying to make a sensible deviation decision in cruise.

If you're checking it in FS2024 now, I'd probably start with the clean stock airport first before adding any scenery on top. With runway/elevation oddities, extra scenery and old cache/content leftovers can make it harder to tell what is actually broken. If the stock version still looks wrong after that, then at least you know you're not chasing a conflict from another package.

For me the commercial side is actually the main value of it. I mostly fly low-cost type routes around the UK and Europe, so what I notice first is whether the airport feels like a real airline operation or just a few random aircraft parked around. With FSHud Traffic the useful part is that you see arrivals and departures as part of the same flow, and sometimes an aircraft that arrived earlier is later part of the departure rhythm again. That makes places like UK and European holiday airports feel much less empty. For turboprops and smaller IFR traffic I understand the point though. If that is the main thing you want, running another traffic source alongside it still makes sense.

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.