Dialex

Then a good place to start would be to follow the support process each developer has in place. If you’re experiencing an issue, we’re more than happy to receive a bug report along with your log files so we can investigate it properly. As for my honest opinion, I don’t think this discussion is going to lead anywhere. You’ve already made up your mind about who we are and how we work, and you don’t seem willing to acknowledge that the vast majority of users have a different experience. That doesn’t mean those users never encounter bugs or frustrations, or even that there are users that are globally unhappy with it. In fact, the whole purpose of our survey was to identify the most common issues and pain points so we could prioritize improving them. The latest update is the first step in that process. The conclusion you’ve drawn, that because most users are satisfied, we believe there are no problems, isn’t something we’ve ever remotely said. That’s your interpretation, not our position. We’ve consistently acknowledged that issues exist and have been actively working to address them. At this point, it feels like you’re dismissing the reality of software development more than we’re making excuses. We do need to reproduce issues before we can fix them. That’s not an excuse, it’s simply how debugging works. Some problems are difficult to reproduce, and those are often equally hard to solve. If you want to blame us, that’s your choice. It doesn’t change the fact that we’ve been doing our best to improve the software from day one, and we’ll continue to do so. With or without your support.

I feel like you’re missing the broader context here. If we didn’t genuinely care about feedback, we wouldn’t spend time building a custom survey into our platform. We’d just throw together a Google Form. Or even simpler, we wouldn’t run a survey at all. Do you really think we need marketing at this point to “sell” BeyondATC? That’s never been the goal. If making money was our priority, there are countless more effective ways to do that than selectively interpreting survey results. Not only did we publish the survey results, but we also released an experimental update that directly addressed some of the most common concerns users raised. Given that, I don’t see how it’s reasonable to assume the survey had any purpose other than gathering feedback to improve the user experience. That said, I don’t want to spend my time justifying our philosophy or the way we work. We’ve been around for two years. We have a public Discord server, public patch notes, and a clear history of the areas we’ve focused on since the very first build. People are free to share their opinions anywhere they like, but opinions on forums or social media are anecdotal. Our surveys give us measurable data that helps us make informed decisions. Whether you choose to trust us is entirely up to you, but I think we’ve consistently demonstrated transparency and honesty with our community from the beginning.

I think most people here have already addressed the majority of the points you've raised, so I won't go through each of them again. I do, however, want to share one important piece of information. We recently conducted a community survey and we have the results. While no survey is perfect, the feedback we received doesn't support the picture you're describing. The majority of respondents are genuinely enjoying the product. That doesn't mean there isn't frustration or criticism, we know there is, and we have taken those comments seriously, but it isn't representative of the overall sentiment within our user base. As for your suggestion that we could or should be doing things differently: if you have the experience and skills to build an alternative and think you can do better, I genuinely encourage you to do so! There's plenty of room in the flight sim community for different ATC solutions, each with its own philosophy and approach. Or maybe you don't have that knowledge, and then I would seriously refrain from making any comment about how our development process should be managed, because you wouldn't clearly have the whole picture about software development and all challenges associated with it. From our side, what matters most is being transparent with the community. We've tried to be upfront from the very beginning about our development process, our design philosophy, our pricing, and the current state of the software. We know we won't always get everything right, but we've always aimed to communicate honestly about where we are and where we're going. And we have listened to feedback as much as we possibly could, within the limits of our design choices and capacity. I'm sorry that your experience has led you to feel this way. Your feedback is surely valid but personal. Based on the data we have and the feedback we receive every day, however, your perspective doesn't appear to reflect the experience of the majority of our users.

My response is specifically answering a message that I quoted, so I’m not sure why "I should hold my horses" when I can’t even tell you how many times I had spent in the past explaining this, as I have mentioned it’s a common misconception that I have seen regularly from people. And I leave with you the challenge of doing better than us and delivering a full ATC system in a timeframe that suits you best!

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.