anilcougar

Supertonic is needed for the high quality PA and multiple languages support. Soon we'll be removing the standard quality version. So to be honest it's not messy, it's super tidy

1.1.9 is mostly a data release. It started with a simple report from a pilot flying Aeroitalia: there was no Italian announcement. That turned into a much bigger cleanup than we expected. We went through roughly 250 airline records and found quite a few cases where the airline name, country or ICAO code was either outdated or simply wrong. A few examples: Korean Air, Asiana, Jeju Air and Air Busan had never announced in Korean. Their country was stored as "Republic of Korea", while the language table expected "South Korea", so the match never happened. The same issue affected Syrian, Dutch and Russian carriers. 21 airlines in total were missing their expected language because of this. Aeroitalia was being identified as "Aerial Transit Company", an old US company that no longer exists. That meant Aeroitalia flights were running announcements in English instead of Italian. Sky Alps was still tied to an old Swiss European Air Lines entry, so an Italian regional airline was announcing in German. ITA Airways, AJet, Akasa Air, Riyadh Air, Air Peace, easyJet Europe and quite a few others are now recognised properly for the first time. Mozambique's flag carrier will no longer introduce itself as "Linhas A". We found 12 ICAO codes that pointed to two airlines at once. One of the better examples was MAI, which could resolve to a defunct Kyrgyz airline and make a Mauritania Airlines flight announce in Russian. Belgium now uses French for its local-language announcements, and Brussels Airlines is properly recognised by name. We also changed how SimPassengers reads the flight logs you send us. The next report should give us considerably more useful information than the previous format did. And genuinely, keep sending those logs when something sounds wrong. This entire release exists because one pilot flew an Italian airline, noticed there was no Italian in the cabin, and took the time to report it. That one report uncovered all of this. A special thanks to Emiliano Gnudi, whose report about missing Italian announcements on an Aeroitalia flight started this whole investigation. One good bug report ended up uncovering issues across roughly 250 airline records. That is exactly why these reports matter. 1.1.9 is available now.

Development is continuing, and we’ll share the next update when we’re ready. From this point forward, I won’t be posting further development updates in this thread. I’m not interested in having the product or the work behind it dragged into repeated trolling, bad-faith questions, or unacceptable claims. We’ll keep building, testing, and improving ACE privately, and when there is something we’re ready to show, we’ll show it. Until then, there's only one thing you can do, "Wait" /Anil

