marlon445

I appreciate you clarifying this, and I want to start by acknowledging that. If we both agree that core system failures, crashes during standard procedures, and severe performance bottlenecks on launch day represent clear quality assurance failures that shouldn't be excused, then our actual points of agreement are indeed much larger than it first appeared. Where I still see things a bit differently is how we define an unforeseen conflict versus code resilience. I completely agree that no beta team can test every permutation of hardware out there. But in modern flight simulation, tools like SPAD.neXt, FSUIPC, or Chaseplane and Active Sky aren't obscure edge cases—they are standard operating equipment for a huge portion of the community. When custom axis bindings or frame rate drops cause autopilot logic to trip out or flight dynamics to freeze, it often points to brittle underlying architecture, such as tying system loops directly to frame rates or failing to handle unexpected input parameters. While a developer can't test every setup, building systems that don't shatter when exposed to common community tools is still part of writing solid software. This is another point where our definitions diverge slightly, specifically around what constitutes a "working" add-on. From my perspective, performance is functionality. Flight simulation relies heavily on smooth, consistent execution, especially when hand-flying. If an aircraft tanks frame rates into single digits or stutters violently on a mid-range PC or console, it doesn't really matter how accurate the flight computer logic is in the background—the aircraft is functionally unflyable for that user. Trying to separate system fidelity from frame rate performance feels like an artificial distinction when the end user experience is ruined either way. Personal attacks, insults, and harassment directed at individual developers are completely unacceptable and poison the community. Where I want to offer a protective shield, however, is for non-buyers who use online reports to make informed decisions. Because digital flight sim add-ons are almost universally sold as non-refundable final sales, potential buyers have no safety net. Watching launch-day streams and reading initial reports is the only self-defense consumers have. If stream after stream clearly shows unplayable performance or system lockups, a non-buyer raising concerns based on that evidence isn't being toxic - they're exercising healthy caution and warning others before they drop their hard-earned money. Ultimately, I respect that your main goal was to push back against unfair pitchfork mobs, and I share that frustration. But when developers release products with severe performance bottlenecks or fragile code, the line between an innocent edge-case bug and a product rushed out the door gets very blurry, and I think it's vital that we keep holding the bar high for what gets released at full price.

You shift the goalposts by conflating minor edge-case bugs with fundamental product flaws.I rarely expect 100% bug-free software on day one. What I expect is a product where the core systems function reliably as advertised. There is a vast distinction between a misplaced switch texture or an obscure audio loop bug, and broken LNAV/VNAV logic, inaccurate flight dynamics, or desktop crashes during standard procedures. Nice exercise in whataboutism. Normalizing flawed launches creates a race to the bottom, where releasing semi-finished software becomes an acceptable commercial practice simply because "everyone else does it." Nice strawman. Disappointed customers are rarely complaining about hyper-obscure bugs triggered by non-standard actions on niche hardware setups. Most day one or week bugs are standard sop related. When basic, routine flight profiles trigger severe issues, it indicates that internal QA and beta testing lacked basic coverage. I am not paying $50 to $100+ to act as uncompensated quality assurance testers for a commercial release. You do not need to be a software engineer to evaluate whether a paid product works as advertised, just as you do not need to be a chef to know when a meal is cold or uncooked. Software development is undeniably complex, but complexity is the developer's chosen domain—and the price tag reflects that expertise. When a developer sets a premium price, they are claiming professional competency. Shielding a commercial product behind the excuse of "coding is hard" ignores the basic rules of consumer trade. If a developer charges high-tier prices, the product will be judged by high-tier standards. Technical complexity explains why a bug happened; it does not excuse selling a broken product at full price. Nice deflection technique. Potential buyers do not need to purchase a broken product to criticize its state. Watching unedited livestreams, reading detailed breakdown threads, and watching launch-day reviews are rational ways to evaluate a purchase. If stream after stream demonstrates broken systems, non-buyers have every right to point out those flaws. You ask consumers for empathy, patience, and lower expectations. But from a customer's perspective, empathy does not fix broken autopilot logic, nor does technical difficulty refund hard-earned money. The fundamental issue is not that consumers expect perfection; it is that the flight simulation industry has increasingly adopted a culture of "release now, fix later." While developers face real technical challenges, shifting the burden of patience, testing, and tolerance onto paying customers invalidates legitimate feedback and undermines consumer trust. If only your post were at least well-reasoned; instead, it’s full of false arguments, logical fallacies, and circular reasoning that just don’t hold water.

All your "arguments" in this thread are so embarrassing. Synaptics released a broken plane, full of bugs, crashes, and terrible performance, and you're seriously coming here with arguments like "But hundreds of people are flying it without any problems" and "No software is bug-free." People usually outgrow that kind of reasoning after kindergarten. They can’t even manage to release clean patches and patch notes without causing total confusion again, just like with the -100.

As if that were an argument for anything. When a feature is implemented - in this case, the terminal interior - I take a look at it, and if I’m not satisfied with it, I criticize it. Whether I actually end up using it or value it is irrelevant for now, and it’s also extremely subjective, because your expectations for a scenery don’t have to be the same as mine. That’s why I’m just one of many people sharing their opinion here.

The quality varies greatly from terminal to terminal. Terminals 1 and 2 look pretty good on the inside, but Terminal 5 is a total disaster. My performance drops massively, especially when panning the camera toward the cargo area, regardless of whether there’s traffic or not. It never becomes unflyable (always around the low 30s FPS with FG-FSR3), but it feels choppy. VRAM usage is at 15.2 out of 16 GB (Beyond Traffic / 9070XT). GSX boarding doesn’t work via jetways anywhere. There’s plenty of room for improvement. Overall, the scene just looks strange, especially when there’s fog and low-hanging clouds. Everything shimmers in such a strange way. Between Runway 28L and along the taxiways leading to Runway 28R, there are mountains of sand floating in the air. That's all I noticed during my first flight with the A350. The scenery is better than FSDT's, but that's not saying much. Once the hype dies down, the flaws will become apparent—and pretty quickly, at that.

