1 hour ago, edu2703 said:

but it has serious performance issues

Not to be argumentative but my 220-300 does not exhibit any real performance issues. I routinely get 80-90 FPS on field, 120-140 in flight. YMMV. TANSTAAFL Blue skies,

-B

2 hours ago, UrgentSiesta said:

While I’m very much in agreement with most of your post and its sentiment, the above assertion of a 737 NG/MAX as “1960’s technology” is a comically bad take. Especially as some weird excuse for the incomplete state of most iB releases.

I was only trying to say that the complexity of an A350 or A220 in real life is significantly higher than the NG series of aircraft, and iniBuilds has tried to simulate some of those advances. I did not mean it as an excuse, just a recognition of the reality of the situation -- but I could have said it better.

14 minutes ago, Cognita said:

I was only trying to say that the complexity of an A350 or A220 in real life is significantly higher than the NG series of aircraft, and iniBuilds has tried to simulate some of those advances. I did not mean it as an excuse, just a recognition of the reality of the situation -- but I could have said it better.

I seriously doubt the complexities between peer- level Airbus and Boeing are that much different, particularly when it comes to reproducing them for flight sim.

Perhaps in terms of IRL engineering, but then again, if Airbuses are that vastly more complicated than “simple”Boeings - to what end is it all worth…?

The entire ethos of IRL airliner development is to keep things the same as possible for the longest period of time possible across as many airframe types as possible. I.e., the 350 has an awful lot of 32x code running in it.

And I especially don’t believe that just because the A350 and 220 have all glass cockpits is meaningfully different than CRT’s, etc in terms of modeling for flight sim. The underlying functional requirements are extremely similar, hence the underlying code will be of similar complexity as well.

Again, IMHO the messy launches of iB have a lot more to do with iB’s corp culture than they do with the subject matter.

I mean heck, if we’re going to use a highly diverse product set as probability for roughly finished launches, then arguably Just Flight should be the worst of all, no?

56 minutes ago, btacon said:

Not to be argumentative but my 220-300 does not exhibit any real performance issues. I routinely get 80-90 FPS on field, 120-140 in flight. YMMV. TANSTAAFL Blue skies,

-B

Do you touch the tablet or interact with it a lot? I've found that if I navigate through the tablet options my frames decay or become unstable. If I don't, my frames are like yours.

2 hours ago, edu2703 said:

I believe you completely misjudged my comment and put words in my mouth, thinking my comment is a emphatic defense of developers for broken add-ons on launch.

You claim I am "shifting goalposts," but you are actually moving mine. Nowhere in my comment did I state that game-breaking bugs, CTDs during normal SOP, or fundamental system issues (like broken LNAV/VNAV logic) should be excused because "coding is hard." If an add-on launches with this type of problem, it's clear there was a QA failure and the developer shouldn't release the aircraft with that kind of problem. I believe we both agree on that.

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.

2 hours ago, edu2703 said:

The issue is that this standard SOP is executed across thousands of different hardware combinations, peripherals, frame rates, third-party weather injectors, camera add-ons like Chaseplane, custom control bindings (FSUIPC, SPAD.neXt, etc.), etc. A bug that appears to a user as a "simple SOP failure" is very often the result of an unforeseen conflict at the system/hardware level that no reasonable beta testing could caught.

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.

2 hours ago, edu2703 said:

Synaptic shouldn't have released it without first addressing the low performance issues. Even if the devs had a beefy PC with a 5080, it's impossible that nobody in the beta had a weaker PC and didn't notice how demanding it was. Even with a 5080 this would be noticeable, and considering this plane was released for Xbox, which has performance equivalent to a mid-range PC, optimization should have been a priority.

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.

2 hours ago, edu2703 said:

My criticism was solely and specifically directed at certain users in this thread, directing harsh criticism at Synaptic and iniBuilds developers directly, going far beyond the level of constructive criticism of the product itself.

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.

I did two Air Baltic flights today, using two very nice flag inspired repaints from flightsim.to. The more I fly this aircraft and get used to its quirks the more I love it. Certainly some bugs to be squashed but not enough to get in the way of a nice afternoon of flightsimming.

As an aside, I bought two Air Baltic hub/focus airports on sale 40% off at Contrail, Riga and Tallinn. Both very well done and will be excellent A220 destinations.

5 hours ago, UrgentSiesta said:

I seriously doubt the complexities between peer- level Airbus and Boeing are that much different, particularly when it comes to reproducing them for flight sim.

Perhaps in terms of IRL engineering, but then again, if Airbuses are that vastly more complicated than “simple”Boeings - to what end is it all worth…?

