Dialex

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.

That’s not true. We have over 45,000 members and everything is going well. I don’t understand what about my attitude is off-putting when I’m sharing information people might not have here. I certainly don’t blame anyone and I’m sure Ryan won’t take it personally.

We’ve been very transparent that EA will last for years. Regarding your other assumptions, I’m afraid they’re simply incorrect. I understand the idea of developing ATC in modules but that oversimplifies the interconnected nature of everything. You’re also overlooking the fact that the changes in vectoring primarily affect the framework. The current system incorporates far more variables and will address problems that were more challenging to solve with the previous version. And as I’ve already pointed out in the other thread, we also need to go forward with the roadmap. If we started to work on VFR, it’s because it was the right time to do so.

Then wait? Given your feedback, you should have even waited for the official release, without purchasing an early access software. I believe I personally responded to all your questions, but I don’t feel like you are willing to accept the answer. At this point there’s nothing much left I can do.

To begin with, I believe you 😉 I think what I’m trying to say is that I would also appreciate it if people could trust that our team genuinely wants the product to work just as much as you all do. We don’t ignore issues, and we have no reason to do so. Everything is transparent, including bug reports, responses, and ongoing discussions. So please bear with us while we work on fixing things, even if it can be frustrating at times. This is not targeted to anyone in particular, it’s just a general comment to keep in mind. Still with the disclaimer that I’m not in the development team: Just to give some perspective, I’m pretty sure the team would love to have these things working correctly. If something isn’t, it’s not because they don’t want to fix it or incompetence, but because it’s genuinely more complex than it might seem. The challenges are also different when you’re building ATC software rather than an aircraft, and that doesn’t always require the same logic or skill set. An aircraft is a totally different piece of software, that does not use the same technologies. I wouldn’t assume the same problem could be solved in the same way, food for thoughts. Another thing I’ve noticed is that when we take a closer look at some logs and reports, we sometimes don’t actually see the issue. When we try to replicate the flight in a dev environment, the path, vectoring and descent profile can end up looking perfectly reasonable and normal. That brings us back to the main challenge, which is that we need to be able to see and reproduce an issue before we can start thinking about a solution. All that process is time consuming, and I’m not even talking about implementing a solution yet! I’m not saying those issues don’t exist, but this is one of the difficulties we run into when handling all these reports. That’s also why it’s always important to keep submitting them, even if it feels like there are already plenty. This isn’t necessarily a sign of their quality and doesn’t necessarily mean that particular example helps us understand the problem.

Please allow me to clarify a few points. I want to stress that this isn’t meant to dismiss anyone’s feedback or come across as defensive. Rather, it’s an attempt to provide broader context that may help explain some of the differences in perception around the product and recent updates. So do not take this personally. It’s important to recognize that user experiences can vary significantly. The fact that something isn’t working as expected in one case doesn’t necessarily mean it isn’t working at all. When an update is released in early access, it indicates that the system performs better than the previous version, but it does not imply that it is free of issues. Additionally, “Vectoring 3.0” represents more than just immediate visible improvements, it introduces a more robust underlying framework. This new structure enables the team to address scenarios that may have been difficult or even impossible to fix previously, as we take a lot of new parameters into account. As new reports come in where vectoring behaves suboptimally, this framework gives the team the ability to analyze and improve those cases more effectively if there’s any need. That’s the other side of the coin with transparency 🙂 The Discord server is the official support platform, so it will naturally contain a high volume of reports, especially during an early access phase. That’s expected and, in fact, necessary to improve the software. It’s also worth noting that not all reports reflect the same issue. Some may stem from different edge cases (from a development perspective), misunderstandings, or even user error. While your experience may indeed be shared by others, a support-focused space will inherently concentrate reports of problems, which can sometimes amplify the perception of widespread issues. What you won’t see is how many users do not complain and have benefitted from those enhancements. We monitor reports and it’s still globally positive even if there are areas of improvement. For context, I’m not part of the development team. However, even when feedback is well-intentioned, certain phrasing can come across as discouraging, especially considering the scale of work involved in recent updates. The latest update represents a significant effort from the team to rebuild core systems, improve overall stability, and lay the groundwork for features such as VFR. These foundational changes are not always immediately visible, but they are essential for long-term progress and flexibility. When statements suggest that such a big update has “changed literally nothing”, it can be difficult to interpret that constructively, particularly when internal testing and supporters’ users have reported improvements in parts of their experience. That said, it’s completely fair to point out what isn’t working on your end. Experiences can vary quite a bit, though, so what hasn’t improved in one case may have improved in others. Which is why we need updated reports to monitor our changes.

