11 hours ago, Christopher Low said:

If this requires SimBrief, then sadly I will not be able to use it. That is not the way I operate. However, I wish you the best of luck with the project 👍

Fortunately for me, it's now second nature as it's built into our VA flight booking system (avoided it for years before though). Although would be better all-round if it could accept plans from elsewhere.

That said, whilst this could be interesting, a subscription model would be an absolute hard no from me.

How do you fly an airliner without simbrief though? How else do you plan the route and fuel and ect?

How do you fly an airliner without simbrief though? How else do you plan the route and fuel and ect?

39 minutes ago, simsuper80 said:

How do you fly an airliner without simbrief though? How else do you plan the route and fuel and ect?

Little Navmap is one popular option.

22 hours ago, anilcougar said:

Regarding SimBrief, for the initial airline IFR scope it gives ACE of ATCs a reliable operational source of truth. We are not only trying to generate radio phrases. The system needs to understand the planned route, aircraft, callsign, departure, arrival, and operational context so the ATC side can make consistent decisions around the flight. That said, I completely understand that this makes the first version less attractive for users who prefer to fly without SimBrief. And also please keep in mind that, whenever you start a flight, we are creating a bubble around the user, and calculating all traffic within that bubble. That bubble also moves with the user, so getting that data from SimBrief is super critical.

Sounds awesome!

The required base Simbrief functionality sounds like a no brainer for for ATC calculations this complex!

I'd definitely rather have it feed off Simbrief than having need an additional 2 more programs in the background like AI Flow/Controller and LittleNavMap.

Looking forward to this!

Edited July 5Jul 5 by blueshark747

47 minutes ago, blueshark747 said:

Sounds awesome!

The required base Simbrief functionality sounds like a no brainer for for ATC calculations this complex!

I'd definitely rather have it feed off Simbrief than having need an additional 2 more programs in the background like AI Flow/Controller and LittleNavMap.

Looking forward to this!

Other ATC apps permit both freestanding flightplans OR Simbrief operations...

1 hour ago, simsuper80 said:

How do you fly an airliner without simbrief though? How else do you plan the route and fuel and ect?

I do not need to plan routes or fuel, since I am not trying to recreate real world flights. I enjoy short, low level VFR flights or airport circuits in my PMDG 737 (and even the 777F). I build relatively simple flightplans directly in the FMS, bung in whatever fuel load I like, and take to the skies!

Welcome to the world of flight simulation, where anything is possible 😉

Hi Captains,

I think there is one important point that may be getting lost in the SimBrief discussion.

ACE of ATCs is not being built as a menu-driven or prompt-driven radio addon where the pilot follows a fixed script and the system simply responds with the next expected line.

That is not the target. The target is a serious ATC environment where the radio can be more natural, more contextual, and closer to how real operations feel. That means the system has to understand intent, context, traffic, timing, sequencing, and the operational situation around the user.

And this is exactly why the backend needs a reliable operational source of truth. The more freedom we give on the radio side, the more disciplined the operational side has to be.

If a pilot requests something, reads something back in a shortened way, steps into a busy frequency, asks for a direct, changes level, checks in, or interacts with ATC in a less scripted way, the system cannot rely on guesswork. It needs to know what the flight is, where it is going, what the aircraft is, what route was planned, what the traffic picture looks like, and what decisions are operationally valid.

That is why SimBrief is required for the initial airline IFR scope. Not because ACE of ATCs is trying to force everyone into one brand or one workflow. It is required because the first version is built around structured airline IFR operations, and that kind of ATC logic needs structured operational data.

Flight simulation is a sandbox, and everyone is free to fly however they enjoy flying. But ACE of ATCs is not trying to support every possible sandbox behavior on day one. If someone wants to fly a 737 visually around a local area, build a quick FMS route, put in any fuel load, and operate completely free-form, that is absolutely fine as a simulator experience.

