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 😁