Der Michel

FCOM: The constraint value and the constraint symbol have identical color coding. If the circle is amber, the value should also be amber

Fehlerhafter Anwendungsname: FlightSimulator2024.exe, Version: 1.4.20.0, Zeitstempel: 0x00000000 Fehlerhafter Modulname: FlightSimulator2024.exe, Version: 1.4.20.0, Zeitstempel: 0x00000000 Ausnahmecode: 0xc0000005 Fehleroffset: 0x0000000003892905 Fehlerhafte Prozess-ID: 0x42CC Fehlerhafte Anwendungsstartzeit: 0x1DBDDC771F74C28 Fehlerhafter Anwendungspfad: C:\Program Files\WindowsApps\Microsoft.Limitless_1.4.20.0_x64__8wekyb3d8bbwe\FlightSimulator2024.exe Fehlerhafter Modulpfad: C:\Program Files\WindowsApps\Microsoft.Limitless_1.4.20.0_x64__8wekyb3d8bbwe\FlightSimulator2024.exe Berichts-ID: 0688ec88-ff4c-4562-b778-3ec8d3e79ae4 Vollständiger Name des fehlerhaften Pakets: Microsoft.Limitless_1.4.20.0_x64__8wekyb3d8bbwe Fehlerhafte paketbezogene Anwendungs-ID: App

PSEUDOWAYPOINTS missing for: - descent (SPDLIM) at FL100 - FLAP 1, FLAP 2 for the CDA function Appr: ILS 09L at EDDV

Yep....I had yesterday endless FALRE, but no autoland....

With TCAS in STANDBY and TRAF pressed at EFIS CP, the TCAS ARC has not to be drawn, but instead a dashed circle. The GS has to be right alligend, not left. See top left corner

Might be yes, but believe me, system devs can forget, miss or just shortcut a lot. And they did it correct for the red version:

Following is wrong for the VD. a.) the vertical line at the end of the scale has to be solid, not dashed. Dashed it's only, when ND has ARC greater 160 or ROSE greater 320. b.) vertical MORA line has to be horizontal aligned with 0 range line c) if the constrained is missed, the constrain symbol has to be amber with an dotted line: d) if alt constraint is ignored, it has to be white in the VD: 1. empty FMS: VIEW ALONG ACFT TRK is missing Aircraft should be at the bottom of the VD no green arrow would be correct, as no f-pln avail currently MORA is missing if SIM DEFAULT is used, but NAVIGRAPH is linked RADIO HEIGHT indication is missing 2. citypair/route entered FMS: MAGENTA AREA missing...distance to airport reference coordinate GREY AREA for the remaining VD RADIO HEIGHT indication is missing Aircraft should be at the bottom of the VD 3. runway and SID entered FMS, but no perf data avail: MAGENTA AREA missing...distance to RWY TRESHOLD coordinate GREY AREA for the remaining VD RUNWAY missing RADIO HEIGHT indication is missing Aircraft should be at the bottom of the VD green arrow should still be indicated, because no predictions are avail 4. runway and SID entered FMS, but perf data now avail: MAGENTA AREA missing...distance to RWY TRESHOLD coordinate GREY AREA for the remaining VD RUNWAY missing RADIO HEIGHT indication is missing green arrow should still be indicated, because aircraft does not follow the FMS trajectory or the selected trajectory vertical profile has to start at the calculated takeoff point In selected mode the VD is not showing the Vertical Cut along the TRACK and should show the selected vertical track not the arrow.

Let's look again at the CA-Leg type in conjunction with VD-ND-FPLN. - at the ND the 600 wpt is behind the runway - at VD it's in the middle of the runway And again the CA WPT is still indicated as a regular lateral fixed WPT with constraint. THAT'S WRONG !!!!!!!!!!!!!!! 1. A CA or VA or FA is only vertical fixed. Lateral it is linked to the aircraft performance - VNAV. So depending on the climb performance the lateral position has to be adjusted!!!!!! 2. There shouldn't be any asterix next to it in the F-PLN. Because it's NO regular constraint !!!!! 3. The vertical profile can't start at the rwy treshold, calculate the required takeoff roll and the point of lift off !!!!!

I can check next time.

I didn’t had any WASM freez since a long time. Issues to be fixed I’m looking for: LNAV correct approach simulation for LDA and RNP correct ALTN f-pln correct display of leg-types in f-pln Correct wind uplink and a lot other other items I reported.

