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.