MariuszKr

Using the 'Ignore' option feels like a lazy work-around rather than a real fix. Your own official documentation explicitly warns against using this feature because it causes unpredictable behavior and breaks core functionality. Telling users to turn on a setting you yourselves advise avoiding — just so FSHud v2 doesn't crash with Fenix V3 — isn't a proper solution. Fenix is a major standard in MSFS, and expecting us to compromise software stability instead of updating FSHud to natively support V3 is disappointing for a paid product. I have also raised this issue with Fenix support to get their side on the V3 architecture changes, but as a paying user of FSHud, I expect a solution from your end as well. Are there actual plans for a native code update to properly handle Fenix V3, or is this 'Ignore' workaround intended to be the permanent solution? I think we've covered everything on this topic, I'll await your response, and then we can close the thread.

Here, look at what it says about the "Ignore" function, which has now apparently become your "cure-all"!! https://www.fshud.com/site/knowledge/traffic-settings-v2 I'm sure after this post of mine it'll disappear from the page. And maybe that's a good thing, because it's time for some changes and freshness in your addon! PS. Next time, which function will you tell me to uncheck and check instead in the FSHud v2 menu? Maybe I don't know much about the technical side — code and all that — but I don't like it when problems get swept under the rug, especially when it's your rug... :-)

It wasn't me who wrote about the "Ignore" function on the FSHud v2 page https://www.fshud.com/site/knowledge/traffic-settings-v2! So read for yourself what it says there. It's as if the developers themselves wrote that their addon makes no sense and contradicts itself... I think the topic is not subject to further discussion... Best regards to all fans of virtual aviation... If it works for you and everything is OK, I'm glad and I hope it keeps working OK. For me, the topic isn't over until the problems are fully resolved. I've been around long enough to know that MSFS in general is already a problem in itself + the addons on top of it...

That approach is completely missing the point. Today it's Fenix v3, tomorrow it'll be another complex aircraft using helper objects, and we’ll end up with the same broken system and the same advice to "just use a workaround". As paying customers, we shouldn't have to constantly adapt our setups or give up features just because your traffic handling fails when a modern airliner injects system-related objects. Expecting another developer to change their aircraft logic—or telling users to overhaul their traffic setup—instead of properly filtering AI objects on your end is simply frustrating. I don't have the energy to keep going in circles on this. I just expect the software I paid for to handle edge cases robustly like other tools do. .......

My configuration is strictly FSHud v2 + AIG models. I do not use any external injectors like FSLTL. Suggesting "Ignore" is useless—it turns my airports into 100% ghost towns, completely destroying the traffic separation and airport order I specifically paid for. This SimConnect bug is strictly between FSHud v2 and Fenix v3. Fix your internal injector code instead of telling paying customers to disable the core features of your product.

Hii ALL... So, as of today, is FSHud v2 basically useless? I bought it specifically for airport traffic, separation, and order, but with this SimConnect physics injection bug causing the Fenix A320 (v3) to constantly move backwards on the ground, the only suggested workaround is setting Traffic to "Ignore". If I have to disable the traffic management features just to stop my aircraft from rolling backwards, the entire purpose of buying this addon is gone. It's really frustrating that after major updates to MSFS and the Fenix, paying customers are left with an unmaintained software conflict. Is there any workaround that doesn't completely disable what I paid for?

I am asking simple questions about facts, not emotions. I am asking about what was promised versus what was actually delivered. This SP1 is clearly a final update for MSFS 2020, while MSFS 2024 users are left with an 'Experimental' tag. How much longer is this 'Experimental' state going to last? Suggesting that missing core features and an unfinished build are 'non-issues' is just pure denial. If pointing out documented limitations and missing systems like CPDLC causes 'issues' among members, then the problem lies with the product's transparency, not with the person asking legitimate questions. I’m here for engineering, not propaganda. It is easy to label serious software flaws as 'non-issues' when you look at them from the perspective of a Chromebook user who avoids the complexities of modern simulators altogether. However, for those of us who actually fly these advanced setups and paid full price for a product, these are real, broken systems that deserve answers, not administrative silencing. Anyway, I am done here. There is no point in repeating the same things over and over again when even the simplest, most direct questions are either too difficult to understand or simply too inconvenient for some of you. Safe flights.

Exactly this. Having been in this hobby for over 30 years, I’ve seen how standards have evolved, and we shouldn't be moving backward. We paid for an advanced study-level airliner, not a basic mod where you can just shrug off missing core systems. When key features are cut to meet a deadline, it’s a rushed release, period. Glad to see someone else in this community who actually cares about precision and holding developers accountable.

Cutting key features like CPDLC to meet a deadline is the exact definition of "rushed," whether it makes you chuckle or not. Trying to justify an incomplete SP1 by claiming "many simmers wouldn't use it anyway" is just a poor excuse for a broken release. We paid for a complete product, not a stripped-down compatibility patch. PS. Co tam u Kirka? 😎

A public forum is exactly the place to discuss the state of software, and facts don't care about your feelings. Pointing out documented bugs, a missing CPDLC, or a broken ACARS isn't "blasting hate"—it’s stating facts. If pointing out objective flaws that are literally listed in the official documentation hurts your feelings, maybe you shouldn't read public discussions. Have a great day too. PS. SP1 for MSFS 2024 not MSFS 2020! Kpw? Facio...

Good for you that you don't care about CPDLC and that the new EFB satisfies your needs. However, the fact that you don't use certain systems doesn't mean they shouldn't be fully implemented as promised. Personal satisfaction with basic features doesn't change the reality of what was cut from this update.

The point stands whether you semantics-check ACARS or not. My original post was about dropped promises like CPDLC and the fact that iFly literally labeled this MSFS 2024 build as 'Experimental'. If it was so 'polished' and took a 'looooong time', they wouldn't need to put an experimental warning on it. A couple of smooth flights on your end doesn't wipe out the cut features and official limitations.

Blaming a livery won't magically bring back missing features like CPDLC or fix documented bugs in this experimental build. Good for you that you are in 'GA mode' and don't care about missing airliner systems, but trying to gaslight others about a clearly rushed service pack is just pathetic.

An installation guide doesn't magically add missing features like CPDLC or fix officially documented experimental build issues. Glad you're happy with your 'fetures', but personal satisfaction doesn't change the reality of an incomplete service pack.

Installation settings won't magically code a missing CPDLC, fix a broken ACARS, or resolve known code inconsistencies in the experimental MSFS 2024 build. Good for you that it runs fine on your old 2080Ti, but white-knighting for a rushed SP1 and calling other community members 'cavemen' doesn't change the facts or the bugs mentioned in the documentation itself.