dectenor1

Yep, again here, absolutely no reason for it to want to be so low at IZS38. And it thinks it can get to the (incorrect) altitude by losing 2600ft and slowing down in 6nm... Just borked. One can also see here that the time predications are messed up for the FLAP pseudo-waypoints. Bit of a mess really.

The calculated descent path logic still needs work. There is absolutely no need for the aircraft to be planning to descend below the altitude constraint here at PRN25. If the aircraft needed to slow down, then it is possible it would be above an AT constraint, but there is no need for the aircraft to descend lower.

BKPR35 should be part of the main route and in green not blue This issue also affects things like distance remaining of the route, as it won't take into account the part from the final fix to the runway.

On this video you can see an issue with the Cabin VS constantly fluctuating.

Why has suddenly the arrival runway become part of the missed approach procedure? This is completely wrong and messes up the flight plan and various things on the F-PLN page associated with it. Looking at the changelog, it seems like this was done on purpose....

I'm afraid issues with the flight plan and the F-PLN page are a total mess since the last update. Just look at all those altitude predictions at 10ft... I think it is something to do with the path not being drawn on the ND from the FAF to the runway as we have both reported elsehwere, it is like the flight plan ends at some waypoint on the approach. I would do more testing, but it's not my job and frankly I have better things to do.

Yeah I have to agree here. I usually do a few flights after a new version, and see the same old bugs and then also new bugs, and so the aircraft goes straight back to the hangar. Again, as @Der Michel says, these are basic things, I don't really understand why they were incorrect in the first place or have not been fixed. For those of us who enjoy realism, there is just no desire to fly this aircraft when there are others that simply don't have these basic errors. It is very disappointing for an aircraft that is marketed as offering unparalleled immersion and realism . One can see how the frustration builds as well, when we constantly see new features, snow accumulation, printers etc., and yet the basic core functions still do not work. I do not mean to be negative, it is just so frustrating when you spend hours and hours of your own time testing and making reports, reading the FCOM etc., and you just wonder if anyone from the team is also actually doing this, given that all the basic errors and bugs are still there after all these updates. Of course it goes without saying that I thank all the team for the continued work on it, we'll get there eventually. It is just a shame that the release was, and still is, so far off what was promised.

Seeing this also, and also with ILS approaches. Included it a few bugs I added at the weekend.

Yes also seeing this!

2020 or 2024? Do you have GSX set to auto reposition? I think since the last a350 update, when the aircraft does this reposition it removes the GPU and you then can't get power.

Also incorrect placement of DECEL FLAP1 and FLAP2 pseudo-waypoints I mean there is a lot wrong with this. CHLF is 5nm from the runway and the aircraft wants be at 10ft.... And it is not connected to the rwy on the ND. Something odd with this approach. Again flown regularly with other aircraft and never experienced this.

I should add that I am now using 1.0.12, but the same applies as was only a hotfix update, and didn't address these issues, so these (including the original post) relate to v1.0.12 as well.

A few more things. When repositioning the aircraft with GSX to go to the correct place for the gate you spawned at. It is disconnecting the GPU, so I am having to start the APU to even get the OIS screen on to be able to set chocks and reconnect the GPU. Then turn APU back off etc. It's cumbersome. Also seemed to bring up an error on STS & DEFRD PROC of L/G Gravity EXTN T/O CONFIG TEST is showing as OK on the C/L Menu, when you haven't actually done the T/O CONFIG Test, so there is a discrepancy between the Test on the ECAM and on the Checklist. Entries made on FUEL&LOAD page for RTE RSV, ALTN, and FINAL, are reset when the ZFW and ZFWCG Fields are updated. Selected ILS 22L in Copenhagen and it doesn't fill LS (Identifier) and FREQ/CHAN on Select Arrival Page (could be navigraph issue, but flown here in other aircraft and it has always got the identifier and the freq without having to enter it manually on the NAV AID page.

Here you can see GSX says 367 PAX have been loaded, OIS says 357...

Thanks! I will give this a go!

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,