But that is not the initial supported operating envelope of ACE of ATCs. (Maybe we're behaving like Airbus in here :D) We would rather build a narrower operational world properly than claim to support every possible flying style and then reduce the ATC logic to shallow guesswork.

So the SimBrief requirement is not the product being less ambitious. It is part of the discipline that allows the rest of the system to be more ambitious. The initial target is structured airline IFR operations with an ATC system that has enough operational context to make meaningful decisions.

Other flight-plan sources, GA, VFR, helicopters, and more free-form workflows are useful feedback for the future. But the first version needs a solid operational backbone, and that is the reason behind the current requirement.

With love and Blue Skies...

ps: My dev team will probably kill me for announcing this but they have just started the multiplayer version of ACE of ATCs too. Two or more people will be able to share a completely isolated ATC session with their voices audible to all of them (no promising, no timeline or deadline given, it is just an idea right now which we'll see what's gonna happen)

/Anil

54 minutes ago, anilcougar said:

Hi Captains,

I think there is one important point that may be getting lost in the SimBrief discussion.

ACE of ATCs is not being built as a menu-driven or prompt-driven radio addon where the pilot follows a fixed script and the system simply responds with the next expected line.

That is not the target. The target is a serious ATC environment where the radio can be more natural, more contextual, and closer to how real operations feel. That means the system has to understand intent, context, traffic, timing, sequencing, and the operational situation around the user.

And this is exactly why the backend needs a reliable operational source of truth. The more freedom we give on the radio side, the more disciplined the operational side has to be.

If a pilot requests something, reads something back in a shortened way, steps into a busy frequency, asks for a direct, changes level, checks in, or interacts with ATC in a less scripted way, the system cannot rely on guesswork. It needs to know what the flight is, where it is going, what the aircraft is, what route was planned, what the traffic picture looks like, and what decisions are operationally valid.

That is why SimBrief is required for the initial airline IFR scope. Not because ACE of ATCs is trying to force everyone into one brand or one workflow. It is required because the first version is built around structured airline IFR operations, and that kind of ATC logic needs structured operational data.

Flight simulation is a sandbox, and everyone is free to fly however they enjoy flying. But ACE of ATCs is not trying to support every possible sandbox behavior on day one. If someone wants to fly a 737 visually around a local area, build a quick FMS route, put in any fuel load, and operate completely free-form, that is absolutely fine as a simulator experience.

But that is not the initial supported operating envelope of ACE of ATCs. (Maybe we're behaving like Airbus in here :D) We would rather build a narrower operational world properly than claim to support every possible flying style and then reduce the ATC logic to shallow guesswork.

So the SimBrief requirement is not the product being less ambitious. It is part of the discipline that allows the rest of the system to be more ambitious. The initial target is structured airline IFR operations with an ATC system that has enough operational context to make meaningful decisions.

Other flight-plan sources, GA, VFR, helicopters, and more free-form workflows are useful feedback for the future. But the first version needs a solid operational backbone, and that is the reason behind the current requirement.

With love and Blue Skies...

ps: My dev team will probably kill me for announcing this but they have just started the multiplayer version of ACE of ATCs too. Two or more people will be able to share a completely isolated ATC session with their voices audible to all of them (no promising, no timeline or deadline given, it is just an idea right now which we'll see what's gonna happen)

/Anil

You're free to develop on whatever path you choose of course, but I'd question why you think simbrief is a higher 'source of truth'? It's just an automated pln import basically....

I'd agree your system has to understand intent, context, traffic, timing, sequencing, and the operational situation around the user, but simbrief doesn't actually give you any of that over a bare pln file....

2 hours ago, kevinfirth said:

You're free to develop on whatever path you choose of course, but I'd question why you think simbrief is a higher 'source of truth'? It's just an automated pln import basically....

I'd agree your system has to understand intent, context, traffic, timing, sequencing, and the operational situation around the user, but simbrief doesn't actually give you any of that over a bare pln file....

Hi Kevin,

Thanks for your comment, but I honestly think you are reducing SimBrief to the wrong layer here.

I am seriously suggesting that you take a proper look at what SimBrief can actually provide through its API. You do not need a token or authentication for the basic OFP fetch; a username is enough:

https://www.simbrief.com/api/xml.fetcher.php?username={username}

After seeing the amount of operational data available there, please reconsider describing SimBrief as basically a PLN file importer.

For ACE of ATCs, this distinction matters a lot. We are not building a radio chatter box. We are not building a system that imports a route and then plays ATC voice lines on top of it. As I have said many times, ACE of ATCs is trying to create a simulated operational world around the user, where the AI traffic also behaves according to aviation logic and operational rules.

Let me give one simple example.

Imagine a Boeing 747 holding short for departure, while an Airbus A320 is on final, 12 NM from touchdown. At this level, ACE of ATCs is not only asking “who should speak next?” or “which aircraft has a route loaded?”

The system evaluates operational consequences.

Should the 747 keep waiting until the A320 lands?
Is there a safe and efficient departure slot before the arrival?
What is the impact of slowing the A320 slightly?
What is the impact of keeping a heavy aircraft waiting at the holding point?
How does this affect runway flow, spacing, sequencing, and the traffic picture around the airport?

AMAN/DMAN and the Director layer are being built to reason about exactly these kinds of operational tradeoffs. AMAN/DMAN can suggest the most suitable slot, Director makes the final operational decision, and the Manager layer keeps watching the bigger picture for wrong or unsafe decisions.

That is the level we are designing for.

So no, for this first airline IFR scope, a simple PLN file generator is not the right starting point for us. A PLN file may describe where an aircraft is supposed to go. ACE of ATCs needs a proper aviation-based OFP context to understand what the flight is and how it fits into the live operation around it.

We have real-world ATC input, real-world airline pilot input, and we are constantly checking the behavior ACE generates against real operational thinking.

So this is not a toy.
This is not an aviation radio box.
This is not a jukebox.
This is an attempt to build a serious simulated ATC world.
Or at least, that is exactly what we are aiming for.

I remember seeing a quote back at university:

“Aim for the stars; at least you may land on the moon.”

That is what we are doing here.

So to cut the story short: No, we do not need a PLN file generator as the foundation for v1.

We need a proper aviation-based OFP source. That is why SimBrief matters for the initial airline IFR version.

I hope this clears up the SimBrief point.

/Anil

6 hours ago, anilcougar said:

I hope this clears up the SimBrief point.

Not quite. While I happily concede there's a lot of info in there, I'm not seeing a great deal that can't be established from other sources within the sim. So my point I think still stands, in that it is possible to create exactly the knowledge based level of control you say is your objective, (and I agree!), but it doesn't HAVE to come exclusively from simbrief.
You've chosen to go with that to begin with, and that's a perfectly valid choice, no quibbles. Don't overlook other sources of data though that might be slightly harder to access and make use of 🥰

Edited July 6Jul 6 by kevinfirth

On 7/4/2026 at 9:27 PM, anilcougar said:

That said, I completely understand that this makes the first version less attractive for users who prefer to fly without SimBrief. And also please keep in mind that, whenever you start a flight, we are creating a bubble around the user, and calculating all traffic within that bubble. That bubble also moves with the user, so getting that data from SimBrief is super critical.

It is not only that, I use Simbrief for each and every IFR flight, but for me the need to have a valid Simbrief flightplan is one of the biggest drawbacks of BeyondATC and a huge disadvantage over FSHud. It basically makes the use of AI Traffic via Tool impossible when NOT flying an IFR flight with Simbrief FP. Suggestion: if no Simbrief FP is loaded, the tool asks for the departure and arrival airport and the planned departure time and this bubble can be created nevertheless. Or in other words: FSHud manages to create this bubble without Simbrief flightplan as well, so it IS possible.

51 minutes ago, AnkH said:

It is not only that, I use Simbrief for each and every IFR flight, but for me the need to have a valid Simbrief flightplan is one of the biggest drawbacks of BeyondATC and a huge disadvantage over FSHud. It basically makes the use of AI Traffic via Tool impossible when NOT flying an IFR flight with Simbrief FP. Suggestion: if no Simbrief FP is loaded, the tool asks for the departure and arrival airport and the planned departure time and this bubble can be created nevertheless. Or in other words: FSHud manages to create this bubble without Simbrief flightplan as well, so it IS possible.

To be fair, ACE of ATCs is probably intended to do a lot more than FSHud. Whilst I do not know the current capabilities of FS Hud, if it did what Anil is suggesting his product will do, I think we would know about it.

11 hours ago, anilcougar said:

And this is exactly why the backend needs a reliable operational source of truth.

And the default built-in nav data (I.e. navblue/LIDO) and flight planner isn’t a source of truth? Can you give a simple list of what it is missing or incorrect compared to Navigraph?

Edit: I replied before I read your subsequent posts. Why didn’t you just say you needed an OPF rather than the 100 words of fluff :)

Edited July 6Jul 6 by boez

2 hours ago, kevinfirth said:

Not quite. While I happily concede there's a lot of info in there, I'm not seeing a great deal that can't be established from other sources within the sim. So my point I think still stands, in that it is possible to create exactly the knowledge based level of control you say is your objective, (and I agree!), but it doesn't HAVE to come exclusively from simbrief.
You've chosen to go with that to begin with, and that's a perfectly valid choice, no quibbles. Don't overlook other sources of data though that might be slightly harder to access and make use of 🥰

I'm wondering some of the same things. Specifically:

• What are the things that ATC really needs from the OFP, beyond what an IFR flight plan contains in the real world? Does it look at the top-of-climb to get an idea of climb performance? If so, this would seem like a bit of a "hack" though, considering that real-world ATC doesn't have access to the OFP -- they simply know from looking at the aircraft type and from experience what performance to expect.

• Most fundamentally: If the OFP is so crucial, what does ACE of ATCs do for AI aircraft? It presumably needs to make the same operational decisions for AI aircraft as it does for the player aircraft, but there is no Simbrief OFP available for AI aircraft. If it can do without this for AI aircraft, why does it need a Simbrief OFP for the player aircraft?

Not trying to be contrarian here -- I'm just generally curious what the constraints are that require a Simbrief OFP.

Edited July 6Jul 6 by weaklink