Fiorentoni

There's no Spirit in live traffic, not evne for the parked ones. Devs have made sure that all defunct airlines are filtered out from ther parking spots if live traffic is active. Only with scheduled traffic you get Spirit (as it was still alive in 2025)

Yes correct. This is because there's no data from parked aircraft (transponder is off). Only when the aircraft becomes "active" on FR24, BATC can see it.

From what official members have said on the Discord, in MSFS 2024 it's fine with PG off and some are flying with PG off themselves. I can confirm this with KJFK at least, which was unusable on MSFS 2020 with PG off. I've also noticed ini doesn't write "only works with PG on" anymore so into their product descriptions (for 2024 airports at least), so there's also that

Sorry... but what does the Scenery Manager do? It moves my sceneries to a very secret location in the planet Earth...? Am I missing context?

It's simple - those kind of details are actually rather easy to model (you can even use pre-used textures or straightout models) and they look very "good" on product pages, suggesting a very high level of details. And that's what sells for most people these days.

Yes it is clickbait, but you haven't seen the video have you? He analyses the scenery in developer mode and e.g. one of his findings is that KATL has over 100.000 (!) draw calls, while something not exactly lightweight like ini EGKK has 2500. Also many objects seem to have no LOD whatsoever.

No Navigraph needed for BATC. The base sim navdata is working fine and is updated regularly.

Hard pass. They haven't even got a working autopilot 3 1/2 years in. I have it, so I speak from experience.

I suggest you get on Discord and also take a look at our tutorial, a lot of the questions are answered there within. 1) If you reconnect in the air, you do not have to file a new plan, just announce on frequency and it will continue fine 2) You can change the runway and approach. I do both regularly. Needs to be an active runway of course, but at least one that fits your aircraft type will be active at all times. Again, look at the tutorial and wiki for more infos. 3) Yeah the "report when ready" readback is a bit too strict. You need to say "call when ready" at the end. This interaction needs more freedom of phraseology. For anything else please get on Discord, post a log and someone will tell you what's going on. It takes some time to understand BATC's flows and that's why we have an extensive wiki. That said stuck traffic is likely a bug, but even then no one can fix it if you don't file a report.

It's two different products. One does turbulence, one does weather. As for turbulence specifically the difference is that ActiveSky has no terrain turbulence

How are you making sure the app / procedures / result etc. do not break due to the user not doing everything in a specific order (also because SOPs vary a lot), or by aircraft addons not sending (default) simvars etc.? That's what in the end has always broken every addon that tried to go that deep (like SLC). Aircraft addon does not use the seatbelt simvar? Great, user turns seatbelt on but for the app it's still off. So the user has to do it manually in the app and gone is a bit of the immersion and so on.

It means the aircraft code crashed while running. A restart of the flight will fix it.

Anyone checking the FlyTampa YSSY? The last World update (netherlands) wrecked the FlyTampa EHAM and they (FlyTampa) are totally reluctant to provide a fix; I don't want the same to happen to YSSY

BATC does not do anything different with the Concorde (except for taking care of minimum / maximum speed type limits like with any other aircraft), which is because: 1) While you can use BATC with historical airplanes just fine, the ATC design is present-times (which is why there's e.g. not yet any Oceanic Procedures because they are changing right now, so it's a moving target), and at present there are no (practical) procedures for supersonic passenger flights that I'm aware of. 2) There's no decent Concorde for MSFS, which is why no one ever asked about it or complained about it on BATC 🙂 Actually I haven't even thought about it until you mentioned it now.

So from what I gather it's more about getting the flexibility and context that real life has, like saying "runway not in sight, can we get an instrument approach?" which BATC can't handle yet for example. That's however also the most difficult part in creating an ATC tool. Sure, you can throw away the scripting and just hook it up onto an AI which will then react dynamically to anything you say at any time and also forget who you are, where you are and what was said before... there are other tools that tried that approach and the result is not convincing. So that dynamicality (is that a word) and flexibility is something that needs to added via classical coding, but that takes a lot of time and effort and is probably something I'd expect only after the core features are complete (they are nearly now with VFR out for experimental) and working flawlessly (there's still a lot of work to do on vectoring and speed management and AI traffic in general). I know we flight simmers always want to have everything right now, myself included, but let's not forget that there has never in 30+ years been any ATC tool that did what the current ATC tools are doing or trying to do (core ATC + traffic injection being controlled by core ATC + AI voice generation etc.). So we don't really have a baseline to measure those tools by. Yes, those old ATC tools like P2ATC had much better vectoring already, but they were also being developed for 10 years and they have no AI traffic or modern voices. Considering what BeyondATC has on its plate and is offering for a mere 30 dollars I think they've come a long way in just 2 years. Hell, it took PMDG almost 2 years to do their mediocre UFT...