Latest newsletter: “With a large scale update on the schedule, we want to ensure that any bugs the community are still facing are being actively looked into and fixed for this update.“ Hi ini team, can we really expect a BIG Update that will fix all the mentioned bugs in the forum? That has to be a massive one. How long will that take, when can we expect it? I know, that questions are hard to answer. Looking forward…..I will take you by the word 😉

Hi, I still face CTD problems when I want to use Navigraph NavData. With sim default setting all is fine during longhaul. I haven’t further tested but I use in MSFS still the default LIDO data. I haven’t updated that one with Navigraph. Has anyone here some experience? Is Navigraph replacement required for default msfs data to be able to run Navigraph setting in A350? With Navigraph replacement, there shouldn’t be any requirement to set to Navigraph in OIS, because sim default is now also Navigraph?!?

That’s not the solution. I have the problem in MSFS2024. Your quote indicates that 2020 is problematic and 2024 fine. But to my understanding a GA is always part of the APPR. Coded is that just in a sequence of wpts (leg types according ARINC 424). So if the sims split that part…it’s part of SDK and no hidden item. And Navigraph as a source is still no option as the sim is still crashing with it enabled in A350.

Yep. Appr VNAV is totally bugged.

I also mentioned this in one of my posts. No idea what they mean with that Changelog entry. But if it is what we see here….

Yeah, airport/ground chart is not the same as the data required for the ANF.

Looks like corrupt file. Are you running the Marketplace version? Have you tried to reinstall it local? Not sure if SU2 does allow it. But SU3 (released to be soon) should allow to download local Addons from marketplace.

Microsoft has a contract with LH Systems for the LIDO Charts and NavData. Not for the Airportmaps. They are not included in MSFS2024.

Hi, if you have a sidewind component, rudder input (trim) is required to turn the aircraft slightly into the wind to keep your desired heading. This will result in different airflow above both wings and also some airpressure on the forward side of the vertical stabilzer. Both will result in some induced rollmoment. To compensate that rollmoment you need also input from your roll control surfaces. Spoilers 3-7 are also used for rollcontrol (not only the ailerons). Maybe that is what you see in your screenshot. A screenshot from the ECAM F/CTL page and ND in that situation would be great.

DXGI DEVICE HUNG is something we know well from P3D times. Graphic Driver related. In the past it was one possible solution to set the TDRLevel in the registry. Just google for DXGI DEVICE HUNG, bunch of results.

Hi, after the long weekend I want to sum up and clarify some points: In the first I was really frustrated when I opened the topic, because of my first flight experience after the latest fix. I'm very thankful to the dev team for their countless work to improve the plane. The number of fixes in each update proof that. But that number of fixes and we have now 12 of them and the current state is also one reason why I'm so frustrated. Sometimes it feels like 2 steps ahead and 1 back. Let's face the current VNAV for the approach, which seems to be broken. How can that be released? Basic approach types can't be flown, because of wrong and bugged implemented FLS. I stop now, because I don’t want to do a rant. As said, I'm thankful for the team @ iniBuilds. Keep up the work. I just hope that all the basic stuff gets fixed soon. I don't care for abnormal in first place, but all implemented systems should work as intended by Airbus in normal situations. I from my side I will try to post/report as much as I can. But with all the bugs I reported now, I don't have time to check every one, if it's fixed or not after another update. It would be really great, if we can get a "logged" tag and if the dev team can add a "version number" or "fixed" tag, if the report is fixed and positiv tested by the test team. Yeah, that would mean a second bugtracking system. Or just add the forum link to the fixed item in the changelog (I assume you have the link already in your bugtracking system). Thanks and kind regards

Maybe caused by the last fix? changelog 1.012: FIXED: Arrival Runway is now part of MISSED APPR + VSD ending too early [2024 only, 2020 in production] For this APPR the KEWR29 has to remain green!!!!! If the RWY is part of the APPR coding in NAVDATA it's always green. There are APPR, when the MAP is prior the Treshold and the RWY is not coded in the APPR navdata, then the RWY is not part of the F-PLN but also not part of the GA, because then the RWY is not indicated in F-PLN. The F-PLN is really easy...just indicate, what is in the NAVDATA coded. If the Runway is coded or not, is independent from the white runway at the ND.

The circles arround the WPT at ND should match the colors of the asterix at the FPLN. Are the constraints met or not?

I know for sure that LIDO has coded a constraint of +834 for COPKO in the NAVDATA. Jeppesen doesn't have that. I also know that the constraint is indicated at the ND in reality for this approach. KEWR29-Y RNAV (RNP) My setting is sim default. So why is the constraint missing?

BTV is indicating TOO SHORT without reason