Aamir

What is still unclear is what “always 3D” actually means in the current WXR implementation. The published API documents the display controls, but I have not seen any public documentation defining the underlying sampling model: whether the radar is sampling a true volumetric beam, a slice through a volume, or some other projection. The documented cone angle appears to be display coverage; I have not seen any documentation describing beam width or sampling geometry. There is also a more basic limitation. DevSupport (https://devsupport.flightsimulator.com/t/allow-reading-environment-simvars-from-non-aircraft-simobjects/4976) previously stated that accurate weather information can only be returned at the ownship position, plus a small radius around the aircraft when needed, and that this is why there is no general Weather API for arbitrary world positions. That creates a direct problem for WXR developers trying to reason about forward sampling, cell structure, or any radar-derived hazard logic. The current official API also appears to be display-oriented, not data-oriented. Publicly, it gives a rendered MapView texture and display controls, but no official way to query cells or extract structured weather/radar information from the return. That matters because placing symbology at a given position requires access to the underlying radar/weather data at that position; merely displaying the rendered MapView texture does not provide that. The useful SDK clarification would be: - whether the WXR return is a true volumetric beam or a slice/projection - whether any beam width / beam broadening with range is modeled - whether attenuation, occlusion, or shadowing are modeled - whether structured weather/radar data is planned beyond the bitmap output - whether any structured Doppler / cell-motion data is planned for turbulence and predictive windshear logic Goes without saying we all massively appreciate the work being done, and look forward to further improvements!

Reach out to support - ideally with a video of what you're experiencing, they will be able to offer 1:1 help

Sounds to me like the startup flow for the FCU/FMGS etc, these units are "waking up" and initializing. Can be seen on a cold and dark startup too, once you sort some power to the aircraft!

Huh, that is a new one. Well, every day is a learning day - but could you do me a favor and just ping support with what you've found and where you're at on this? It's quite an odd one to me, I will go double check my own bindings in 2024 a little later today as I am also running a combination rudder/tiller on my foot pedals. No worries re Discord, happy to leave things here so people can find it in the future, but one thing of note is that our Discord is for "verified" customers only - it's an automatic process, you can read about it here, should just take a minute: https://support.fenixsim.com/hc/en-us/articles/12458469647119-How-to-Join-the-Fenix-Sim-Discord

no problem, thanks for being willing to work on it with us - just hit up support when you have what you need and they'll take it from there, good luck!

To start with, if you've got a set of rudder pedals - make sure ONLY the rudder is bound to them in MSFS. If you've got a set of rudder pedals and a tiller - make sure both are bound to their requisite functions. Unchecked bindings can cause this kind of havoc. At baseline, if you've got a simple rudder axis bound in MSFS correctly, you load in to the runway (without anything else in your community folder) - no FSUIPC/FSR/Chaseplane all that sort of stuff - and you you move your rudder left to right after load in and initialization is complete, and nothing happens, get in touch with support as something is not right on your system and needs a bit of 1:1 investigation.

This is not how it works IRL - that is just how it works on that product. This is correct

You don't. Just set a rudder axis per normal in MSFS and click the rudder pull tab when you want to use nosewheel steering. You don't need to deactivate it either when lining up, it will automatically do so when you apply takeoff thrust.

Depends on a lot of things - the fuel burn computed in the trip field should be close enough within around 200-300kg provided the winds are uplinked, the runways on both DEP and ARR are selected, and the procedures on either end are selected. This also means that if Simbrief has/includes step climbs, step descents, etc - that they too are programmed and inserted into the FMS to reflect. Then finally, double check the Simbrief wind uplink to ensure the winds are reflective of the reality you find yourself in - i.e the data is good - sometimes it deviates! All in though, the next update should also provide some enhancements to the accuracy in this area.

Right, hence why I said I found your comment disingenuous. You're moving the goalposts a bit from what you said initially below, to what you're saying above, now. There's a difference between "it should displace more", and below - where you're quite firmly claiming nothing happens. While I am happy to say I can review the amount of effect, there's little I can do with feedback that falls into a fallacy of composition - "it doesn't move enough, so it doesn't move at all". Much more so when posted as a matter of fact. I feel the need to point this out as people do read what is said, and people within this community do have influence on, and within, prevailing opinion - a longstanding and well respected community member such as yourself, more so. Even scarier, most do not check for themselves, but will repeat it allowing such to propagate as fact. Have been on the receiving end of such, multiple times. fwiw, I also quickly tried a failure at 5000ft, 250knts, and a lightweight airplane so neither engine was producing a lot of thrust, in other words the most sympathetic situation to support your initial claim - it still deviated laterally, offset by a few degrees. If you feel it needs more beta target deviation, that's fine, but beta target and the actual aerodynamic yaw deviation are two relatively separate concepts. Yes, they mingle, but they are not one another, and there is a long, long list of factors that influence beta target that could cause it to deviate less than you feel appropriate - but again, equating that with physical yaw deviation due to thrust asymmetry and leaving it at that is very much an unfinished picture.

Hm, I find this statement sliiiiiiiiiightly disingenuous. Did a takeoff cut, not a V1 cut, so you can see the asymmetry. Not sure why you don't need any rudder at all, but at least on my end - you need to respond to align your beta target. I think the amount of rudder trim needed is slightly less than reality, but more a problem with the trim units and the power of the rudder which I will review later. Asymmetry is alive and well 🙂 Sorry for the short video, using a debug build which tends to have many oddities going on with it, so usual caveats apply et al.

You're not supposed to use it for timing anything. It's a procedural reminder, it has absolutely no idea what's going on besides playing in concert with it's relatively rigid logic. The FWC places these callouts into a buffer sometimes when they are activated rapidly in sequence, e.g retard callout - and it is not smart enough to "cancel" it like the newer aircraft when no longer required. The A320's logic and processes are from the 80s after all 🙂

That's... not how VAT works - we absorb the cost of VAT for EU customers. The US charges sales tax per state, each state charges their own. We pay these too, again, we simply absorb it. Globally, Australia and NZ have their own schemes, as does pretty much every country on earth really. We absorb these costs across the board. We are not charging VAT. We are paying it.

This picture caught my eye a bit - I'm not entire sure when your ECAM alert for LO LVL triggered, but the sensors and fuel are simulated in a more physical sense that you may expect i.e you're banking and pitching, 30 degrees of bank and 10 degrees of pitch - the fuel is sloshing around in the tank as a result and the sensor feeding this information to the flight warning computer (and therefore triggering it) can flag as dry with sustained bank/pitch earlier than it should, although it does look a tad on the low side anyway 😄

Better to have and not need than need and not have 😁

There are CBs that are required for MELs, failures, and troubleshooting - e.g if a system fails, you can pull the CB for it to reset power to it, observe it go through it's startup process, and depending on how long you power cycled it for, observe the effects of it fully resetting or not. That stuff is simulated, so if you fly with random failures turned on, there's a chance you may need to use the CBs to try and recycle power to broken things sometimes.

Unfortunately we have never rewritten VNAV, we have rebuilt various sub-functions, algos, bits of math, bits of performance data, all sorts - but structurally and fundamentally it's been the inherited code from ProSim dictating the degree of flexibility we had. Yes, we have put quite some work into it as is - but the thing with keeping the wheels on the bicycle is that we can't address all things at once, so sometimes we must choose to do smaller work to make a smaller iterative improvement (like we have the last 3 years on VNAV) to keep things ticking along, maintained and improved, but not fully overhauled - until we have the resources or time necessary to do the overhaul. When we do start overhauling though, not only can we design from the ground up - but we can carry the learnings and "do not dos" from the old code and extensively working with it. Lots of overhaulin' going around and resources are limited ultimately, ECAM etc is also a very big job, very long in the making - we perpetually have more to do than time, but we're trying to balance as much as possible! We actually hired a full-time programmer to the team over a year ago specifically to work on an all-new VNAV that isn't rushed, or "good enough", instead building it to a specification that is closer to aerospace than home software. We could have probably done something in half the time that was a decent upgrade on the current VNAV, but that's not our M.O. Take the time, do it right. Which we have been, and will continue to do despite many calls for us to rush out whatever we have in development now.

Hey - we're dialing in this new sound implementation so volume levels were sort of all over the place, we're knocking them back into shape now, but if you wish to try some fixes, a branch is available. Simply click the little icon on your installer, right next to Fenix A320 Base Pack that looks like a little fork almost. Enter: bfu-sound-fixes-2, and then click OK and update your install.

Maybe I'm not understanding correctly - but it seems to me like instead of modifying your controls, you're modifying your actual flight model to adjust the control sensitivities - which seems like a really broken approach. This is a fly by wire airplane and it has external augmentations to the flight dynamics. Adjusting the _elevator and aileron_ effectiveness means ALL the fly by wire work is pretty useless, the layer underneath in direct law is also receiving and procesing inputs at a completely different magnitude than it expects, so on and so forth. It's ok to enjoy tinkering - but I heartily recommend you not suggest to users that this is the way forward - I can tell you for a fact we have had our support inbox rammed full of people that have "odd problems" and after 3 or 4 days of troubleshooting do we discover they've modified something in their FM files and it's broken some behaviour somewhere. As a result of chasing our own tails several times with users that edit stuff, part of the new systems in BFU is an FM validation pass for the FBW and associated systems, if the aircraft senses a difference between what the FBW expects and FM is providing, the validation will fail and the aircraft will revert to direct law as a result. If you want to modify the Flight Model that's fine, but the FBW, associated systems, and externally augmented flight modelling are now so intrinsically linked with how the aircraft behaves in every stage of flight (including ground roll) it can pretty badly break the whole thing, so this validation step is a 'sanity' check before it tries to make assumptions about what the aircraft is doing. Long story short: by all means have a play, but it'll behave like a dog being given medicine and throw itself into direct law if it doesn't exactly match the expectation. This will pretty much help your stability so you can edit away and enjoy - but it also does mean you have no access to the fly by wire subsequently. We cannot build a fly by wire which will just accept whatever input unfortunately. These are fairly closely tuned systems. Anyway, instead of that - just adjust your curves in the controls. If anything, that is a MUCH better approach because it works with the sidestick control work we've done, AND lets you weight up the controls as you desire. Like we said, start at linear and work from there.

It is an interesting and infinite topic, really. I will share from my context about our work, but I am obviously a biased entity, so please take that into account with what I say and consider it on that basis - hence why I will also not draw any direct comparisons amongst the other products you mention. I will be clear to say also that I'm not entirely familiar with how those products handle, I used FSL back in the P3D heydays, years ago and remember a fairly minimal amount. These days I keep my window of reference outside of any other products to remove any bias - ultimately our goal is to build an Airbus A320 - the ground source truth for us lies in the real aircraft and actual data in that sense, but there is more to just the data, of course. To start with, the math on these aircraft is actually both reasonably well defined, and fairly easily available to view. Yes, the actual inherent specifics are not - but as a generalisation, looking into various research papers you can find on google, you'll find the authors of Airbus' fly by wire systems, and other researchers, describing down to the math how these things function. With that in mind, as far as the roll axis goes, imo, in the real world a roll axis that continues rolling after the sidestick is neutralized to the point that you can actually perceive it is not ideal at all. This is imprecise - in this case the airplane isn't going where you ask it, it's going near where you asked it and continuing to roll after you've asked it to stop. This imprecision is not something I can say I have noticed in the data when directly comparing roll rate to sidestick deflection - the airplane's commanded roll and the sidestick is actually quite remarkably overlapped - yes there are certainly damping factors, but it still overlaps tightly. This makes sense to me given the entire loop, that is, input to output - and it makes sense to me BECAUSE of the input. Look at it closely and study it a bit and you sort of begin to understand where the problem is - the absolute most fundamental part of the entire control loop _is_ the control input, to me at least, and in light of that the sidestick on the A320 is really quite impressively mechanically engineered. https://youtu.be/rHzl34Kjj9o?t=123 < check that out - it's a real sidestick - and note how it recenters. Gives you a gist of the damping on this thing. There are also some interesting tidbits that will lend you an idea of quite how thought through the design of the sidestick damping mechanicals actually are - for example, even roll is asymmetric on a hardware level, forget about pitch vs. roll - the roll tension springs for inboard deflection vs. outboard deflection are different because your arm is naturally stronger in one direction vs. the other, so the resistance is slightly stronger in one direction. So, there is your weight and inertia that pilots are talking about - it's not in the fly by wire - it's here. That smooth return to center, the weight off center, all that good stuff. The fly by wire is just doing as it's told. Now, how each maker chooses to transpose this to desktop joysticks is a different story. I have my reservations about imprecision when attempting to build this into the fly by wire layer as mentioned above - I find it critical to be precise in the application of flight controls. Our approach is charted out in a section that ultimately was cut from the main BFU video, but if you're still interested in this topic after reading my rambling - take a look at this, it's the unlisted cut section - it describes our approach to this: https://www.youtube.com/watch?v=LkgpqFZL5Bc

It's probably important to recognise that generic troubleshooting steps are pretty standard in all customer support as we simply cannot know what/where/when/why epople are giving feedback in a high volume environment. Not sure what all the state of the art simulation commentary is about, or how it's really relevant to your joystick settings, but feel free to share the exchange and I can give some feedback to support.

Fairly uncommon, but hey, it's an option so it's in there!

Ah! This would be FLS - in Fenix, you can have either FLS or FINAL APP selected, this is because the FMS software we emulate at the time was a little more rudimentary than the latest standards, and so these two modes could no co-exist, airlines were forced to choose. On later aircraft, they allow the coexistance of both FLS and FINAL APP - which means you can choose in the MCDU. So, to fly an RNAV like you're used to, just make sure you've not got the FLS option selected in the EFB settings page! For more details on FLS and FINAL APP, see here, great article: https://safetyfirst.airbus.com/safely-flying-non-precision-instrument-approaches/

I would try unticking display sync in this case, but the logs are available by opening your Fenix App (not the installer, the one with the display options) - and clicking on the logs button on the right hand side pane.

https://support.fenixsim.com/hc/en-us/articles/13358535673103-Displays-lagging-stuttering Could you try this for me and let me know if it alleviates your issue?