dectenor1

Yeah sadly. When there are many other aircraft out there that simply don't have these kind of issues, I can't quite bring myself to fly the A350 sadly. I really want to though as it is my favourite aircraft. I enjoy flying it for testing purposes after the updates in the hope that these kind of basic systems stuff will be fixed, just wish the testing the testers do was more rigorous so all these kind of errors wouldn't be in the aircraft in the first place. But you can't question the desire of iniBuilds to get to improve the aircraft, whether they will be able to, I don't know but it seems like they have the desire to. Hopefully these kind of fixes can be applied to their whole airbus range, they all suffer from similar errors and it would be lovely to fly the A330 for example if it wasn't also jam packed full of these kind of bugs.

CHECK DEST DATA message on MCDU should also disappear once the requisite fields are filled in, at the moment it stays and you have to remove the message manually. I normally just prefer to comment on systems things rather than sound, performance art etc. But just would like to also point out, that the performance seemed really bad for me on the latest v1.0.10. this was in MSFS 2024, -900, version with included cabin. At the same gate at ini EGLL, in the Fenix I get 100fps in the A350 60fps, quite a drop....

No problem. A few more things after the .10 hotfix Managed speed targets are flickering and bugging out again. I didn't notice this on v1.0.9. but it maybe I just got lucky on that flight and it was never fixed. This can be seen on the video below Loadsheet and loading are now a bit of a mess. When loading with GSX it does not load the correct number of PAX or ZFW, this was confirmed by auto-fillibg the entry boxes on FUEL & LOAD INIT PAGE and comparing with OFP. The LOAD CG button on LOADSHEET OIS page is also bugged now. I pressed it the first time and it gave erroneous results, the ZFWCG and CWCG were exactly the same, which shows something is wrong. I clicked it again, and the values changed to other values, but both were also the same, again showing something is bugged. Finally the third time, I got different values again, that looked like they might be correct, the two values were roughly what I would expect with also a little difference between them, which again is what I would expect. Many thanks for the work as always,

I have written up some of the bugs here in case you are interested in reading them. Best wishes

