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.