Dialex

That’s a question for Navigraph, really. If you want my opinion, I think it would be quite unexpected. At the same time, we wouldn’t have expected live traffic either before so who knows! But that would be a discussion between Navigraph and FR24, we’re not in the equation.

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.

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

My issue with this is that we haven’t tried to hide anything, this has always been public information. From the beginning, we’ve been clear that this would take years to fully develop. That’s not an excuse, it’s simply the reality of the complexity involved. At the same time, it feels unfair to criticize the pace of progress while still choosing to purchase the product knowing it was early access and that it would take this much time to develop. The issue seems less about transparency and more about expectations around how quickly things should improve. Our devs haven’t abandoned the project or left it sitting idle. Progress has been made, including improvements to vectoring. Are we where we ultimately want to be? No, but saying nothing has improved overlooks the work that’s already been done, it’s documented and our fixes are linked to bug reports that are sent to our attention. You may not see the improvements in your case, but I don’t think it’s fair either to conclude we haven’t done anything at all. At this point, the conversation doesn’t feel productive anymore. It seems the frustration comes from the speed of development rather than the direction. And while that frustration is understandable, this isn’t a simple problem to solve. If it were, a much larger and more established team as the Asobo one would have already done it, and yet during all these years nothing convincing has been implemented. Expecting a small team to solve it in a matter of months or even just one year just isn’t realistic. We were also upfront about this being an early access release. In fact, the decision to release it early came from the community. Otherwise, we would have waited. Given that, it’s difficult to place the blame on us when the expectations were clearly communicated beforehand. Everyone is entitled to their opinion, of course. But I don’t think it’s fair to disregard the transparency we’ve maintained throughout the process or the information that was available before purchase. It does feel that no answer is going to satisfy, even though we made our best to present it correctly to place expectations in the right place.

That’s exactly where we are going in circles, and I’m sorry to say this again, but it’s still in early access. If it was ready yet, there would be no reason to keep it in early access and we would advertise it as a finished product. Guess what, it’s not! And we’re pretty much aware of it and I’ve said this numerous times here. But again, you’re putting expectations that does not align with the development process. Every patch includes fixes and improvements related to IFR, and these updates are documented in our patch notes. Everything is public, you can even check it on our website now. The fact that your specific issue may not yet be resolved doesn’t mean it’s being ignored or we aren’t working on core systems regarding IFR. Sometimes I feel like you guys think we do this on purpose. We want to have it perform and be as reliable as you all want. The difference is that we recognize it will take time to get there.

That’s exactly why it’s still in early access, so I’m not sure I follow your point..? I’m also struggling to understand the overall negativity. It’s fair to say the current version doesn’t meet your expectations and to explain why, but I don’t think it makes sense to judge how others enjoy BATC based on their aviation background or experience level. People can still find value in it as it is and believe it or not, even those with a similar level of knowledge to yours can enjoy it as well. That doesn’t mean there are no issues at all. That’s your conclusion, not mine. Anyway, I feel like we’re starting to go in circles here.

Sorry but it gets tiring to see my words twisted. I don’t know what your goal is, but I would expect some fairness in the discussion.

I’m not here to be put on trial or to defend myself, to be completely honest. My goal is simply to explain how we work and to share information with those who are open to it, especially during this early access stage. As for moderation, we handle it the same way any well-run community does. Our Discord isn’t a place for unrestricted free speech, there are guidelines and we certainly expect people to follow them. That said, people are absolutely free to share negative experiences (and yes, there have been some), as long as it’s done respectfully and within the rules. We don’t mute people for criticism. You can call them excuses if you want, but there are limitations. Some things simply aren’t possible to address right now, and others might be, but later. This is a process and we have to make choices along the way. Not everyone will be pleased and we’re very aware of that. If you’re not willing to accept that, then yes, you’ll probably end up disappointed. We’re not trying to please everyone or fulfill every individual request. What we are trying to do is build something genuinely immersive and convincing, within what’s realistically achievable at this time. Knowing that we are certainly not finished working on it. But again, if you expect all of this to happen overnight, you’re likely just setting yourself up for frustration. Our goal is to provide a good ATC experience even for people with zero real-world experience and I don’t see anything wrong with that, especially if they can be happy in the current state. A lot of people still find the enjoyment with it. But you’re assuming that we’re only trying to cater to that group, which isn’t the case. If you’re still unsure, feel free to revisit later. Development is ongoing, and we’re far from finished as I keep saying. We already have a number of real-world controllers and pilots providing feedback, across both IFR and VFR, and from different parts of the world. That input is being taken into account when we work on the appropriate part of the software. Just some food for thought.