Here are a collection of bugs in v1.0.9 Some of them relate to vertical navigation and how aspects of this are displayed on the ND and MCDU pages. It is really disappointing to see so many of these after the long-awaited VNAV update. OIS Power buttons still do not work ADS-B TRAFFIC ON ECAM memo - I understand you guys are saying this is not incorrect, but both the FCOM and a real world A350 pilot disagree. It would be good to have more research on this and for the team to explain why they sit is incorrect when these two reliable sources say otherwise. Lower displays are brighter than the upper displays, rendering the DU MASTER BRT knob pointless The aircraft doesn't always tune the ILS, for example flying to EGPH with ILS 24 selected via the MCDU, no ILS frequency was tuned and I had to do it manually. Changing the altitude in the PRED TO box on CLB and DES PERF pages, does not result in any difference to displaying when the aircraft will reach, and the distance it will take to reach, the altitude typed in the box. Changing the target runway exit with BTV does not result in any change to the displayed runway occupancy and turnaround time. When you enter the FUEL values for TAXI, ALTN, FINAL RES etc., on the Fuel and LOAD INIT page, these are resetting if you then change the ZFW, FOB, CG etc. Once you have modified them, your modifications should stick. TO CONFIG TEST is not going green unless you do it after the CABIN READY has gone green. You should be able to do a TO CONFIG TEST and get an OK green result, irrespective of the status of the CABIN READY memo. The logic of the FCU MACH SPD window is incorrect. It should show MACH when the aircraft is targeting a MACH number, and SPD when targeting a speed. In the screenshot below you can clearly see the aircraft is targeting a speed (look at the CLB PERF page on PM MCDU, the aircraft should climb at 308kts IAS until this equals .84 and then climb at .84 . You can see on the ND the magenta bug is on 308 KTS so that is what the aircraft is targeting. At the moment, given the current altitude, this is equal to .786, therefore the aircraft is very much following a Speed), and therefore the FCU speed window should say SPD not MACH as it does here. Whilst on the subject of this window, the logic for going into Selected Speed from Managed Speed is still incorrect. When you open the speed window from Managed to Selected Speed, it should open at the current speed and not the Managed target speed. Whilst on the subject of managed target speed. The logic for displaying this is on the PERF page is incorrect. In the screenshot below, you can see on the ND that the aircraft is targeting 250 kts in managed descent. However, look at the DES PERF page on the PM MCDU, the this is showing that the aircraft is targeting .84 or 313 kts. Completely incorrect. The PERF page should show the correct target speeds. For avoidance of doubt, when the aircraft has just begun descent, on the DES PERF PAGE, under MACH the aircraft should display the ECON MACH Speed, and under SPD it should display the conversion speed at which the aircraft will change to targeting a Speed So at the stage of flight as shown in the shot above, it should say simply 250 under SPD, (because it is targeting 250 KTS due to a Speed Constraint, and not 0.84 313 KT. This is because as soon as you are targeting a speed constraint you are not targeting the econ profile of mach and then conversion to speed. So the mach disappears and it just shows the speed you are targeting under SPD. Hopefully that makes sense. This screenshot also demonstrates yet another bug related to management of the vertical profile. The aircraft is 0.1 NM from ESKDO and is at FL181. Yet the F-PLN page is predicting the aircraft will be at FL163 at ESKDO, I think not.... It also shows there is a bug in the relationship of the level-off symbol on the ND and the altitude predictions on the F-PLN page. The level-off arrow is indicating the aircraft will be at FL160 someway in the distance, yet the F-PLN page is saying we will be at FL163 (ignoring the 300ft difference) at ESKDO which the aircraft is basically already at (0.1NM away). Clearly this is a bug/error etc. Alarmingly it also demonstrates a further error. There is a SPD ERROR AT ESKDO message on the MCDU, but the SPD constraint at ESKDO on the F-PLN page has a magenta asterisk next to it. If there is a speed error there and the aircraft will not meet the constraint this should be orange not magenta. It is pretty bad that a single screenshot can demonstrate so many basic errors and bugs. The way the aircraft approaches AT Altitude constraints is also bugged. On this video at 1.00 you can see that as the aircraft approaches INREV, which has an altitude constraint of FL200, it pitches up and gets high on the profile and then has to dive to get back on profile after INREV. One can see further evidence of the poor F-PLN altitude predictions in this screenshot. The level-off symbol on the ND is showing reaching FL070 a long way after TARTN, and yet the F-PLN page is predicting the aircraft will be at TARTN at FL070. This cannot be so. The level-off symbol is also bugged when in VS Mode. Here might be a good point to clarify how the level-off symbol should work. In managed descent, it will show the point where the aircraft will reach either: The FCU selected altitude, if that is above an altitude constraint, (it will be shown in Cyan along with the Cyan display of the FCU selected altitude at the bottom of the altitude tape on the PFD, or, if the FCU selected altitude is the same as, or below an altitude constraint, it will show the point the aircraft will reach the constraint, it will be shown in Magenta, along with the Magenta display of the constraint below the Altitude tape on the PFD. In managed mode this point is calculated purely from the calculated path of the aircraft as shown in in the F-PLN page of the MCDU. Taking into account whether you are above or below the path, or low or high with regards to speed. If the F PLN page is predicting you are going to be too high at an altitude constraint for example, the level-off arrow will come after this constraint on the ND. The F-PLN page and the level off arrow are always in sync. In selected mode descent (open descent) the level-off arrow will show the point at which the aircraft will reach the FCU selected altitude, ignoring any constraints, and not taking the calculated path into consideration. It will be shown by a calculation of current speed and current VS. In VS descent, the level off arrow again shows the point at which the aircraft will reach the FCU selected attitude, ignoring any constraints, and not taking the calculated path into consideration. It will be shown by a calculation of current speed and FCU selected VS. Note this is different from in open descent when it is calculated by current VS. To clarify, in VS mode itself, the level off arrow is calculated by FCU selected VS. This screenshot also shows yet another bug. The missed approach waypoint on the F-PLN page should be in blue not green. This video below shows another bug. The distance remaining shown at the bottom of the F-PLN page goes from 13NM to 10NM and then back to 12NM. Apologies my cursor it a bit too close, but I was trying to point it out, though you can still see it. This is at 10 to 22 secs on the video. I hope there is enough useful information here for the team to work with. Please do get in touch should you require any further information. These are just a handful of basic errors, of course there are more, but as plenty of other people are posting, I don't which the team to be overwhelmed. As ever, I thank the team for their work, I just hope we can soon get the aircraft to a stage where such simple stuff is correct on an aircraft that is billed, and charged, as a premium product with unparalled realism. Even freeware aircraft have the majority of these basic functions working properly, so it is disappointing that the A350 does not.

I said in the post that I will write up the bugs properly. I decided to not spend more hours doing it last night after my first flight as I wanted to fly a different aircraft instead. I will probably do another flight in the A350 later and gather the evidence then.