Guys, SimPassengers 1.1.8 is out. This one got a little out of hand (: It started as a fairly normal update and somehow ended up with 30 supported languages, airline specific boarding music, a pile of announcement changes and a few bugs that had apparently been sitting there quietly waiting for us to notice them. The main change is the cabin language system. Passenger announcements now follow the airline you are flying for. Lufthansa speaks German and English, Turkish speaks Turkish and English, Iberia speaks Spanish and English, JAL speaks Japanese and English, and so on. English speaking airlines stay in English, so there is no silly English followed by the same English again. The other big change is boarding music. There is now a Real World Music library. If SimPassengers knows the airline, it picks the matching boarding music automatically. If it does not, it just falls back to your normal track. We also went through the announcements again after actually flying with them and changed quite a few things that sounded wrong once you heard them in the aircraft. Flight time is now gate to gate, aircraft names are pronounced properly, airport names are spoken as cities, the arrival update has much more useful information, and the captain no longer tells you pushback is about to start while you are already going backwards (: We also found that "cabin crew, be seated for landing" had never actually played. Ever. That is fixed now. And please don't forget to run the launcher and switch to High Quality audio engine The bridge reconnect issue after restarting MSFS is also fixed. The old bridge process was sometimes staying alive after the sim closed and blocking the next one. Anders Bermann also managed to find an airline mapping problem during beta by flying Heathrow to Brussels and getting welcomed "on behalf of BEL". So thanks Anders for breaking it before everyone else could (: There are a few other things in there too, including the new Hall of Fame, Advanced aircraft showing in gold on the live map and the pilot card inside the launcher. Anyway, 1.1.8 is available now. Install it over the existing version as usual. If you find something stupid, let me know. We seem to be getting pretty good at finding those lately (: /Anil

Guys OMG! What a thread. I was away for 2 days trying to handle the related documents required by law (which i will honestly tell what it is) I’ll read through all of it and respond back to you about what’s been going on lately. Thanks a ton... /Anil

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

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

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

I know (: System Wide Information Management System! We're ready for that too! ps: That's what I do for living tho!

To be 100% honest, yes sometimes i'm using AI to perfect my post. Because I don't want to type or send any bad written words to this community, because I respect AVSIM a lot. If we're talking about the LLM behind de ACE of ATCs, that I can not tell, because this fully custom AI modeled and trained by ACE Solutions. Since actually my company's real focus is on real world aviation and that information can not be shared because of signed NDAs and what not. For the audio part, we're partnering with couple of Amazing Audio Generation software companies but it will be based on how a user wants to pay? For example. if they want the real deal, it'll cost more, but if they are ok with standard quality it will cost less. And for the final part, actually VFR and chopper operations are already done, but I don't want to give all features in the release, because it's hard to control, hard to test and also very time consuming to fix bugs. But I can safely say, those feature will be free-of-charge. And finally, yeah it's gonna be monthly subscription based, I can fight for this choice for days or weeks or months but believe me the money behind this thing is super demanding, requiring those server payments and everything. Ohhh not to forget, yes if you don't wanna do STT (Speech to Text) you will still have text options too.

Fair criticism. The original post was intentionally high-level, so let’s leave the philosophy behind and talk about what ACE actually does. First, on the question of whether you will be properly vectored: If ACE could not issue tactically correct vectors, there would be very little point in us talking about AMAN, DMAN or Director logic in the first place. Vectoring is not the impressive part of the architecture. It is the baseline. ACE is not built around a simple “pilot asks, ATC replies” model. Above the tactical controller layer, ACE has separate traffic-management systems responsible for sequencing arrivals, managing departures, balancing flow and deciding how aircraft should be integrated into the wider traffic picture. AMAN looks at the arrival stream. DMAN looks at departures. Director logic sits above the tactical level and works with the traffic picture as a whole. So the heading, speed or altitude instruction you receive is not intended to be an isolated response generated because your aircraft happened to need something at that moment. It is the tactical result of a larger sequencing and traffic-management decision. That distinction matters. AI Traffic Integration FSLTL is fully supported today. ACE also has its own traffic injection capability, so the system is not tied to a single third-party traffic package. Additional sources such as AIG or JustFlight traffic can be integrated without changing the underlying ATC architecture. For live traffic, ACE currently uses OpenSky. When you are online, ACE retrieves the available real-world traffic picture and uses that data to construct its own virtual traffic environment. Once inside that environment, those aircraft are not decorative traffic. They are traffic. ACE sees them, sequences them, separates them and manages them through the same traffic-management architecture used for the player aircraft. And yes, the user aircraft receives traffic information as well. Traffic advisories are not reserved for AI pilots. If another aircraft becomes operationally relevant to you, ATC can call that traffic to you. So, plainly: FSLTL: supported. Own injector: yes. Live traffic source: currently OpenSky. Traffic advisories to the user aircraft: yes. Traffic sequencing and flow management: AMAN, DMAN and Director-level logic. Weather and METAR Sources ACE is weather-aware, and the user is not locked to one METAR provider. You can choose which source ACE should use, including the simulator’s own weather environment, VATSIM METAR data or IVAO METAR data. The selected source becomes part of ACE’s operational picture, so weather-related ATC decisions are based on the environment you have actually chosen to fly in rather than forcing everyone onto one provider. If you are using simulator weather, ACE can work from that environment. If you want your operation aligned with VATSIM or IVAO weather data instead, you can select the corresponding source. I will address the more specific weather scenarios you raised, such as deviations, convective weather, holding and rerouting, separately, because those deserve proper operational answers rather than another yes/no soundbite.

Thank you, much appreciated. I agree, the ATC space still has some very real gaps, and that is exactly what made us want to approach it differently. Over the next few posts I’ll be sharing more of the operational detail behind ACE, so you’ll get a much clearer picture of where we think those differences are.

Good question. The initial beta is focused on IFR operations, not specifically on airliners or large hubs. So the real boundary in the first release is flight rules, not aircraft size. GA aircraft operating IFR from smaller and regional fields are absolutely within the intended scope, provided the relevant procedures and airport data are available. VFR will not be part of the initial beta release. We are deliberately expanding the operational scope in stages, with VFR and broader GA operations coming later as the IFR core matures. So in short: small aircraft, yes. Small airports, yes. IFR, yes. VFR, not in version one.

You are def right! i had some family related problems that i had to handle, but everything is a-ok right now and a new version is coming up tomorrow.

You absolutely did, Dave (: You called it very early. Kennedy Steve is indeed part of ACE of ATCs, and I think you’ll enjoy what we have coming next. There is a lot more operational detail to share now, so I’ll be getting into that properly in this thread.

Hey vonduck! Thanks a lot for your kind words brother. Having Kennedy Steve on board is something we’re incredibly proud of, and we’re only just getting started. Can’t wait to finally get ACE of ATCs into your hands! ❤️

Thanks a lot! Really appreciate that — especially coming from someone building on the commercial side of the flight sim community. We’ve put a huge amount of work into ACE of ATCs, and we’re very excited to finally start showing what it can do. There’s a lot more to come very soon. Would genuinely love to hear your thoughts once you’ve had a chance to see it in action!

For the last couple of months, we have been quietly building something that started with a very simple question: What would it take to build an AI Air Traffic Controller that actually understands the operation, not just the phraseology? Not a chatbot with an aviation prompt, not a system that simply reacts to the last transmission, and not an ATC voice generator that happens to know how to say "cleared to land." We wanted to build a controller. Very quickly, we realized that meant building much more than a controller. We also realized something else very early: we did not want to be the people deciding whether our own ATC system was convincing. If we were going to take this seriously, at some point somebody who had actually spent a career on the other side of the frequency was going to have to look at it and tell us where we were wrong. More on that later. State before languageACE of ATCs is designed around the actual operational state of the airport and the airspace. Aircraft are not treated as isolated conversations. They exist inside a continuously changing traffic picture where position, route, runway configuration, sequencing, taxi state, frequencies, clearances, previous instructions and the movement of other aircraft can all affect what should happen next. ACE maintains that state continuously. It knows where an aircraft is, where that aircraft is supposed to go, and whether it is arriving, departing, taxiing, holding, lining up, landing or parking. An instruction issued thirty seconds ago still matters thirty seconds later. A decision made for one aircraft may affect several others. That is where a huge part of our work has gone. From gate to gateACE is not limited to one phase of flight. The same system can carry an aircraft through: Taxi -> Departure -> En-route / Arrival -> Approach -> Landing -> Taxi -> Parking while preserving operational state throughout the entire chain. On arrival, ACE can work with sequencing, descent, vectoring, approach clearance, landing and runway vacation. After landing, the aircraft does not simply disappear. The operation continues through frequency changes, Ground handoff and the taxi network toward parking. Departures and arrivals can exist inside the same operational picture. The controller is not the entire brainThis became one of the most important architectural decisions in ACE. We did not build one giant AI model and ask it to control everything. Behind the controller sits an operational architecture responsible for looking at the traffic picture before the radio transmission is ever generated. That includes our AMAN, Arrival Manager, which looks ahead at inbound traffic, arrival demand and sequencing rather than treating each arriving aircraft as an isolated conversation. Then there is DMAN, our Departure Manager, which looks at the outbound side of the operation, including departure demand and how those departures fit into the larger airport picture. Above those systems sits what we internally call the Director. The Director is not another radio controller. It is an orchestration layer whose job is to look at the larger operational picture and coordinate what is happening underneath it. A Tower controller should not have to rediscover the entire airport every time a pilot presses the PTT button. A Ground controller should not invent the ground operation from scratch, and an arrival controller should not sequence aircraft without understanding what is happening ahead. The intelligence is distributed across the system. The controller is the part the pilot talks to. It is not the entire brain. The radio is an interface, not the source of truthACE does not reconstruct reality from a transcript because the system already has its own operational state. The radio conversation interacts with that state rather than defining it. That means ACE can reason about information that may not have been spoken in the last transmission at all: aircraft position, route progression, runway occupancy, traffic ahead, previous clearances, controller ownership and what the aircraft should logically be doing next. That separation between language and operational state has become one of the foundations of the project. Route awareness and progressionAircraft are not simply pushed toward random waypoints. ACE follows route structure and understands where an aircraft currently exists within that route. The controller can therefore work with the progression of the flight instead of repeatedly reconstructing it from scratch. The same philosophy continues during approach, landing and taxi operations. Progression matters. History matters. State matters. Readbacks matter tooPilots can read instructions back, and ACE validates those readbacks against the clearance that was actually issued. A correct readback can progress the operation, while an incorrect one can be challenged. The system therefore has a concept of what it said, what the pilot was expected to read back, what the pilot actually said, and whether those things agree. That sounds simple until you try to maintain it across a stateful operation involving multiple aircraft, multiple clearances and multiple controllers. And this is also where having someone around who has actually worked real traffic becomes uncomfortable in the best possible way. A developer can look at an interaction and think, "That sounds right." A controller can look at exactly the same interaction and say, "No. Why would I do that?" We have heard that question more than once during development. And ACE is better because of it. Frequencies are operational boundariesTower and Ground are not simply different AI personalities with different voices. They are operational roles. An aircraft that changes frequency should not continue interacting with the previous controller as if nothing happened. The controller handling an aircraft matters. Frequency matters. Handoffs matter. Those boundaries exist inside ACE rather than being left entirely to the language model. Then we went further down the aviation infrastructure rabbit holeOur work around aviation systems has also taken us into areas such as AFTN and AMHS, the messaging infrastructure used throughout real-world aviation operations. That work is separate from ACE itself, but it strongly influenced the way we think about system architecture. Aviation infrastructure teaches you very quickly that important operational information cannot simply live inside a conversation. State needs to exist independently, events need to be traceable, transitions need to be observable, failures need to be reproducible, and systems need to know what happened before something went wrong. That philosophy now runs throughout ACE. Clearances, state changes, controller actions and operational transitions are not treated as disposable lines of text. They are part of a larger causal system. So, for the software engineers and aviation infrastructure nerds reading this: yes, we care about causality, deterministic state transitions, missing context, handoffs, reconnects, incorrect readbacks and what happens when the pilot tunes the wrong frequency. And yes, we have spent an unreasonable amount of time deliberately trying to make ACE fail. Because making an AI sound like ATC is not particularly interesting to us. Making it understand what the controller is responsible for is. Then we started feeding it the real worldEventually, we connected ACE to live traffic data and started running the system against real operational traffic pictures. That changed the question. It was no longer: "Can an AI control an airplane?" It became: "Can it understand an airport?" That is the problem we have been working on ever since. We have built regression tests, causal checks, operational guards and end-to-end scenarios specifically to find situations where the system might sound convincing linguistically while being wrong operationally. Because for us: Sounding like ATC is the easy part. Thinking like ATC is the product. And we think we have built something fundamentally different from what people currently expect when they hear the words "AI ATC." That confidence does not come only from us running our own tests and congratulating ourselves when they pass. For a significant part of this journey, someone with decades of real-world ATC experience has been looking over our shoulder, challenging decisions, questioning behavior and occasionally sending us straight back to work. We will introduce him properly in a moment. First, there is something we want from you. Public BetaACE of ATCs is entering BETA. For the first public beta, we are opening exactly 10 seats. Not because we are trying to manufacture scarcity. Because we want the first ten people using ACE to have our attention. We want people who will actually fly, test, challenge and break the system. People who will notice when something operationally does not make sense and tell us exactly why. If you are looking for a polished product where every edge case has already been discovered, wait for the release. If you want to be one of the people who helps us discover those edge cases, this is your invitation. We are particularly interested in experienced flight simmers, real-world pilots, controllers and people with enough aviation knowledge to make our lives difficult. There are 10 places. If you want one of them, email us at: [email protected] Tell us a little about yourself, what you fly, your aviation or simulation background, and why you want to test ACE. We are not looking for ten people to tell us how impressive it is. We are looking for ten people capable of proving us wrong. And if ACE survives them, we open the doors wider. One last thingRemember the controller we mentioned at the beginning? When we decided we wanted someone from the real world to challenge ACE, we did not exactly choose the easy option. We wanted someone who had spent his career handling traffic at one of the busiest and most demanding airports on the planet. Someone who would know immediately when something sounded clever but made no operational sense. Someone who would not care how complicated the software was if the controller made the wrong call. So we brought in Steve Abraham, retired JFK Ground Controller. He did not come in to record a testimonial. He worked with us. He challenged the system, challenged us, talked ATC with us and helped us understand the difference between something that merely sounds like a controller and something that begins to behave like one. And today, Steve officially joined ACE of ATCs. We could write another thousand words telling you what he thinks. But after everything above, that would be a ridiculous way to end this post.

Hi Captains, First of all, I sincerely apologize to those who have not been able to use SP as expected. We recently identified two major issues: Some users were unable to start a flight because the Bridge continued to request a login, even though they were already logged in through the Launcher. In some cases, the Bridge was unable to read the aircraft’s GPS position correctly. Let me start with the login issue. SP uses WebSocket connections to provide fast, real-time communication between the Bridge, Launcher, and our servers. However, users connect from many different network environments, with different firewall rules, antivirus software, NAT configurations, and system setups. We released two versions intended to resolve this issue. Those updates worked for some users, but unfortunately did not solve the problem for everyone. In a few cases, they also caused SP to stop working for users who had previously been able to run it. At that point, instead of continuing to release speculative fixes, we enabled verbose logging, collected connection data, and investigated the complete login flow. We found the problem and fixed it. Our servers are now more tolerant of different network environments, and the login issue appears to be resolved. According to our logs, 18 user connections have been successfully established since last night, with no recurrence of the problem so far. The important part is that this was a server-side fix, so no new SP version is required for the login issue. Now, regarding the less common GPS position issue: Not everyone is running SP on a high-end computer, and some systems may already be under heavy load when a flight is started. In certain cases, the Bridge attempted to read the aircraft’s position before the simulator was ready to provide it, causing the flight to be rejected. We have fixed this as well. However, this correction requires a new SP version, which is scheduled for release this Sunday. Thank you again for your patience, your reports, and for helping us identify the problem. Blue skies! ps: and one final note for @Sparkrite his patience and help us identify the issue was golden. Thanks brother. /Anil

@Sparkrite Hi! I see one problem with the screenshot and that is "[email protected]" email address. That was my mistake and was changed to [email protected] with version 1.1.7 To be on the safe side, can you please completely uninstall SP and redownload and reinstall SP 1.1.7 That problem was fixed with the latest version tho. /Anil

Hi Captains, There are some very fair questions here, so let me clarify the SimBrief point in a simpler way. First of all, yes, ACE of ATCs is not architecturally married to SimBrief forever. In our architecture, SimBrief is an adapter. If another source can provide the same level of structured operational data later, we can build another adapter for it. But for v1 and for the first beta, SimBrief gives us something very important: a consistent OFP-level operational starting contract. For ACE, SimBrief is not just “import the player’s route and read it back.” It helps us set the operational scene. It tells ACE what kind of structured airline IFR operation the player is trying to fly: departure, destination, accepted route, timing, aircraft context, alternate, fuel and reserve assumptions, NOTAM context and the dispatch picture around that flight. Once that scene is established, ACE can build the traffic world around it. Departing AI traffic can be generated with proper departure intent and SID service. Arriving AI traffic can be generated with arrival intent, STAR service, vectors, visual approach logic where appropriate and sequencing pressure around the player’s operation. So the important distinction is this: AI aircraft do not need SimBrief because ACE can generate their internal dispatch objects itself. The player aircraft is different. We do not want to guess the player’s operational intent in v1. SimBrief gives us that intent in a standardized OFP form. After the session starts, ACE is not simply replaying SimBrief. ACE owns the live operational state: traffic, runway state, clearances, readbacks, airport state, weather, sequencing, AMAN/DMAN decisions and the moving bubble. So SimBrief is not the whole ATC system. It is the initial dispatch/OFP anchor that lets ACE build a disciplined operational world around the player. [nerd-data-incoming] ACE of ATCs is being developed with a hexagonal architecture. That means external data sources are adapters/plugins around the core domain. Today, for v1, that adapter is SimBrief. Tomorrow, if another source can provide the right structured operational contract, we can build another adapter for that too. [/nerd-data-incoming] I do not want to sound pushy about the SimBrief requirement. It is simply the cleanest way for us to keep the first beta focused, consistent and operationally disciplined. As always, With love and blue skies, /Anil

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

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

Thanks, that is a fair post. I am definitely very passionate about this project, and I accept that this can sometimes come across stronger than intended in my replies. I have no problem at all with someone saying ACE of ATCs is not for them, or that they do not like subscriptions, teaser content, or a SimBrief-based workflow. Those are valid personal preferences. What I do try to keep separate is constructive criticism versus personal hostility or assumptions about intent. We are happy to discuss the former all day. @Christopher Low phrased that distinction very well. 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. For GA and VFR, the plan is not to treat it as “airline IFR but smaller.” It needs a different model: pattern work, local VFR procedures, flight following, controlled and uncontrolled airport transitions, and a different workload style. It is part of the broader direction, but the current public focus is airline IFR and controlled airport operations because we would rather get one scope right than promise everything at once. (not promising but what we have in our mind is, whenever a VFR flight is created, we're planning the ATC to speak in the native language, not in aviation language. As I said, not promising, just in our pipeline) Helicopters are even more specific, so I do not want to overpromise that right now. They deserve their own operational thinking, not just a checkbox. So yes, the early WIP posts are mostly airliner-focused because that is the first area we are trying to make solid. But... This kind of criticism is totally golden! This is our fuel and this is the way want to evolve. With love and blue skies. /Anil

According to your latest email, I believe the problem is solved. Thanks /Anil