anilcougar

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

That is exactly the kind of limitation we have to respect. ACE is not trying to invent a universal taxiway layout or draw its own airport geometry. It follows the airport ground network exposed by the simulator for the active scenery. So if a user’s installed scenery has taxi nodes/pathways that are offset from the painted centreline, the aircraft may visually appear offset even while following the sim-side taxi path correctly. In that case the issue is not always steering logic; sometimes it is simply the difference between the visual scenery and the underlying taxi graph. Scenery-specific correction may be possible in some cases, but we do not want to pretend that every third-party airport can be visually perfect across every user installation. But we are open for all kinds of discussion about this topic. Any idea is welcomed. /Anil

Got the mail, passed to the devs. We will get in touch with you today. Thanks sir!

Hi Anders, Can you please send out an email to [email protected] so that one of Devs can reach out to you and fix the problem? Thanks /Anil

Hi Christopher, Exactly. That is one of the things we are seeing as well. ACE is not drawing its own visual taxi lines; it follows the underlying airport taxi graph/path data. So if the taxi nodes/pathways in the airport data are offset from the painted centreline, the aircraft can look offset even while following the sim-side path correctly. We are adding diagnostics around this so we can distinguish between our own steering/path-following errors and scenery/AFCAD alignment issues. In the long run we may also add scenery-specific correction where it makes sense, but the first step is making sure we are reading the ground network faithfully. /Anil

Exactly! In ACE of ATCs we're following a source-of-truth which actually that's the alignment data coming from DFD files charts and AFCAD data. but sometimes, not every scenery is visually aligned with the real data. That's why they look not aligned but we have an idea, not promising but we may find a solution. We found a way to decode .bgl files and now we're trying to read that data coming from .bgl files and finding the mismatch. But I believe we will find a solution. /Anil

Hi Captains, Thanks everyone, these are exactly the kind of comments that are useful at this stag On the taxiway centreline / hold-short positioning: yes, that part still needs polish. One important distinction though is that the operational source of truth for us is the chart / DFD / procedure side, not the visual scenery itself. The actual physical movement inside the simulator still has to use the airport ground network and scenery data that the sim exposes. If the taxi graph, painted markings, or runway entry geometry are not perfectly aligned in a scenery, that can show up visually in the aircraft placement. That said, we do not want to hide behind that. The surface executor still needs to become better at validating and refining the final stop position, especially near runway holding points, so that aircraft sit correctly on the taxiway centreline and remain properly behind the hold-short line wherever the data allows it. On the departure timing comments: yes, that is absolutely tunable, and the current video is intentionally on the conservative side. The goal is not for departures to wait just because an arrival exists somewhere in the picture. The Director should reason about arrival ETA, runway occupancy, predicted vacate time, departure staging and short-final traffic as one shared operational picture. So yes, more expeditious departures are definitely part of the direction, but only when the timing and separation picture supports it. I will also review the moment around 2:50 again. Some of the radar presentation and spacing logic is still WIP, and this is exactly why we are sharing these videos early enough to catch those cases. Voice / phraseology is a separate layer and we will show more of that later. Right now we are mostly focused on proving the operational behaviour underneath it.

Hi Captains, Here comes our new WIP video showcase. In this video, you will see three operational layers working together: AMAN, DMAN, and the Director. AMAN is responsible for arrivals. DMAN is responsible for departures. The Director is responsible for coordinating the overall traffic flow and making the runway-resource decisions between them. As you can see on the ATC radar screen, there are two arrival streams coming in: one from the north and one from the west. The system sequences the arrivals, manages departure opportunities, and the Director decides when departures can line up, take off, or hold based on the live arrival gaps. There is one small issue in the middle of the video: you will see a rogue 737 moving through some traffic holding short. That one is completely on me. I accidentally tapped the “Spawn puppet” button during the live test, and that caused it. It is only a development/debug feature, of course; there will be no “Spawn puppet” button in the final release. And just not to forget: we have completed the voice-related paperwork, and a very BIG surprise is coming in the next 1–2 days. As always, with love and blue skies. ps: The video playback rate was increased x5 just to keep it short. It's actually a 22min video. /Anil

Hi @rcviani Totally agreed. Just like @Sparkrite informed us, we're looking at the authentication problem right now, that's why we decided to delay this week's update. And your suggestion is right now in our pipeline. I will update you (in this forum) in couple of days and also with notifications and emails. Thanks again for being an early adaptor. There are millions of different computer and software configurations in the world and we're doing our absolute best to find the best sweet spot. But we will do! With love and blue skies. /Anil