Many thanks for the team's continued work on the A350. Having waited quite a while for this big VNAV update, I, as I'm sure many others were, was very excited to try it. However, I'm sad to say it is a pretty big disappointment. There are still very many bugs related to VNAV (as well as lots of others that have been present since release and still not fixed even though we are now on the 10th version). I was really hoping that the VNAV stuff would be fixed in this update, and it is really disappointing that the aircraft will have to go back into the hangar for me and yet again have to wait to see if these issues will be fixed. I'm not sure how some of this stuff has appeared in the changelog because it is blatantly not fixed... And the errors are so obvious after just one flight, that it is hard to understand how they are still there in the aircraft... Of course, I will write up the bugs properly and report them here, and look forward to hearing back from the team regarding them. Perhaps someone from iniBuilds could tell me if it would be easier to put all of these bugs into one post rather than clogging up the forum. It goes without saying that despite the disappointment and obvious lack of actually fixing the VNAV issues, I thank the team for their work. I just hope that one day I will feel that the aircraft was worth what I paid for it, (ignoring the hours an hours and hours I have spent testing and writing up bug reports). Many thanks again.

Yeah it is sad. 2020 with Atmos and Reshade looks better than 2024 in terms of atmospherics. The ground textures are sharper in 2020. No horrible clouds with terrible LOD just looking like blobs in the distance in 2020. Airport ground lighting is significantly better in 2020. Night lighting is better in 2020 without the hideous sepia mask. Without even going into all the horrible UI bugs. It is such a shame 3rd party developers are starting to abandon 2020, in my opinion it's by far the better sim.

Again here Showing reaching 7000ft after DETGY on the ND, but FPLN page showing crossing DETGY at 6990 - not possible.

You can see here that the SPDLIM is in the incorrect place in the F-PLN. Look at the altitudes, the aircraft can't reach the SPDLIM point in descent at a lower altitude than a waypoint with a higher altitude prediction that follows it.

I have to disagree here based on real world experience and what the FCOM states, but lets leave it for now, there are more important issues upon which to focus. As ever, thanks for engaging and speaking to the dev team, and thank all for continued work on the A350, we'll get there eventually!

Yeah they can take a bit of working out. But I am pretty sure I am correct here, plus rw experience of course. Would be great if @Eddie could acknowledge the change of opinion and forward this one!

Same. I can't access it.

Look at the waypoint GOLNI. The aircraft is basically at that waypoint, and, according to the F-PLN page the aircraft should be at M0.84, but then according to the PERF CRZ page the aircraft should be cruising at M0.85... The aircraft is, in fact, targeting M0.85 as can be seen on the PFD. This suggests the F-PLN page is incorrect and producing spurious numbers.

My understanding is that this is not correct behaviour. If ADS-B TRAFFIC is set to OFF on SURV page you should never get the ADS-B TRAFFIC ON ECAM memo because the ADS-B TRAFFIC is not ON. It is OFF. The ADS-B TRAFFIC ON memo would appear if XPDR/TCAS is in STBY, but ADS-B TRAFFIC is set to ON on the SURV page. - Non-normal. Normally in TCAS/XPDR STBY, the ADS-B TRAFFIC would be OFF, and so the memo ADS-B TRAFFIC ON is telling you that you have turned ON ADS-B TRAFFIC on the SURV page. Note there would not be a ADS-B TRAFFIC OFF memo, in a normal situation, because it is expected to be OFF Your shot from the FCOM is if ADS-B TRAFFIC on SURV page is set to ON, not to OFF, whist it would be expected to be OFF - i.e. XPDR/TCAS in STBY. As the FCOM shows here: You should actually get ADS-B TRAFFIC OFF as an ECAM memo if the ADS-B TRAFFIC button is OFF but only if XPDR in is Auto and you manually turn off the ADS-B TRAFFIC. Or if the TCAS or XPDR are on STBY in flight - non-normal. Basically any ADS-B TRAFFIC ON or OFF memo is due to a non-normal situation. So as I said it is the wrong way around in the iniBuilds aircraft. We should never see any ADS-B TRAFFIC memo unless we are in a non-normal situation. When it is appearing in the inibuilds is wrong, there should be no MEMO at all. This is because the ADS-B TRAFFIC is OFF on the ground with the XPDR/TCAS in STBY. When we turn the XPDR/TCAS to AUTO, the ADS-B TRAFFIC should turn on (the switch not the MEMO), but there should be no MEMO as it is expected to be ON with XPDR/TCAS in AUTO. If we were then to manually turn OFF the ADS-B TRAFFIC, we should get a ADS-B TRAFFIC OFF MEMO. Conversely, when in XDPR/TCAS in STBY. We should only ever get a MEMO saying ADS-B TRAFFIC ON, if we manually turn on the ADS-B TRAFFIC switch on SURV page. Sorry I am waffling. To summarise. XPDR/TCAS in STBY - Default is ADS-B TRAFFIC switch OFF - Only get a MEMO if we manually turn ON ADS-B TRAFFIC switch on SURV page - MEMO would be ADS-B TRAFFIC ON. XPDR/TCAS in AUTO - Default is ADS-B TRAFFIC switch ON- Only get a MEMO if we manually turn OFF ADS-B TRAFFIC switch on SURV page - MEMO would be ADS-B TRAFFIC OFF. I hope that make sense....