Having had experience with Radar Contact v4 for many years that started when I was invited to join the testing team back in 2004 I’d like to add my views.

I should also add I don’t have MSFS or BATC so can be considered an outsider with no axe to grind. I’m just looking at the situation dispassionately but with knowledge of how a successful IFR ATC program works.

I would expect the program to take me from Clearance and pushback through taxiing to the runway, giving clearance to line up and then approval to takeoff.

That would be followed by being handed over to various controllers and instructed to climb to my planned cruise level.

At a point near the calculated ToD I would then expect instructions to descend in line with any STAR altitude restrictions. Finally, a 30° intercept heading should be given followed by a clearance to land.

I wouldn’t expect the program to handle approaches into tricky airports surrounded by high terrain such as Innsbruck - LOWI. That is extremely difficult. But just like RC4 the user should have a way of telling the program the landing airport is in that category.

But it should work at airports with no terrain issues. Only when that has been successfully tested should it be released to the paying public. We had a beta team of 6-8 people who tested RC4 at a variety of airports and only when we were satisfied it was as good as it could be would John Decker release it for sale.

I’ve never bought any software described as early release. It seems to be the modern alternative to having a beta testing team. Whether that’s better or not is best left to the customer.

4 hours ago, Dialex said:

That’s exactly where we are going in circles, and I’m sorry to say this again, but it’s still in early access.

 

You can't hide behind the "early access" shield forever.   It's been two years and I'd argue that IFR vectoring is no better than when it was released on Day 1.   I have a feeling that "early access" will still be thrown out there as an excuse two years from now.    So again, maybe just hold off on adding all those other features and just get the main aspect of this product fixed.   Once that's fixed, go ahead and add a million shiny new features to it.   But until then.... 

As an aside - Just wondering what the reaction would have been if Microsoft decided to release "MSFS 2024 (Early Access)".   Then, when everyone complained about it's horrible initial state, they would simply just throw out the "but it's still in early access" language. 

12 hours ago, CFIJose said:

It doesn't matter if you're a pro controller, a seasoned CFI, or a casual user, anyone that uses this ATC add-on the right way will come to the same conclusion. It ain't ready yet.

As a former pro controller and instructor, a long time IRL private pilot and with a 40+ year background in flight simulation (first simulator was Bruce Artwick’s “Flight Simulator circa 1980 and just about every simulators since) and after using many ATC simulator programs (as an ATC Instructor) and ATC add ons for flight simulation, I have a qualified point of view that makes me feel comfortable making this one minor correction to your statement above, change “It ain’t ready yet” to “In my personal opinion it ain’t ready yet”.  Blue skies,

-B

1 hour ago, 11bee said:

You can't hide behind the "early access" shield forever. 

My issue with this is that we haven’t tried to hide anything, this has always been public information. From the beginning, we’ve been clear that this would take years to fully develop. That’s not an excuse, it’s simply the reality of the complexity involved.

At the same time, it feels unfair to criticize the pace of progress while still choosing to purchase the product knowing it was early access and that it would take this much time to develop. The issue seems less about transparency and more about expectations around how quickly things should improve.

Our devs haven’t abandoned the project or left it sitting idle. Progress has been made, including improvements to vectoring. Are we where we ultimately want to be? No, but saying nothing has improved overlooks the work that’s already been done, it’s documented and our fixes are linked to bug reports that are sent to our attention. You may not see the improvements in your case, but I don’t think it’s fair either to conclude we haven’t done anything at all.

At this point, the conversation doesn’t feel productive anymore. It seems the frustration comes from the speed of development rather than the direction. And while that frustration is understandable, this isn’t a simple problem to solve. If it were, a much larger and more established team as the Asobo one would have already done it, and yet during all these years nothing convincing has been implemented. Expecting a small team to solve it in a matter of months or even just one year just isn’t realistic.

We were also upfront about this being an early access release. In fact, the decision to release it early came from the community. Otherwise, we would have waited. Given that, it’s difficult to place the blame on us when the expectations were clearly communicated beforehand.

Everyone is entitled to their opinion, of course. But I don’t think it’s fair to disregard the transparency we’ve maintained throughout the process or the information that was available before purchase. It does feel that no answer is going to satisfy, even though we made our best to present it correctly to place expectations in the right place.

40 minutes ago, Dialex said:

At this point, the conversation doesn’t feel productive anymore.

Indeed ...

so, now we wait 4 weeks until the next BATC bashing thread starts, as usual

We're not bashing a product.  It is early access, which means feedback is important to that process.  

I'll be the first to admit to getting frustrated and venting.  I get very limited time to fly lately, so it is frustrating when a flight goes off the rails.  I try to be constructive with my feedback most of the time.  (sorry too but this is Avsim, if you take away the griping, it would get really quiet around here).  😀

