All Activity

Should be an option if implemented. Even on modern aircraft like the Airbus most US operators display all temperatures in Celsius except the cabin temp which is usually shown in Fahrenheit.

I think that regardless of whether you import the waypoints including SIDs/STARs or without that, when you import waypoints into the INS from the PFB, that the last waypoint loaded should always be the destination airport and not the final waypoint in the flight plan. Once you hit that waypoint there is still valuable information to be gained from the distance and time to the destination that are displayed, and I am quite certain that all crews of L1011s fitted with INSes would have done the same. You can do it yourself manually, of course, but then that defeats the purpose of using the autoimport.

Everything is working fine with GSX until it comes time to push. When the operator asks to release break the plane run into the terminal. I usually pump the parking break until it stops. When it happens in the beginning of the push it's certain it will happend at the end, when I pause the sim and restart coault. At GSX they say it's from IniBuild side!

SimBrief fuel imports still seem to be resulting in a displayed 400 lb imbalance. See attached screenshots. The SimBrief OFP has a total fuel amount of 120.0k lbs which is shown in the PFD. However, once loaded, the fuel totalizer only shows 119.6k lbs, and when I add up the fuel shown on the individual tank gauges, I only see a little over 116k lbs of fuel on board.

See attached screenshot. This was after running unattended at cruise for nearly 4 hours with all crossfeeds open and all pumps on. I am not using the PFD fuel balance helper (which also appears to not be working correctly, but that's a topic for a different post). In my screenshot I've turned all pumps off but the tank 3 and 2R pumps to even out first the small imbalance in 2R and then I will try to burn tank 3 down.

I'll bring this up to the team if there is any update

Hi, the landing telemetry simply takes the vertical speed sim variable at the moment of touchdown - IAS, TAS, and G/S have no impact on the recorded vertical speed. Secondly, it should be expected that you will have a higher landing rate at high density altitudes. Because you are moving faster over the ground, you will also need to descend at a higher V/S in order to maintain the same geometric descent. Best, Steven

I'll look into this as well as pass it along to the team, thanks.

Feedback regarding the Brakes and Heating Behavior has been passed along to the team.

Out of curiosity, we're exploring some possible culprits - but the next time you load your sim could you check your console and search "it will use" and send us the screenshot of any console entries? Like this? Also can you specify if you frequently get crashes/freezes or not?

cheers!

Hi, we'll take a look into this, I'm gonna pre-emptively assume (and I might be wrong so don't quote me just yet) but regarding the autosave I think it only saves anything that has an associate LVAR with it as well as the flightplan data. BTV and Checklist are digital items and the sunvisors just might not be included. I'll ask about this too. Thank you.

I’ve noticed since the everlasting bugs and crashes, the autosave system in the 350s have been extremely useful. However, the majority of the time i need them, I’ve found they save the most necessary bits - time, place, area, avionics etc - but don’t save some other stuff that are just nice not to have to go through and update, those being BTV distance, checklists, sun visor positions, among some random other stuff that’s less important, I think, as I can’t remember them. Additionally, I (may) have found a bug and not sure if it’s actually present in the real aircraft or not: During a flight, the time displayed across multiple screens isn’t always correct (at least not to local time. The UTC time (with seconds, found in the F-PLN section, then the fix info drop-down -> time) is right, but the time displayed across other areas of the ac is out of sync, so I’m not sure if that’s a bug, caused by stopping/starting the sim manually, or something else. Many thanks

Three of my last four flights into KLAX ended with a crash to desktop using MSFS 2024 and KLAX v1.0.2. Everything seems to be going fine then there are three sound cutouts and then the sim crashes. No messages or warnings or anything like that.

To Reproduce: Video (unlisted) is time stamped with moment. WASM crash occurred when inserting the approach data for runway, then STAR, when pressing "Insert" to flightplan: https://www.youtube.com/live/MpOLidphPJA?si=cUIdGiFJrb0lKD2Z&t=5340 Aircraft - A300-600R Premium (Passenger) Simulator: MSFS 2024 1.7.27.0 (latest SU5) Version: 1.1.9 MSFS2024 Marketplace (Installed not Streamed) Navdata: Navigraph Route - EDDF/25C N0446F350 ANEK3F ANEKI Y163 HERBI Y164 MOPAN DCT LUTIX DCT BENOT DCT NEMOS DCT NINTU DCT MEBAK DCT REPSI DCT LERGA DCT MINSO DCT NARAK DCT AGN DCT PIPOR L866 PPN/N0442F370 N976 NEA L14 ADINO DCT ELVAR DCT ALAGU DCT USALU USAL9C LPFR/10 EDDFLPFR_PDF_1779642878.9e825734.pdf Livery - Lufthansa (retro) D-AIAN WASM Error: Unable to retrieve. When I returned to the simulator to retrieve it, it looks like it was already purged. Specs: AMD Ryzen 7 9800X3D / RTX5080 / 64GB Autosave File: Not available for this aircraft.

As I said, it's been noted and passed along...

AGAIN, didn't ask if I need to hear it or not, Airbus or not, I asked why we don't hear them so to make them heard, VOR/ADF/ILS/MARKER.. Those are fitted in the aircrafts, they're there for a reason, please make them work.. If iniBuilds don't want make the audio monitoring work in their fleet, just say so and don't make excuses.

You do not need to listen to the tones as an airbus pilot wether automatically or manually tuned, to be clear. Even in a Cessna with a modern GPS the navaids are automatically identified and pilots do not legally need to listen to the tones when this occurs. I have noted that the tones are not audible through the radio so I will pass that along.

Hello @iniBuilds , I am amazed on what work you have done with the A340, alongside with the updates you push out to improve the A340, such a phenomenal aircraft! I am currently flying this on Xbox and would highly request to add in the Terrain Radar for both EIS1 and EIS2 displays. Also you should also considering to implement the terrain radar to other aircraft, such as the Inibulids A330, A320neo, A321LR, and A350. Just like in the old MSFS2020 days the terrain radar used to work on the Inibuilds A320neo and would be very useful for all your great Airbus aircraft you guys developed. Please reach me out back if you any further updates regarding if you guys are able to push an update for this for all your Airbus aircraft and also the A340. Thank you.

I have already reported this issue to support. Appeared after 1.2.6 update.

I get this message too when taxiing after landing

Dear iniBuilds Development Team, I am writing to report a recurring telemetry calculation issue in the A350 flight report system, specifically when operating at high-altitude airports (e.g., SEQM, elevation ~7,900ft). The Discrepancy: Upon touchdown, the aircraft’s landing performance was physically smooth, with the Radio Altimeter (RA) providing precise and steady closure rates (the 5-4-3-2-1 callouts were perfectly paced, confirming a stable and gentle flare). However, the generated in-built landing report recorded an inflated Sink Rate (-263.60 ft/min) and G-force (1.13G), which contradicts both the smooth tactile feedback and the reliable RA data. Root Cause Analysis: After reviewing the logs, I have identified the probable logic error in your touchdown telemetry script: Velocity Input Confusion: The report recorded a touchdown speed of 142.27 KTS, which is equivalent to the Indicated Airspeed (IAS) at this altitude, rather than the actual Ground Speed (GS) / True Airspeed (TAS) of 166 KTS. Mathematical Amplification: It appears your vertical acceleration/velocity calculation formula uses horizontal speed as a vector component (or denominator). By using the incorrect IAS instead of GS, the formula essentially "compressed" the denominator, leading to an artificial inflation of the Vertical Speed and G-force results. Cross-system Dependency: The internal sound engine and HUD/PFD display mapping seem to be triggered by this corrupted VS value, resulting in an unnaturally "hard" landing sound and visual data that does not reflect the actual physical state of the aircraft. Recommendation: Please ensure the WASM module’s landing telemetry logic is updated to utilize Ground Speed (GS) or True Airspeed (TAS) for all kinematic calculations, instead of relying on uncorrected IAS, especially for high-altitude operations. Thank you for your hard work on this aircraft. I hope this technical breakdown helps in optimizing the flight report system. Best regards,

Yeah, that’s what I do too, but it’s nicer to use the physical keyboard like we can do with the MFD… Especially when the EFB itself says there shouldn’t normally be any conflict...

hi again found the problem ! it s a small scenery near KLAX thats causing interference. have nice flights

Yeah have noticed this. I just use the onscreen keyboard on the OIS that you can pop up to avoid any conflicts.