FNX_Dave

Can you try rolling back to v1986 via the red dot in the installer next to the previous version? I'd be interested to know if that clears your sound stutters. To add, this is the first report I've seen of sound stutters related to either BFU or Patch 1, but will monitor for sure.

This is expected in 2024. Right now, the value you need for lights to be visible during the day is say, "150,000" but at night that same visual brightness is only a value of "50". This is a pain because it means we either pick the right value for day and have the lights blow the monitor apart at the seams during the night, or set for night time, and accept during the day things will be barely, if it all, visible. We did try setting to the day value, and then attenuating them based on ambient brightness data the sim sends, which works (crudely), however we can't set the values with the granularity required: even 1% of 150,000 is 1500, not 50. Microsoft have said they're aware and will be trying to implement something to make this easier to work with going forward, I'm not sure what timeline.

I'm tracking some issues with the CFM soundset, will try to get some fixes into the first patch!

Actually they should be entirely different in brightness from the main display as one is a back-lit LCD, the other is front-lit 7-segment with a much dimmer light (I've spent hours photographing both in real A32X aircraft during bright sunshine, cloudy days, and the darkness of night with calibrated exposures and colour charts). The two are very different technologies and to 'sync' them in brightness with eachother would be a step back in the simulation. With this said, BFU will bring some improved simulation to the visuals for back-lit and front-lit displays, with the latter being more physically accurate than what MSFS has previously allowed devs to simulate.

Hi Perry - Feel free to raise a ticket with us on the matter with repro steps, including any reference material for the expected behaviour and we'll take a look! https://fenixsim.com/support/ Do keep in mind we don't always catch these sorts of threads, so best place to contact us or make us aware of something is via the form linked above. Thanks!

This is not the expected behaviour, and I've not come across any reports of this myself yet. The installer update should be relatively unnoticed bar a 2-5 seconds "Installer updating to VX.X.." loading bar that will appear before launching. All settings should be saved, and during the main product update we even carry over your cameras.cfg if you have custom views. Please do drop us a support ticket and we'll do our best to assist!

I really couldn't speak on their behalf or comment on their code. I will say, they've been in this game a long time and have been through many new simulator releases that required porting their code - I'd imagine their code is very well written to be as resilient as possible to these sorts of changes and highly refined at this point to avoid any 'gotchas' by being too reliant on one specific SDK.

Whilst the external application helps with debugging, and for sure we'd be in a similar boat without the WASM debug tools if we were internal, I'd like to correct one thing: we do follow the SDK. Microsoft built something specifically for our usecase many years ago called SimConnect, it's the same API that GSX, Navigraph, PMDG and many other add-ons use - and is part of the SDK, along with the exe.xml functionality that goes with it. To be on XBOX/Marketplace isn't just following the SDK, it's following the SDK but only using specific parts of it. The ony difference between how we use it and how PMDG use it is both the core language of our code (C# vs C++) and that we run our code externally. Unfortunately the path from C# to WASM is... start again, whereas C++ is much more straight-forward; one of our developers actually converted a full C++ aircraft codebase to WASM in about a week for an external contract, if that gives you an idea of the difference. With regards to FS2024, by far the biggest change we've seen is not the code execution, but the approach to artwork. If you want to export an aircraft's visual model natively via the FS2024 SDK like we've done, it's a huge undertaking. The LOD handling is different, the emissives are different, the lights are different, the way materials are handled is different. There's also a whole new texture format to contend with (.ktx2) which will obviously mean existing exported liveries in .dds format from 2020 will need a re-export. We've managed to work through and around a ton of these issues and it wasn't at all straight-forward, so I really wouldn't hold it against any developer struggling here. I hope that provides an insight to what us devs are staring down the barrel of when it comes to FS2020 -> FS2024.

Hey - I can confirm that the wiper effect in the Fenix A32X for MSFS 2024 is simply the one described in the SDK. No work arounds here, we simply followed the SDK page on wipers, it took us about 15-20 minutes to implement across all 3 aircraft variants. It simply seems that none of the default aircraft use this feature except the AS350.

Hey - just wanted to clarify a couple bits here as I've also been slightly misquoted, so figured I'd keep things purely factual. Firstly, for our intents and purposes we own the code running Fenix, and all works (fixes, improvements, additional features) are undertaken by Fenix in-house programmers, forked off from ProSim's codebase almost half a decade ago. Those same programmers have scratch-written large swaths of the originally licensed code to better suite our specific needs and goals, including our external engine model and custom FM, custom implementation of Airbus FBW, and specific system differences to support the A319/A321/SLs. These are all things the original codebase had no support for as the ProSim A320 suite is designed around a very different use-case, so five years in it's fair to say the code is more Fenix than ProSim. As for the licensing - I'm not going to go into detail, but we're not limited to any platform or variations upon our existing products - as before, for all intents and purposes, we're no more restricted than anyone else with what we do with our products and associated source code. Now, with regards to the quote from me about Fenix being an unsustainable business - this is the danger of taking a snippet from a conversation rather than contextualising it, so allow me to do just that: Making a one time payment of £49.99 for an airliner add-on with a fully-fledged failures system, circuit breakers etc. and expecting that initial purchase to sustain continuous improvements, periodic full-rebuilds (see V2), and platform upgrades for 5-10 years, without producing and releasing another product, is precisely what is not sustainable. Given we still plan for FS2024 compatibility to be free to all customers, it's fair to say we're doing well enough for now. 🙂 Anyway, I very much look forward to seeing the FSL A321 - competition is good for everyone, and the market is certainly large enough to sustain it. I'm sure both our product, and theirs, will be better for their mutual existence.

I appreciate the sentiment (and boy do I share in the frustation) but it's worth noting that we don't believe we were ever entitled to or owed access to the DevAlpha - it'd have been lovely, but I totally understand and respect their reasonings for making it Marketplace-dev only. We're very open to the idea of the Marketplace, and if it was technically feasible under the current requirements you'd see us there too. We don't have any ill-will towards Microsoft or Asobo on this, our messaging is simply to share that we've done our best to get up to speed with the new platform, and are very willing to work with it, but that it's out of our hands for now. What we gain in some ways (flexibility of the external process) we lose in others (early access), and we're under no illusion that we're owed anything just because a tiny fraction of a percentage of their customerbase have a little pretend pink and orange airplane on their computer called Fenix. Give it a couple weeks and we'll have no excuse but to get to work! 😄

Very interesting, the shot through the cockpit windows from 3dsMax shows they're accurately representing N747NA (an airframe I'm quite familiar with, which has many 'one off' modifications to the panels and surrounds). So this looks like a 747SP of sorts! Exciting!

Exactly. We can't detect that so have no ability to change it.

Indeed, it isn't technically possible to read the ambient light value in any given location, but in our case we simply guess based on ToD/season etc. It's crude, but works most of the time. My bad, we're still on a 'half and half' system at the moment, so changelogs do not propigate automatically - I've now updated it in the app.

We fixed all the instances we could repeat - if you have a way to replicate this reliably please do submit a ticket with steps along with a video if possible and we'll see what we can do. The difficulty with this one was we found there were a few different causes, so we were only able to fix what we could find and repeat.