The other frustration is, when it does work, it is a great product!  If it simply didn't work, I'd uninstall and move on.  

The devs have been open about how they are continuing to work on existing features.  Great!  I just want to make sure that continues.  

I'm trying to provide specific cases where the program struggles.  For example - GA IFR into medium sized airports without a STAR (or one that can be used).  

4 hours ago, btacon said:

one minor correction to your statement above, change “It ain’t ready yet” to “In my personal opinion it ain’t ready yet”.  Blue skies,

-B

IMHO. Thank you for your contribution to this thread.

I to am having the problems listed here with BATC since I fly mostly regional airports with Flightfx Citation. I have never used FSHUD. Would that be a better choice for me ? Thanks

25 minutes ago, bmarcoux2 said:

I to am having the problems listed here with BATC since I fly mostly regional airports with Flightfx Citation. I have never used FSHUD. Would that be a better choice for me ? Thanks

Before I moved to the other competitor I found FShud to be a really solid performer.  A bit on rails, but I didn't have half the issues that I had with BATC.  

On 4/10/2026 at 10:34 PM, BWBriscoe said:

 20 miles past the TOD before it acknowledged and issued me descent clearance (I had to use speedbrakes all the way down).
 

I experience this on most flights. It's got boring.

I think the 'early access' excuse would be acceptable if I hadn't paid for it...which I have. How long does 'early access' give them before we start thinking it should be fixed by now.

There are a lot of MS products in 'early access' or beta but they don't charge.

If I'm paying, then I expect a decent product as promised.

Except that when you purchased it, it was advertised as early access. They were very clear about that.

 

As for it being a decent product, I certainly have no complaints as to where it's at. Sure it's not perfect, but very few things regarding this hobby really is.

So I made around 9 flights with BATC. Over all I like the experience. First of all I love variety of voices that feature different accents depending on geographic area you are flying. I like hir chatter. Once I asked to expedite take off due landing traffic which was nice touch. I like very intuitive interface and map that helps you navigate airport without losing at taxi diagram.

Most of the flight that I generated with simbrief didn't require vectoring, so the flow pretty good from departure to STAR follow by approach. In those segments where vectoring was involved it was not prefect but also not terribly bad.

I want to point that in my time IRL dealing with ATC I had an experience with absolutely awesome ATC work as well as very poor. I remember  S turning in IMC around localizer kept sidetracking and forgetting  about me causing each vector  to overshoot localizer without clearing me for approach .  Once I was vectored so high and was literally to dive in IMC to intercept GS. I even been told on few ocasions to stay outside someone airspace and call back in 30 minutes without inquiring how much fuels and should I had on board. LOL Also all midair accident Ive seen over the years were with ATC controllers on duty including mid air with several IFR flights. The truth is light GA never get as good treatment as airlines. Basically what I'm trying to say that ATC is not always perfect IRL.

IRL we are taught to aviate, navigate, and communicate. In my opinion whether you vectored by virtual ATC or real ATC it is in pilot responsibly and authority to ensure safety of flight. I was never afraid to say to ATC "unable" IRL. So I'm using the same philosophy with BATC. When BATC gives me bad vector I can see how I can fix it to better serve safety of my virtual flight. After all BATC doesn't complain when I deviate it doesn't prompt me to write down telephone number and call supervisor LOL So it works for me. I'm actually  quite fond of  BATC because it makes my flight experience reacher. 

So the bottom line my BATC expectations in par of what I got. I didn't expect to be absolutely perfect. Remember real ATC is never perfect either. My students always terrified when ATC asks them to "fly direct to the numbers", "give best forward speed", or "make and short approach" or "make modified approach"  LOL I always tell them when they solo always say "unable " of they are not comfortable to do what ATC asks them LOL

I flew another flight this evening.  A short IFR GA hop (used the PC24).  About 110nm including my expected IAP.  Routing was KCWA (towered airport) WISOM KSUE (untowered airport).  The weather was LIFR (Low IFR) so probably near minimums at KSUE.  Overall this is probably the best short IFR flight I've seen BATC handle.  Let me bold that for you:  This is probably the best short IFR flight I've seen BATC handle

People are grilling me because they claim I'm picky and am expecting extreme realism...  I've never said that and in addition to some of the negative parts I've also shared the positive parts in previous avsim posts.  But THIS TIME I will explain what happened in the sim, and what would happen in real life. 