The entire ethos of IRL airliner development is to keep things the same as possible for the longest period of time possible across as many airframe types as possible. I.e., the 350 has an awful lot of 32x code running in it.

And I especially don’t believe that just because the A350 and 220 have all glass cockpits is meaningfully different than CRT’s, etc in terms of modeling for flight sim. The underlying functional requirements are extremely similar, hence the underlying code will be of similar complexity as well.

Again, IMHO the messy launches of iB have a lot more to do with iB’s corp culture than they do with the subject matter.

I mean heck, if we’re going to use a highly diverse product set as probability for roughly finished launches, then arguably Just Flight should be the worst of all, no?

While you can make any aircraft sim as complicated as you want, there are definitely some systems like Brake-to-Vacate and Runway Overrun Warning/Protection (not mention ECAM, especially the blue book ECAMs used in the A350 and A380) that are just objectively more complex than what would be required features in an equivalent level simulation of a 737. I believe the manual for the ECAM memos in the A350 alone is about 1/2 the length of the entire operating manual of the 737.

Edited August 4Aug 4 by Stavros

6 hours ago, Cognita said:

I was only trying to say that the complexity of an A350 or A220 in real life is significantly higher than the NG series of aircraft, and iniBuilds has tried to simulate some of those advances

I respectively disagree. take the packs for example, on a 737 they need to be turned off for engine start. If you don't turn them back on after start you won't have any pressurization or ECS. In the A220 it's "automatic" but really that means the whole system can be ignored. Try turning off the packs in the Synaptic A220 in flight and you'll see they skipped this whole system. Hopefully it will be fixed because I do like the aircraft, but there is a lot of detail missing still compared to the FCOM.

29 minutes ago, Stavros said:

While you can make any aircraft sim as complicated as you want, there are definitely some systems like Brake-to-Vacate and Runway Overrun Warning/Protection (not mention ECAM, especially the blue book ECAMs used in the A350 and A380) that are just objectively more complex than what would be required features in an equivalent level simulation of a 737. I believe the manual for the ECAM memos in the A350 alone is about 1/2 the length of the entire operating manual of the 737.

Why are we comparing a 737 to an a350…?

I've said this more than once here. I'm not against early access or beta releases, as long as the developer clearly states the status of the software at launch and, of course, sets a price that reflects that, DCS model for example.

But unfortunately, certain developers are still determined to release early access products without warning and at full price, and this isn't just a one-time occurrence, every release is the same.

I'm sorry, but I can't defend this kind of development model, which is so opaque and unethical toward consumer, especially when there's no right to a refund.

6 hours ago, BrianW said:

I respectively disagree. take the packs for example, on a 737 they need to be turned off for engine start. If you don't turn them back on after start you won't have any pressurization or ECS. In the A220 it's "automatic" but really that means the whole system can be ignored. Try turning off the packs in the Synaptic A220 in flight and you'll see they skipped this whole system. Hopefully it will be fixed because I do like the aircraft, but there is a lot of detail missing still compared to the FCOM.

Just to understand - you turn off the packs in the Synaptic A220 in-flight and nothing happens? The ECAM still shows the packs running?

I love this aircraft. But have some issues I've come accross.

The inserted data on the FUEL page is left blank. Only taxi fuel and pax number is displayed. But getting back to that page later, the fields are filled up.

Periodically get warning on the monitor screen : "Aircraft system mulfunction. Flaps mulfunction". But the flaps seem to work fine. In my VA get penalties always for not using flaps...

Each flight have to log on to Navigraph... Sometimes even during the flight must to login on again.

And position of the copilot bugs me. Needs to be put down a bit.

The rest is good. FPS are good. Motivating airplane :) Glad to fly it.

Edited August 4Aug 4 by zorro747

8 minutes ago, zorro747 said:

The inserted data on the FUEL page is left blank. Only taxi fuel and pax number is displayed. But getting back to that page later, the fields are filled up.

You should submit a ticket with this. IF it's a bug, they will know and they will fix it.

16 hours ago, UrgentSiesta said:

I seriously doubt the complexities between peer- level Airbus and Boeing are that much different, particularly when it comes to reproducing them for flight sim.

I am not an expert. However, there are whole modern systems on an A350 that simply do not exist, period, on an B737NG. Brake to vacate is one of those, as an example. Now in the sim, the developer could just not include that system, but if they try to get close to the real world counterpart, they would model it and the underlying logic. That takes more development effort and time. That is all I was getting at.

Can anyone who owns the A220 confirm if popped out displays are interactable with the mouse or not?