As expected, performance in the A350 is a total disaster for me. It runs even significantly worse than it does at Heathrow (9850X3D, 9070XT, 64GB DDR5). The GSX profile doesn't work either (there are supposedly no jetways anywhere), and on top of that, there are all these graphics glitches. All in all, a typical Ini release.

Let’s be entirely direct: this explanation feels like a defensive excuse for a project that has lost its focus. We all know software development isn’t a straight line, but after two years of investment, those lines shouldn't be running in circles. The community's frustration isn't about a few minor bugs; it’s about massive, unmanaged scope creep. Beyond promised a revolutionary AI ATC, but you pivoted into building a highly complex, bloated external traffic injection engine. By taking on the immense burden of simulating entire airport ecosystems instead of polishing the core IFR and VFR experience, you’ve forced your user base to act as alpha testers for a traffic utility. This unnecessary expansion has driven a relentless cycle of exhausting structural rewrites that repeatedly reset the stability clock to zero, trapping us in a loop where a single hotfix breaks taxiway pathing, gate assignments, or ground comms—completely ruining flight immersion. Claiming the only alternative is to halt updates entirely is a total cop-out, especially since BeyondATC already operates both a standard Early Access version and an Experimental branch. Having this infrastructure means you have the tools to isolate volatile, philosophy-shifting code. The fact that system-breaking chaos still paralyzes the experience proves the issue isn't the nature of software engineering; it’s a failure of code isolation and a lack of baseline quality control. Early Access is a partnership built on mutual value, not a blank check for perpetual architectural instability. We want to help build Beyondl, but we need to see actual forward momentum toward a stable product, not a project chasing its own tail.

What you’re describing here is AI-assisted work—something that has, I believe, already become a firmly established part of software development. However, I would point out that all the major providers rely on LLMs; while these can ingest vast amounts of data, they frequently get things wrong. Furthermore, if you point out errors to these models, they have a tendency to get stuck in a feedback loop where they keep trying to "correct" their incorrect information with even more incorrect information. It is also incredibly easy to trick LLMs by presenting actually correct information as if it were wrong. So, there is nothing wrong with offloading the tedious, exhausting, and time-consuming parts of scenery development—tasks that are easily automated—to AI. But handing over the entire development process to AI isn't the way to go. You could try it, of course, but then you’d end up with results like Microsoft’s Windows localization in my native language; it contains so many appalling textual and grammatical errors that it was almost certainly generated by AI without anyone ever reviewing it afterward. I also generally consider the development of scenery to be a less creative process than creating video games themselves. When you recreate an airport, the real-world model already exists; your task isn't to creatively design a new airport, but rather to replicate the existing one as precisely as possible.

The odd thing is that BATC didn't have these issues that are often mentioned for a very long time. But, for some reason, the programme is steadily regressing, becoming increasingly unstable and unreliable, and getting cluttered with unnecessary features, such as GSX integration. When I bought Beyond two years ago, I was really happy with it. These days, however, every flight just annoys me. This is because traffic is getting in the way again, controllers are issuing stupid vectors, and traffic still costs me 20–25 FPS, etc. I know it's Early Access, but that usually implies development, not continuous breakdown.

Exactly. I’ve heard the same thing from experienced A380 and A350 captains—that both aircraft handle with incredible agility, and you often find yourself surprised by it. I trust their feedback more than that of simulator pilots who say, “The plane is heavy; it has to handle sluggishly.”

I consider the flightmodel feedback from the community to be rather irrelevant, given that a large proportion of respondents to a popular survey assume they can land a real A320 lmao

It looks terrible. The exterior design is completely wrong, and the cockpit is a total mess. It's as if they just experimented with the wrong proportions and fonts. In this regard, no one can beat the ini A350; the exterior model and cockpit are among the most beautiful in the simulator. However, there are issues under the hood, particularly with stability (WASM, etc.), which is why I'm more excited about Rhodiumcode's system-level capabilities.

Is that because of Beyond or the Fenix? The last time I flew it, the VNAV was completely useless, and I couldn't make a single descent without using speed brakes the entire way down. I actually have a nice screenshot where, on final approach with flaps 2 out and a 12-knot headwind, I’m gaining speed at 900 FPM instead of losing it. Needless to say, I’ll never fly that thing again. In the A350, at least, I haven’t had any issues with the descent anywhere; everything went smoothly in Frankfurt yesterday. And the new instruction to fly over a STAR point at a certain altitude and then continue descending makes it even easier. The only annoying thing is that Beyond always makes you fly through the entire transition instead of using sensible shortcuts.

I once asked on Discord why Beyond always uses approaches that don't seem to make sense. In Singapore and Bangkok, for example, it always uses RNAV approaches instead of ILS ones. The response I received was that Beyond prioritises approaches that connect to the final waypoint of the STAR, and that many of these are not ILS approaches. Of course, it still doesn't make sense for Beyond to rely on a visual approach in the US (the flawed logic you mentioned), but it would probably be a different matter if the STAR led to the final approach. At KSFO, a visual approach is always used, whereas when approaching from the east at KLAX, I always get the ILS.

For me, TC leaks memory like the Titanic at every airport. I'd love to use it because Beyond Traffic has a significant impact on performance and Live Traffic isn't suitable for me as I don't fly in real time in the simulator.