2 hours ago, Christopher Low said:

There are some very strange responses from people around here at times.

Yes, I'm surprised that any developer even bothers to open up at all on this forum.

2 hours ago, cowpatz said:

Yes, I'm surprised that any developer even bothers to open up at all on this forum.

In this world full of vibe-coded promises and shallow substance, a healthy dose of skepticism is a good thing to have.

14 hours ago, 787flyer said:

Anil,

Any thoughts/comments on the PC hardware needed by sim users to run the app(s)? I imagine you have some idea of compute power but I imagine you will exploring this in more detail as development and testing proceeds? Can you share anything on this point?

Also, I like your description of the complete ATC workflow, but am wondering about a few specific things when AI traffic control typically goes AWOL.

Will ACE be able to sequence AI traffic via holds and go-arounds?

Will ACE be able to instruct AI traffic on crossing taxiways that intersect runways?

Will ACE be able to determine priority/preference for specific runways where aircraft and runway limitations apply?

What controls are in place for users to apply certain runway configurations of their choosing?

As you move forward, if its possible to create a catalog of FAQs that we can refer to, that could be most helpful to us.

Wishing you all the best on this new journey!

Regards
Mark

Mark,

Thank you. This is actually a very good post.

And I mean that quite seriously, because after reading some of the other comments in this thread, the bar for having an actual technical discussion seems to have dropped through the floor (:

You are asking what ACE does, how we are approaching specific operational problems, where the limits are, and what we are testing.

That is completely different from inventing a version of ACE in your own head, deciding how we must have built it, and then spending three paragraphs explaining why your imaginary version cannot work.

I have very little interest in that kind of discussion.

If somebody wants to challenge an architectural decision, operational logic, a test result, or something we actually built, fantastic. Bring it on.

But if the entire argument starts with assumptions about an architecture you have never seen, then congratulations, you are not debating us. You are debating yourself.

Anyway, your questions are real ones, so let me answer them.

On hardware, I don't want to publish minimum or recommended specifications yet.

Could I put some numbers here today? Sure.

Would they mean anything? Not really.

We have a good understanding of the compute footprint already, but beta testing across different machines is what will give us numbers I am actually comfortable publishing. CPUs, GPUs, different simulator settings, traffic levels, all of that matters.

I'd rather tell you "we don't have the final answer yet" than make up a neat little hardware table for marketing purposes.

The goal is absolutely not to require some ridiculous monster PC just to run ATC in the background.

Once we have enough beta telemetry, I will publish proper minimum and recommended specs.

On sequencing, yes.

Holds, go-arounds, missed approaches and re-sequencing are not optional extras for us. They are part of traffic management.

ACE cannot simply play the correct phrase when a condition is triggered.

It has to understand why the sequence is no longer viable, what changed in the traffic picture, which aircraft now has priority, which aircraft needs delaying, and how to rebuild the plan.

Otherwise, let's call it what it is.

It isn't ATC intelligence.

It is a phrase generator wearing an ATC costume.

The runway/taxiway crossing question is something I am testing quite heavily at the moment.

Chicago Midway is actually one of the airports I use for it, because MDW is absolutely brutal in a good way for testing ground logic (:

Intersecting runways, lots of runway crossings, tightly coupled movements. It exposes stupid logic very, very quickly.

Generating a taxi route is easy.

The hard part is understanding whether an aircraft is allowed to cross a runway at that moment, what is on the runway, what is approaching it, what has already been cleared, whether another clearance creates a conflict, and which controller owns that movement.

If your "ground controller" can draw a line from the gate to the runway but cannot reason about those things, you don't have ground control.

You have Google Maps with a radio voice.

Runway selection is the same story.

ACE is not being designed around "RWY 27 active, send everybody there."

Aircraft limitations matter.
Runway length matters.
Approach availability matters.
Traffic flow matters.
Weather matters.
The current configuration matters.

And exceptions matter.

An aircraft may not be able to use the preferred runway. A runway configuration that worked ten minutes ago may stop making sense. Traffic can force a change.

That is exactly the kind of problem the system is supposed to solve.

The happy path is not particularly interesting.

Pretty much anybody can make a demo work when every aircraft behaves perfectly, every runway remains available and nobody does anything unexpected.

The interesting part begins when reality ruins your beautiful plan.

On user runway configuration, yes, users will have control.

I don't want ACE to be one of those magical AI boxes where the answer to every question is basically "trust the model."

No.

There need to be constraints, operational context, visible state and user control.

We are still deciding exactly how much of that should be exposed in the first release because there is another problem on the opposite side: give people every internal switch we have and suddenly the ATC interface looks like a nuclear submarine.

So there is a balance there.

And yes, I completely agree on the FAQ.

Actually, at this point I think it is necessary.

Not just because the thread is becoming long, but because useful technical questions are now getting mixed together with speculation, assumptions, and some frankly bizarre conclusions about a system the people making those conclusions have never used and whose architecture they have never seen.

That makes it unnecessarily difficult for somebody genuinely interested in ACE to work out what is fact and what somebody simply made up five posts earlier.

So yes, I will put one together.

And Mark, genuinely, thank you for the questions.

I have absolutely no problem with skepticism.

I have no problem with difficult questions either.

If somebody thinks something we built is wrong, show me where it is wrong and we'll talk about it all day.

But inventing our implementation for us and then proudly discovering problems in the thing you invented is not criticism.

It is fan fiction (:

Regards,

/Anil

8 hours ago, Flic1 said:

I'll continue to be the local skeptic here. There have been several of these LLM-marketing style posts about this product. Many claims are being made but not one single proof-of-concept video outside of a couple shots of AI aircraft taxiing around with no audio. Also, they have released another product that has many bugs and customers are not getting much support according to other posts I have seen. This is now in Beta and there is not a single video to be shown displaying actual ATC audio, etc? That might go a little further than these long-winded AI marketing posts every few weeks....IMHO...

Eric,

We have had this dance before, haven't we? (:

Let's start with the "LLM marketing" comment.

I literally said yesterday that I sometimes use AI to clean up and beautify my English before posting here. English is not my native language, and when I write something detailed on AVSIM I prefer the grammar and wording to be clean.

I do that because I respect this community.

So congratulations, I guess. You have discovered something I publicly disclosed myself less than 24 hours ago (:

Now let's separate writing style from engineering.

If you believe a technical claim I have made is wrong, quote it and challenge it. For example do you know what AMAN/DMAN is? or Director level? Seriously I'm asking this.

If you think our sequencing logic is wrong, challenge it.

If you think the runway logic is wrong, challenge it.

If you think the architecture is wrong, challenge it.

I will happily have that discussion all day.

But repeatedly calling detailed technical posts "LLM marketing" is not a technical argument.

And since you seem very convinced that this is mostly AI-generated marketing noise, let me ask you a very simple question.

Why do you think Kennedy Steve is involved in this project?

A retired JFK ground controller, known by probably half this forum, has put his name, voice and persona behind ACE.

Now, to be very clear before somebody deliberately misunderstands that sentence, Kennedy Steve being involved is not proof that every line of code works perfectly.

Of course it isn't.

But it does make the "this is basically AI marketing" narrative look a little silly, doesn't it?

Do you really think we generated some nice forum posts, attached an AI label to them, and somehow Kennedy Steve just wandered into the project by accident? (:

On the demonstration video, you do have a fair point.

We have not published a full end-to-end ACE demonstration yet.

I have never claimed otherwise.

That video will come.

What I will not do is rush out a carefully staged 90 second "proof" video just because somebody demands one in a forum thread.

When we demonstrate ACE properly, I want to show the actual system managing traffic, including the ugly situations where the original plan breaks and the system has to deal with it.

Until then, saying "I haven't seen the full demo yet" is completely reasonable skepticism.

Saying "I haven't seen the full demo yet, therefore these technical posts are AI marketing" is a conclusion you invented yourself.

Those are not the same thing.

Also, ACE is not in public beta.

We announced beta recruitment and we are onboarding testers.

Again, not the same thing.

You are asking us for evidence, which is perfectly fair.

But then apply the same standard to yourself. Wanna join our beta team? Tell us about your aviation expertise and send us an email at [email protected]. If your aviation background is strong enough, we’ll be happy to put ACE in front of you and let you test it yourself (:Don't ask me for proof while filling the gaps in your own knowledge with assumptions and presenting those assumptions as conclusions.

You don't get to demand a higher standard of evidence from us than you apply to your own claims (:

So please, remain skeptical.

I genuinely mean that.

But be skeptical about ACE.

About the architecture.
About the traffic logic.
About the operational decisions.
About the actual demonstrations when we publish them.

That is useful criticism.

Complaining that I sometimes use AI to improve my English, after I openly told everyone that I do, is not.

And calling the entire project "LLM marketing" while Kennedy Steve is literally standing beside us is certainly an interesting hill to choose (:

Regards,
/Anil

Haven't we had enough of subscription-based apps already? BATC found a way to offer their app without a subscription, so unless you have a human directing simulated aircraft, find a solution that doesn't require a subscription. My two cents.

2 hours ago, anilcougar said:

It has to understand why the sequence is no longer viable, what changed in the traffic picture, which aircraft now has priority, which aircraft needs delaying, and how to rebuild the plan.

Otherwise, let's call it what it is.

It isn't ATC intelligence.

It is a phrase generator wearing an ATC costume.

The runway/taxiway crossing question is something I am testing quite heavily at the moment.

Chicago Midway is actually one of the airports I use for it, because MDW is absolutely brutal in a good way for testing ground logic (:

Intersecting runways, lots of runway crossings, tightly coupled movements. It exposes stupid logic very, very quickly.

Generating a taxi route is easy.

The hard part is understanding whether an aircraft is allowed to cross a runway at that moment, what is on the runway, what is approaching it, what has already been cleared, whether another clearance creates a conflict, and which controller owns that movement.

If your "ground controller" can draw a line from the gate to the runway but cannot reason about those things, you don't have ground control.

Anil, thanks for responding to my questions and I think you hit the nail on the head with the comments above.

Glad you are testing the ground logic at specific, demanding airports. I would suggest looking at some others that you may have on your list e.g EHAM, KATL, EDDF etc.where multiple runway operations are dictated by weather, peak arrival/departure waves and so on..

I am truly curious about how the app can honor the different ground rules in terms of permitted taxi flows around the airport . It's more complex than what I thought.

Why do I so that? Well at the weekend I was using Google Gemini and I asked it to give me a route at EHAM from Gate D43 (which has explicit pushback instructions for specific gates) to runway 36L. To cut a long story short, Gemini actually gave up after 8 attempts to give me taxi instructions step-by-step. Each time it provided an answer, it busted one of the operational rules or gave me nonsensical taxi routings. While it was supposedly referring to the aerodrome charts (it claimed) it appeared to me it could not ingest or interpret the real operational rules, limitations and restrictions for that airport.

Anyway, I am genuinely interested to hear how ACE can manage these ATC taxi operations, Would love to see a future blog (just a suggestion) for a specifc airport and how ACE deals with these complexities, which in my view it needs to do to make it the best, most realistic ATC app. This is why the intelligence is important not just the LLM.

Look forward to hearing more on what you are developing.

Regards

Mark

1 hour ago, 787flyer said:

Anil, thanks for responding to my questions and I think you hit the nail on the head with the comments above.

Glad you are testing the ground logic at specific, demanding airports. I would suggest looking at some others that you may have on your list e.g EHAM, KATL, EDDF etc.where multiple runway operations are dictated by weather, peak arrival/departure waves and so on..

I am truly curious about how the app can honor the different ground rules in terms of permitted taxi flows around the airport . It's more complex than what I thought.

Why do I so that? Well at the weekend I was using Google Gemini and I asked it to give me a route at EHAM from Gate D43 (which has explicit pushback instructions for specific gates) to runway 36L. To cut a long story short, Gemini actually gave up after 8 attempts to give me taxi instructions step-by-step. Each time it provided an answer, it busted one of the operational rules or gave me nonsensical taxi routings. While it was supposedly referring to the aerodrome charts (it claimed) it appeared to me it could not ingest or interpret the real operational rules, limitations and restrictions for that airport.

Anyway, I am genuinely interested to hear how ACE can manage these ATC taxi operations, Would love to see a future blog (just a suggestion) for a specifc airport and how ACE deals with these complexities, which in my view it needs to do to make it the best, most realistic ATC app. This is why the intelligence is important not just the LLM.

Look forward to hearing more on what you are developing.

Regards

Mark

Hey Mark,

I totally get your point, and this is actually one of the most important distinctions with ACE.

We are not using Gemini, OpenAI, Claude, or another third-party LLM as the intelligence behind ACE. We are using our own LLM engine and reasoning stack, which I have been developing for nearly four years and which is already being used in real-world aviation-related work within our company.

I would love, love, love to share more about that side of it, but unfortunately we are bound by a number of NDAs with aviation companies we already work with.

For now, all I can tell you is that her name is Jenny. :)

But you gave me a very good idea.

The ACE of ATCs website is coming online toward the end of this month, and I am going to start a development blog there. I want to show exactly how we deal with problems like the one you described at EHAM: airport-specific rules, pushback restrictions, permitted taxi flows, runway configurations, and the operational logic behind the route that ACE chooses.

Because you are absolutely right: this cannot simply be an LLM guessing a taxi route.

There is another interesting problem here too. AI cannot invent documentation that does not exist. The MSFS SDK documentation has significant gaps, and when simulator behavior or an interface is undocumented, an AI model has no magical way of knowing the correct implementation either. That part still requires engineering, testing, reverse engineering where appropriate, and a lot of validation.

So ACE is not a "prompt an LLM and hope for the best" project. Its systems are purpose-built around aviation logic and simulator behavior.

I happen to be both a licensed pilot and a software engineer, and I have been in love with the simulation world for years. ACE really came from wanting to put those three worlds together.

We have the processing power in 2026 to do things that would have been extremely difficult in a consumer simulator only a few years ago. My goal is simply to use that capability to build the ATC system I always wanted to have in the simulator.

That is also why I asked Kennedy Steve to become part of the project. I explained what we were building and where we wanted to take it, and he said yes.

And yes, I really like your EHAM suggestion. That may very well become one of the first development blog posts.

Best,

/Anil

The PAYG method BATC uses with their Premium voices is perfect for me. I use the sim far less during summer and it chafes paying for a subscription I'm not using.

10 hours ago, Georgleboui said:

In this world full of vibe-coded promises and shallow substance, a healthy dose of skepticism is a good thing to have.

........but not when it borders on insulting behaviour.

Edited 14 hours ago14 hr by Christopher Low

1 hour ago, flyingscampi said:

The PAYG method BATC uses with their Premium voices is perfect for me. I use the sim far less during summer and it chafes paying for a subscription I'm not using.

Not to mention that the Local Voices are now a very viable alternative. Since they improved so much I stopped using Premium alltogether.

8 hours ago, anilcougar said:

For now, all I can tell you is that her name is Jenny. :)

I would very much like to meet Jenny at some stage, perhaps when she is not so busy! 😜All in good time.

Thanks for the additional response and sharing those insights Anil.

A follow-on inquiry despite a couple users feeling like we aren't supposed to ask the developer questions. I'm glad that the dev has been forthcoming with responses.

My understanding, admittedly a weak one, is that there are severe limitations in how AI aircraft are/can be controlled by external interfaces in MSFS. I recall other products that can sequence the user through/around traffic, but past efforts at sequencing AI traffic models have been clumsy, in that they have to basically slew AI aircraft around to separate them, slew them around holds, etc, rather than rely on their own coded flight models.

For this software's solution could it / will it direct AI traffic into holds, or enforce speed restrictions, or give any sort of other direction and the AI traffic will follow that? You previously said that AI will be managed, but from a technical perspective, HOW will they be managed? Again, I thought there were interface limitations between built-in traffic handling code within MSFS, and those of external interfaces. (AIG at least used to have some issues with the fluidity of aircraft in flight, for example). Asking simply because I don't know how that works, not to challenge statements. Is it slewing them or relying on their own flight dynamics?

A few examples:

1. Runway incursions - if ATC tells an AI aircraft to abort take-off, will it?

2. Ground taxi routes - As your real-world ATC advisor can likely attest, at busy complex airports, sometimes traffic is cleared at the last second to a different routing as they are taxiing to the runway (Delta 123 continue straight rather than right on alpha, then follow company - for example). Can that happen here to the user AND to AI?

3. Holds - let's say it's rush hour with poor weather on top of that. Will I be in a stacked hold with AI traffic above and below me (thinking the Heathrow stacks here) prior to being cleared for approach? Will I see AI aircraft models in holding patterns?

4. Re-routings - AI aircraft is scheduled to fly from airport A to B via fixes 1, 2, and 3. Would the ATC amend their routing to fixes 4, 7, and 9, and the AI traffic model follow that new routing?

Any technical detail you can share about how your model interacts with how MSFS handles AI traffic would be great to hear! Thank you!

Edited 9 hours ago9 hr by STK

I'm not saying that this is going to fail, but I will say that i highly skeptical.

BATC, SIAI, FSHUD have been at this for years, all with various uses of AI (especially SIAI) and all of them are struggling with traffic handling. its enormously complex even with the rapid progression of AI.

Also, to have [BETA] in the title, while not having a single screenshot or video? Give me a break. This is pre-alpha.

Best of luck to you sir, I wish you success. But let's not be snake-oil salesmen here.

I've stayed out of this mostly because personally the marketing and writing style of this screams AI slop. And I hope its not, I really do, but there are lots of red flags (as someone who uses Claude all the time for their own work).

- Word choice is very suspect and screams AI, and not just hey rewrite this, but like asking AI to create the whole framing... things like "It is the baseline" "That distinction matters" I see these phrases all the time when AI is trying to make an argument or support a point vs something that's just checking proper English usage.

-A whole separate program SimPassengers was released only 3 months ago by the same developer... Even the best devs in any tech space are not already on an actual BETA of a brand new complex program within 3 months of release of their last (and very first as a company) brand new program. These are the timelines that line up much more with lower quality heavy AI assisted programing.

- Why would you as a developer want only 10 Beta testers? That seems like a crazy low number and means your software won't be properly tested in all the conditions, flight environments or computer software/hardware set ups. Even something like 30-40 testers would give you 3 or 4x more data and feedback. To me it screams marketing, not sound development.

-We have multiple projects who have been at this point released and working in continual development for years on ATC that seem to still have not implemented some of the things that are marketed here.

I hope I'm wrong on all this, I would love to have the best ATC with the best AI handling possible. But calling out forum posters who plainly feel uneasy about the above as "insulting behavior" is a little much. Where did all the distain for PMDG's word salad, marketing only posts go? At least they have a track record of quality releases going back years. This feels much more heavy on the word salad and marketing and less heavy on any sort of proof or substance than anything PMDG has done.

ok gents! Let's keep it civil here. Enough snarky comments. There is some good discussion going on and it does not ned to be punctuated with snide comments.

Personally I would want to supoort a developer who is trying to improve our sim rather than say it's impossible because no one else has done it before.