Departure:  there's some odd quirks like multiple vectors on departure then eventually sending me to the first filed waypoint (or my only filed waypoint - WISOM).  I'm guessing BATC doesn't know about the airspace and just tries to simulate a few departure vectors - that's all fine with me.   IRL a sleepy contract tower such as CWA would probably clear me on course to WISOM (IRL the Center controls the releases at this tower and they'd approve a release direct WISOM, the tower would issue that to the pilot).  At any rate, the taxi and takeoff and departure just went fine, good enough for flightsimland.  

Enroute:  after passing WISOM (and I'm now talking to Center), they issue me a slight left turn (I think it was a 080 or something), and the reason is something like "vectors for Door Co Cherryland."  OK fine for flightsimland.  Kinda odd irl though.  What happens IRL is that Green Bay approach will work this flight, they will ask me "N1718A advise Door Co Weather, advise approach request."  They also would issue NOTAMS.  After looking at the real world weather I'm thinking BATC will set me up for RNAV 20.  There must be a weird navdata bug or something cause BATC keeps calling themselves "Green Bay Austin Straubel approach."  This is super minor and totally fine for flightsimland.  IRL it's just "Green Bay Approach."  Also BATC did not leave me high on this flight (It's Wisconsin, there's not much terrain hehe)... but it did a good job descending me in a reasonable timeframe.

Approach:  So eventually approach stops keeping secrets and tells me to expect the RNAV 20 into KSUE.  Perfect.  What comes next surprises me though.  They eventually give me an approach clearance via vectors to final approach course.  That's not what happens irl at sleepy uncontrolled airports - ESPECIALLY for an RNAV approach.  Literally they will send you to the nearest IAF, and as long as the angle from your current track to the next track on the IAP is 90 degrees or less, they will clear you from that IAF.   See green arrows in my pics for typical IAF's that pilots would be issued.   They turned me late and I went through final (again not a big deal -and yes it does sometimes happen irl) - I'm impressed BATC has gotten this far because usually I'm either cruising the waves of Green Bay at like 500 ft agl or stuck on that 080 heading and ATC forgot about me.

Landing:  I admit I was having a decent flight and am bummed out about this last part.  BATC thinks Door Co is a towered airport and it's simply NOT.  So it has me contact "Minneapolis tower" on 124.4 (the frequency I was originally on when I left CWA - which is correct for the Center over there by the way!)  They "clear" me to land on runway 20, I taxi off they send me to parking.  Is this BATC's solution to avoid the IFR cancellation part?  I'm not sure but it was totally annoying and totally fake. 

What happens irl?  Green Bay Approach says something to the tune of "N1718A report IFR cancellation this frequency, or with Minneapolis Flight Data (insert phone number), change to advisory frequency approved." 

And the pilot could 1) cancel right there and then (maybe the ASOS was outdated and its now VFR, 2) cancel on that frequency which may or may not work on the ground, 3) cancel via calling that flight data phone number once on the ground via mobile/fbo landline. Sometimes airports have an additional frequency that's connected to a phone number at the facility as well.  Additionally, if there was multiple aircraft inbound to SUE, ATC would tell them to cancel "through" the other aircraft once they land.  One more IFR cancellation option that's less frequently used but does work, is to have another aircraft on frequency, monitor/listen up for that aircraft's IFR cancellation (for instance another aircraft passing by in radio range since its line of sight they'll be able to hear someone low to the ground while ATC may not)... they'll relay it to ATC, and ATC will relay back "N12345 please advise N1718A their IFR cancellation is received."

So if BATC could just use the nearest IAF for an RNAV approach clearance that would be more realistic for smaller airports.  At larger airports you'll probably still get an ILS first, and then perhaps and RNAV approach - and you might get vectors to final (even with the RNAV like it did to me here) because ATC will have multiple aircraft inbound, and they'll need to sequence you.  With VTF, everyone is doing the same thing and it's much easier for ATC to judge spacing.

Oh one picky comment here, when giving a vector to final, it's more typical to state the distance from the Final Approach Fix (or even the airport itself), and not another IF or IAF.  It states "VOBUY" when it should reference LOSSI or even the SUE airport.  For flightsimland it's not a big deal at all. 

The outrage hehe...  this one just kinda slayed me...  annoying way to end a pretty decent flight imo.  They need a better resolution when landing at uncontrolled/non-towered airports

 

14 hours ago, bmarcoux2 said:

I to am having the problems listed here with BATC since I fly mostly regional airports with Flightfx Citation. I have never used FSHUD. Would that be a better choice for me ? Thanks

The only issue I have with FSHud, is that it strictly holds you to SID Star restrictions.

So, for instance, if you depart EGBB RW15 on the CPT2Y SID, there is a 6000 ft restriction at Compton, which means you are held at 6000 ft for the inital 60 nm of the route, no way to request further climb.

I'm sure there are many other SID's like this, where there is an altitude restriction way out from the field.

BATC respects the SID and STARs but is more pragmatic with its ATC clearances.