I still need to bring a clarification to this. BeyondATC has never been driven by sales. In fact, the pricing model was specifically designed to lower the barrier to entry, so simmers can access a richer ATC experience in MSFS without a significant upfront investment. We would have made different decisions if we wanted to maximize the revenue from that project. What we are doing today is simply following our roadmap, actually the same roadmap we introduced before early access and publicly available. The key misunderstanding is the assumption that moving on to the next step means previous steps are fully complete or in a final, release-ready state. That’s not how development works, especially in early access. If we had chosen not to begin work on VFR, the situation wouldn’t be any better. There would simply be ongoing complaints about early access lasting “forever” along with frustration about a lack of visible progress on the roadmap. At its core, the issue isn’t the order in which features are developed or released. It’s the misconception (or misunderstanding) of what early access actually means and how the development process works, despite our best efforts to clarify these points. Normally, users only see the finished product. They don’t see the full cycle: implementation, testing, bug fixing, and stabilization, and how much time it takes because you have to go through those cycles multiple times as you implement new features. However, when you buy early access software you can’t skip the whole process. But after nearly two years since BeyondATC became available, I would sincerely hope that anyone can see, through all the patch notes, that the team is genuinely committed to improving both the software and the overall experience, regardless of how long that process takes.

It would really really help if everyone relied on the information we share through our official channels. Cap already addressed this exact concern in the first VFR video released alongside the announcement of the feature: “It’s worth mentioning that we will split up the team for this feature set. Between the three of us, two will be moving on to VFR while the other will be firmly planted in the world of bug fixes and stability. So please do not make the erroneous assumption that our endorsement of one feature comes at the expense of the rest. That is not the case.” Reference of the quote: Given that, it’s really difficult to understand why there’s still an assumption that IFR has been sidelined. We’ve continued to deliver significant updates on that front, including improvements to traffic injection and management, voice recognition and voice models, and more. Whether or not every update resolves all existing issues, the ongoing work clearly demonstrates a strong commitment to that side of the software. Suggesting that IFR development is finished or deprioritized isn’t accurate. It overlooks both the effort already invested and the substantial work that is still planned to further improve the experience.

Honestly, the “buggier version” framing kind of stings a little. We sell two packages, one early access version, where you get access to BeyondATC before its official release. We’ve tried to be as transparent as we possibly could, explaining that it will be a long process, it can have bugs as we actively work on developing all planned features and stabilizing the software. Then we have a supporter’s version, which is for all people that want to… support us. That’s exactly what we sell. Access to the experimental branch is a special perk to show appreciation for extra support but you’re not buying it. At least you shouldn’t do it with that intention. At the end of the day, BeyondATC is a one-off $30 add-on. Every feature we ever ship, everyone will get it at some point without spending more than the early access price. We don’t make any more money from anyone after that purchase. So if we were trying to squeeze people, especially with a buggier version, that would be a pretty bad business model, don’t you think? You’re welcome to disagree with that approach, anyone is free to have their opinion even on the "early access" topic. But “paying to test a buggy version” sounded, at least from my perspective, a bit unfair since we tried to make it very straightforward even with how we name our packages and versions 🙂

For our VFR testing users, we have a wiki page going through the implemented features in this stage one and to help you get through your first flight: https://wiki.beyondatc.net/knowledge-base/vfr/ For those interested, one of the real world controllers that helped us with VFR procedures made a video to showcase VFR in the US: This video is unavailable. A note, the video shows an early, in development build of BeyondATC, you will find some readback errors in the video and the video is not indicative of the final product. VFR is release into the experimental build of BeyondATC while it is matured over time, it is not feature complete, nor bug free but the team will work hard to get all those issues sorted!