Dialex

One of the biggest misconceptions about Early Access is the idea that development should be a steady path toward greater stability, where each update only improves the experience. In reality, that’s not what Early Access means. Early Access simply means you’re using software that is still actively being developed. The product is not finished, and development is rarely a straight line. It happens in cycles: we build new features, integrate them into existing systems, discover unexpected issues, fix those issues, stabilize the build, and then start the process again. The challenge is that every new feature interacts with systems that are already in place. Sometimes those interactions create bugs or issues in areas that were previously working perfectly. Nobody wants regressions, and we do everything we can to avoid them, but they are a normal part of developing complex software. As the project grows, this becomes even more challenging. A larger and more feature-rich application inevitably has more moving parts, more dependencies, and more opportunities for unexpected side effects. Bugs that would have been simple to identify and fix early in development can become significantly more complex as the software evolves, and it sometimes requires to build a new system again with a different philosophy, and it will require more time to refine it and get the same stability again. If you’ve been following the project over the past two years, you’ve probably seen this cycle several times. There have been periods where stability improved dramatically, followed by updates that introduced new issues. We understand how frustrating that can be, but it is also a natural consequence of active development and this should be totally expected. The alternative would be to stop making substantial changes and deliver less updates, which would defeat the purpose of Early Access in the first place. This is why Early Access should not be viewed as a guarantee that every update will improve stability. Instead, it should be viewed as participation in an ongoing development process where progress often comes through iteration: building, testing, breaking, fixing, and refining. While the overall goal is always a better and more stable product, the path to getting there is rarely smooth.

We understand the concern, but unfortunately that is not possible. The only data we receive is live data, and we are naturally not permitted to store it. The reason we have access to live data at all is due to Navigraph's partnership with FlightRadar24. Without that partnership, providing live traffic data would be prohibitively expensive for a $30 add-on. For that reason, we will continue to maintain the historical dataset and update it whenever possible. Because we don't want people to have a subscription to use BeyondATC and because we want to provide good traffic data for those that usually don't fly real time.

As always we can't give any estimated date. Features are released in EA once they're considered stable and complete.

Unfortunately, that assumption is not supported by any evidence and is incorrect. Parking assignments are not based on scenery airline codes, they are derived from the FlightRadar24 data that we license and use. As stated on our website: "Over 1 million+ historical flights globally, ensuring a worldwide coverage, and gate-accurate airlines for every airport."

It’s not that they’re unwilling to grant our request, they simply haven’t responded at all. I assume they receive a large number of requests, many of which likely go unanswered. It's probably not a request that would be high on their list.

We can't do anything unless Asobo adds the possibility of triggering jetways through their API. It's been requested months ago and I don't think it will happen anytime soon.

BeyondATC already uses airport configurations that reflect how airports typically operate. The system takes several factors into account when determining which runways are active. The current system does a good job already even if you could add more complexity. You can learn more about it here: https://wiki.beyondatc.net/knowledge-base/airport-sop/

To clarify again and to avoid speculation: As I mentioned previously in a different thread, whakamolenz created the FSLTL injector. However, once he began working on BeyondATC, that became his full-time focus and he has not contributed to FSLTL since then. The FSLTL project continued under the work of the rest of the team, and the injector has since been maintained and updated by other team members. Because of that, there is no basis for suggesting that BeyondATC may have take action against anyone. In fact, if anything, there could have been opportunities for stronger integration with FSLTL given that whakamolenz was originally involved with the project and knew how it worked, but that never materialized. It is also important to remember that FSLTL has always been a team effort. Even while he was involved, there were other contributors, and they are entirely separate from BeyondATC. They are fully capable of making their own decisions, especially considering that he was no longer involved in the project. All decisions were taken to keep the FSLTL project available for as much time as they possibly could and as a freeware for the community. As for FSLTL more broadly, everyone is entitled to their own opinion. But it is worth keeping in mind that FSLTL has always been a freeware project, while FR24 is a commercial company. They may each have their own reasons for how they choose to communicate.

Thanks for highlighting the issue, it’s been fixed. You can edit your answer if you want 🙂

Hello all, We are currently gathering structured user feedback for BeyondATC and would greatly appreciate input from the community. To support this, we have expanded our Pilot Portal with a survey aimed at better understanding user workflows, simulator habits, and feature priorities. This information will directly inform our development roadmap moving forward. You can access the survey here with your BeyondATC account: https://db.beyondatc.net/forms/cefd4b9b0d58b259 Please note: - Access requires a valid BeyondATC account and license - The survey includes both usage patterns of the simulator and feature-focused questions - We encourage you to share this with other BeyondATC users you may know The survey will remain open until the end of the month. Thank you to everyone who contributes, we really appreciate the support and feedback!

My point is that the comparison being made isn’t entirely valid, since it involves two products built on fundamentally different infrastructures and design choices. Cloud-based solutions, whether for AI or not, can surely scale more easily but that scalability comes with ongoing costs and trade-offs that users end up paying. In contrast, our approach doesn’t allow for the same level of elastic expansion, which means we need to invest significantly more in optimization upfront before delivering a comparable feature, as we need to take into account the performance aspect for different users with different computers.

Just to give an answer to this: yes, you can import from the MSFS world map, with a .PLN or .LNMPLN file when flying VFR. It will eventually be possible with IFR later, but that require some other changes with how we handle all information.

There’s nothing particularly surprising here and it explains the price difference. Adding traffic at multiple airports isn’t just a simple toggle, it can significantly impact performance if it’s not handled efficiently. Each aircraft requires its own route calculations, access to airport layouts, and computing airports SOP for active runways. All of that adds up computationally. That doesn’t mean it won’t be implemented, but it’s not something that can be done quickly. For IFR flying, there’s limited benefit in fully populating nearby airports beyond handling arrivals and departures. VFR, on the other hand, is still relatively new in this context, and broader traffic simulation for it is likely something that will be developed later.

This will help you get your callsign correctly: https://wiki.beyondatc.net/knowledge-base/callsign/

Whakamolenz was the developer that created the injector. However since he started working for BATC, he had no time anymore to contribute on the project. It has been maintained by other members of the FSLTL team