dectenor1

Ahh many thanks. I wasn't aware of this. No problem at all.

Yes also seeing this, though not always.

The Loadsheet screen could be really improved by having a 'planned' and 'current' (only suggested nomenclature, but seem to make sense to me at least) section for various values, in order to verify payload and fuel etc. When loading via GSX and not importing from simbrief for example, it is really hard to know if you have the correct values in, or whether the CGs have updated. So a section showing both planned and current things like fuel, ZFW, Gross Weigh, PAX, Cargo, ZFWCG, GWCG would be really really useful I think.

From the outside view, the interior of the cabin seems to be totally missing and you can see out through the other side of the aircraft. For example here, if you look carefully you can see through and see the wing on the other side. Here, looking when the cargo door is open, you can see completely through the aircraft and out the other side. Also weird sort of missing door when you look from the side.

No problem! Thanks

Many thanks for all the team's continued work on the aircraft. Here are some simple bugs and errors I encountered on a test flight. In each of these cases, the relevant screenshot will be posted below the outline of the bug. Pretty sure should not be in DCLB thrust mode when just powering up the aircraft. OIS Power buttons still do not work ADS-B TRAFFIC ON ECAM MEMO when ADS-B TRAFFIC is OFF The first constraint of the climb should be in Magenta on PFD at the top of the altitude tape, not the FCU selected altitude in Blue - So here it should be magenta 6000 as there is an AT Constraint at UMLAT as can be seen on MCDU Pages. Syncing values on TO PERF OIS page does not overwrite any pre existing values, for instance if TOW has changed. Turning TXPR on sets TCAS to TA/RA, should stay in STBY TO CONFIG TEST should be OK if everything else is set other than CABIN.... READY. It does not need the cabin to be ready to get take-off config OK. Extremely annoying repetitive 'knocking' sound when taxiing. ECAM TCAS STBY when XPDR is on and TCAS in TA/RA There is no ECAM memo or SYS page message appearing when G/S MODE and GPWS are set to OFF are not coming. The aircraft is still loading with TRAF enabled here (it might be on ID, I can't remember as I had turned it off. I just turned back on here to show where it shouldn't be enabled.) The FCU MACH/SPD window is just changing to MACH above FL280 and SPD below FL280. This is incorrect behaviour. It should show SPD when the aircraft is targeting a SPD and MACH when targeting a MACH. For example here, the aircraft is targeting ECON CLB of 304KT, as can be seen by the magenta bug on the PFD being at 304, which at this altitude is equal to .772 MACH. It is clearly targeting SPD and not MACH, as it can be seen on CLB PERF page, that the aircraft will target MACH when 304 KTS becomes 0.85 MACH and we are not high enough for 304 to equal .85 yet. So the FCU window should show SPD and not MACH. Basically, the correct way is that irrespective of altitude, the FCU window should show SPD when the aircraft is targeting a speed in IAS, and MACH when it is targeting a MACH. At the moment it just seems to switch to MACH above FL280 and then back to SPD when descending through FL280 on the way back down. It is bugged in the same manner during descent. The CHECK DEST DATA MCDU message should go away once the requisite fields are entered. Here you can see it is still being displayed even though everything is filled in. When descent is begun, (as it can be seen it has by the DES FMA on the PFD) the aircraft should display the green vertical path indicator on the altitude tape. In the current build, it is not showing until the aircraft's shallow 1000ft descent intercepts with the path. The PERF page should also change to the DES sub-page, and DES should be in green rather than CRZ. Still the Constraint logic is bugged in terms of drawing on the PFD, or the F-PLN page Altitude predictions are incorrect. Both the altitude constraints at INREV and ESKDO are shown in orange in the PFD, indicating they will not be met, but the F-PLN page shows them in Magenta, with the correct altitudes in the Altitude Prediction column, indicating the constraints will be met. You can also see that the level-off arrow does not match with the F-PLN page. The F-PLN page is showing INPIP at FL260, but the level off arrow is showing not reaching FL260 until almost at INREV. Clearly there is a bug here. Again the F-PLN page Altitude predictions do not match with the level off arrow. The F-PLN page is showing the aircraft will be at INREV at FL200, yet the level off arrow is beyond INREV and INREV is showing with an orange circle. So either the level-off arrow is incorrect, or the F-PLN page is incorrect, therefore, it is bugged either way. The aircraft is clearly not going to meet the SPD Constraint at ESKDO and yet the F-PLN page SPD prediction still shows 250 KT and a Magenta asterisk, indicating the constraint will be met. Another bug that be seen in the screenshot below is that the PFD is indicating a managed descent speed target of 250 KT but the PERF page is still showing .85 318KTS. The PERF page should show 250 KTS as this is the aircraft's managed descent target speed, (due to the Speed constraint at ESKDO), and the MACH should disappear as the aircraft is limited by a speed restriction rather than its calculated ECON DES speeds. Note this would also be the case if there were no speed constraints but rather just the regular FL100 at 250. So, in general, from the top of descent, it should show the MACH and the Conversion IAS. But then as soon as there is a constraint on the descent, or just the regular 250 at 10000ft, the DES PERF page should just display this constraint. LDG INHIBIT ECAM is not going away after landing. The aircraft door just randomly opened and the jetway connected as I was at the gate before I had even turned the engines off or anything. Could be a GSX thing, but it has never happened on any previous build or on any other aircraft. The parking brake handle sound can be heard in drone camera. Obviously these are are quite a large list bugs and errors encountered om just doing a short simple flight without even scratching the service. I really would love to see this aircraft be free from these basic bugs so please do let me know if there is anything I can do to help in this regard. I have lots of spare time as the moment, and as you can see from me writing these up and previous reports, I am more than willing to spend my own free time trying to get this aircraft to be as good as possible, and up to the standard that it was marketed and priced at. It does take a lot of time to write these up and gather the correct screenshots etc, and I just wish there was something I could do that would be more useful. Clearly these basic things are somehow being missed during the development or during the testing, and I would just like to help in any way I can to make sure this is not the case. Of course, as I already said, thank you for work on the aircraft, I really do appreciate it, and none of this is supposed to come across as a criticism at all, I simply want to help and try and get the aircraft as good as possible, as I'm sure does the iniBuilds team.

Can confirm the TCAS STBY Bug Related to this, when one sets the XPDR to AUTO, the TCAS is going automatically to TA/RA, whereas it should stay in STBY

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....

I notice the GW display here is also flickering, so it is probably related to the aircraft thinking that its weight is changing, resulting in different target managed speeds.... Hope that is useful for diagnosis and fixing.

Here on the PF MCDU page you can see that there are various altitude predictions given in FLXXX format. However, on the PM MCDU page you can see the Transition Level is FL130, this means that the altitude predictions below this level on the F-PLN page should be given as an altitude not a FL. For example, RUDBI should show 8000 not FL080.

You can see the same issue further along the flight here. The level-off arrow is showing being at FL130 before NOSKO, yet on the F-PLN page, the aircraft is predicting it will be higher than FL130 at NOSKO.