bugs A350 v1.1.0 Bugs

[dectenor1]

Many thanks for the continued work on the the A350, it is, however, quite frustrating that there are still so many bugs and systems errors. We were told that this update would fix bugs that the community were still facing. The vast majority of these bugs and basic systems errors have been in the aircraft for months now and have still not been fixed. They are all basic level things, that have involved no deep dives into systems or anything like that. Just simple things would be spotted in 1 flight by a tester who knows about the A350 and basic Airbus logic in general.  It is certainly not yet at the level of fidelity it was marketed as being.

Sorry if the above seems negative, it is not intended to be, I just love the A350 and wish it to be as good as it can be in the sim, it certainly has great potential. I have obviously spent hours and hours, testing and writing up reports such as these, gathering the screenshots, uploading clips to youtube etc. It just seems frustrating the hours I have personally spent trying to improve this aircraft, yet all these basic issues seem to go completely unnoticed by any in-house testing. 

Anyway I digress, and please, I really am grateful for the work that has gone into this aircraft, the last update did fix a lot of things, just there are so many more issues out there that still need fixing and more updates.

I make no mention of the flight model, texturing, or sounds here, as they are more subjective, and I would prefer just to report the objective basic things that are wrong first.

 

• Though on the whole in terms of the flight model, the aircraft continues to roll even with no sidestick deflection, which is completely incorrect and against all airbus FBW logic. Put simply, once there is no sidestick deflection, the aircraft should not change roll rate, but unfortunately this is not the case with your A350. It leads to pilot induced oscillation, and the large number of poorly flown approaches that can be said in many videos and streams of the iniBuilds A350.

 

• The sound quality of individual sounds is good I think, but the overall mixing I believe to be generally not so good. There are balancing issues, and sounds fading in and out unrealistically that seems to be done in order to achieve a constant decibel level. Rather as is if the sounds have been modelled on a video or audio recording whereby when things are quieter the mics pick up more of the quiet sounds to achieve a constant audio volume.

 

Anyway, on to the systems. I will provide a description of the bug/error and then a screenshot or video below where applicable.

 

iniBuilds A350 v1.1.0 Bugs

 

These first three are related to GSX, so I am only including here if there is anything that can be done on iniBuilds’ side. In previous versions of the A350, I did not notice these behaviours, so it may that it is something that you guys can fix, or it maybe GSX, but either way it is worth letting you guys know, and it is also an issue I do not experience with other aircraft. Maybe it is something related to how the A350 reacts in slew mode, maybe you can change something so that with slew mode, the aircraft’s current state is preserved.

 

• When using GSX to reposition the aircraft (as the aircraft loads into the sim in the wrong place), the GPU disconnects. You can’t turn on the OIS on the battery alone even though all the other screens are operable with just the battery. This means that you need to start the APU to get power to turn on the OIS to reconnect the GPU, then shut down the APU etc.

 

• Related to this, when repositioning you get the Landing Gear Gravity Extension Warning, which does not go away by even resetting the Panel State.

 

• There is a periodic big stutter every 4 seconds or so, maybe as the aircraft is syncing data with GSX?

 

GSX Out of the way - 

 

• If you have entered custom values for TAXI RTE RSV ALTN FINAL FUEL on the Fuel and Load page for example to the correct values according to Simbrief, changing the value for ZFW or ZFWCG or BLOCK FUEL resets these previously entered custom values. This is incorrect, once a custom value has been entered, it should be persistent.

 

• Turning on the XPDR to Auto from STBY automatically sets the TCAS to TA/RA. This is incorrect behaviour, turning on the XPDR, should not affect the TCAS setting.

 

• The TO CONFIG TEST should be able to be performed and get NORMAL result, even without the cabin being ready, at the moment you have to wait for Cabin Ready before being able to complete the TO CONFIG test, this is incorrect.

 

• Turn Around Time on BVT is still the same regardless of the exit selected. (BTV Information also doesn't now show up unitl A/BRK is pushed, before we used to get the information on the exit, by selecting it on the map, even before A/BRK button pushed. - will check which is correct

 

• When going to Selected Speed from Managed Speed, the FCU window is opening on the Managed Target Speed rather than the current speed. This is incorrect, it should open at the aircraft’s current speed.

 

 

 

• ADS-B TRAFFIC MEMO logic is still incorrect. Here you can see the ECAM showing it ON when it is clearly selected OFF.

 

 

• The logic for showing MACH or SPEED in the FCU window is still incorrect. Here you can see the aircraft is targeting a SPD, 304 IAS, as shown on the PERF CLB page and the PFD. If it was targeting a MACG it would be 0.84 not .775 as shows. The aircraft is targeting a Speed, not a MACH, and so the aircraft should show SPD in the FCU window, not MACH. This window should always show SPD if a speed is being targeted and MACH if a Mach is being targeted. At the moment, it is just simply changing to MACH above FL280 and SPD below it. This is completely incorrect.

 

 

• The VNAV behaviour when approaching a hard altitude constraint is incorrect. You can see here as the aircraft approaches INPIP (AT FL260) it pitches up and adds thrust. The aircraft then ends up above profile and so has to dive to catch it up. If the calculated path after the constraint is the same angle as before, it should just carry on descending and should not have to pitch up and add thrust as it approaches the constraint.

 

 

 

• You can see here that the Approach is selected on the F-PLN arrival page, but there is no frequency or LS identifier. The frequency is also incorrect on the PFD and then had to be entered manually. So the aircraft is clearly not getting the ILS data correctly when it is entered on the F-PLN Arrival page. This is with the latest navigraph data, updated through the OIS.

 

 

• VNAV Logic – the 250kt restriction at ESKDO is shown in magenta on the ND and also has a magenta asterisk next to it on the F-PLN page. This indicates that the aircraft will meet the constraint. This is clearly incorrect, the aircraft is very close to ESKDO and almost 50kt too fast, the aircraft will not make this constraint and so should be in orange not magenta.

 

 

• You can also see in this shot that there is an inconsistency between the managed speed target on the PFD and on the DES PERF page. It is shown as 250 on the PFD but .84/313 on the PERF page. Clearly incorrect. The aircraft is targeting 250 because of the ESKDO constraint, and therefore the DES PERF page should just show 250 with no value (dashed out) for mach.

 

• The number of passengers boarded is incorrect, GSX is saying 367 PAX have boarded but on the OIS it shows 367. The ZFW was correct, so 367 had been boarded but the OIS is showing the incorrect value. Simbrief flight plan was also 367, so it is the OIS that is incorrect.

 

 

• The DES PERF page on the right is showing the first SPD CSTR target as being 230 KT at TARTN, but the first speed constraint should actually be 250 at ESKDO.

 

 

• VNAV Logic – Predictions of whether constraints will be met (magenta/orange on PFD and magenta/orange asterisk on F-PLN page, the actual Altitude Predictions on F-PLN page, and the level-off arrow are still broken, and always inconsistent with each other. Let’s look at INREV as an example. The level-off arrow is indicating we will be at FL200 at INREV (should also be purple arrow not blue, as in managed descent and FL200 is a constraint even though was also selected in FCU, should only be blue if the FCU selected altitude is higher than the constraint on descent and vice versa lower than the constraint on climb). But anyway, arrow, indicating that we will be at FL200 at INREV, so why is the circle around the waypoint on the ND orange? If the aircraft will meet the constraint, it should be magenta. Then on the F-PLN page, it says we will be at FL200 and the asterisk is magenta. How can it be orange on the ND and magenta on the F-PLN page. Doesn’t make sense and obviously incorrect. A lot of the Altitude and Speed restrictions on the F-PLN are just not good or reliable, Altitude predictions are shown at waypoints, but then when you arrive there, you simply are not at the altitude it says you will be at. Of course these predictions can change as wind changes, maybe you level off for a bit due to ATC etc. The FMC should be constantly calculating the vertical path and predicting the correct altitudes and speeds at the F-PLN waypoints. With correct information displayed as to whether speed or altitude constraints will be met or not.

 

 

 

• The lower screens are a different brightness to the upper screens when on the same brightness setting, Look at the lower screens and then the PFD and ND on captain’s side, same brightness setting but different brightness.

 

 

• VNAV Logic – Here you can see the managed target speed has completely ignored the SPD Constraint at TARTN. The magenta dot on the PFD is indicating a managed target speed of 250 KT, but there is a SPD CTSR at TARTN of 230 KT, so it should be 230. Hence had to go into selected SPD.

 

 

• VNAV Logic – Later on, the PFD did indicate a managed SPD target of 230 kts, as can be seen by the magenta bug. But the F-PLN PERF page is showing a managed speed target of .84 and 250 KT. This is clearly incorrect. Once the aircraft is targeting a speed constraint, the MACH value on the PERF page should be dashed out, and the value for SPD should be the same as the constraint.

 

 

• PRED TO logic – Here you can see that manually entering the same altitude in the PRED TO box gives different values to if there is no custom altitude entered and the value there is just the default (which should be the FCU selected altitude). When it is default (small font numbers) FL320 it shows 16:39 and 82NM (obviously changes to 81, etc as the aircraft flies). Manually entering FL320 gives 17:12 and 303 NM. Clearly incorrect, also this is interestingly the total remaining flight distance and estimated arrival time (more on that later). Whether it is the default altitude from the FCU or the same altitude but entered manually, it clearly should produce the same result.

 

 

• LNAV path drawing - INPIP2E, ILS24, TLA transition at EGPH – eugh I don’t think so. Lines not joined up, totally missing out one waypoint, then a loop. Clearly something broken here. This is with the latest navigraph data, updated through the OIS.

 

 

• Predicted arrival time is broken. We are just turning final, 11nm of the flight remaining as shown at the bottom of the F-PLN page. The current time is 10:48 but estimated arrival time of 11:10. 22 mins to do 11 nautical miles. I don’t think so. Even the next waypoint which is 1nm away is predicted at 11:07, that’s 19 mins to do 1 nautical mile, I could walk it faster than that, and the aircraft is doing over 300 mph… clearly incorrect.

 

 

• VNAV Logic – The SPDLIM pseudo waypoint is in a totally spurious place, in fact the aircraft should already be targeting 250 KT at ESKDO which it is predicting to be at at FL163, so the SPDLIM is actually irrelevant. The SPDLIM pseudo waypoint should be shown in the F-PLN page at the point when the aircraft begins to pitch up to decelerate to 250 KT at FL100/10000ft. If the aircraft will not do this, because there is some constraint before FL100 that means the aircraft will already be going at 250 or below, the SPDLIM pseudo waypoint will not be there. Similarly, if the managed descent econ speed is 250 or below anyway – obviously unlikely, but would still result in there being no SPDLIM pseudo waypoint.

 

 

• Here the SPDLIM is in the correct place so it is not about the positioning of the SPDLIM pseudo waypoint, but rather its ALT prediction as shown on the F-PLN page. It is given as 11290. But this above the TRANS LEVEL which at the bottom of the DES PERF page is shown as FL110. So the ALT prediction for the SPDLIM should be FL113 not 11290.            

 

 

• Similarly here, this time on climb. The TRANS ALT is 6000 FT, therefore UMLAT on F-PLN page should be 6000 not FL060. TRANS ALT is the altitude that ‘at’ which or ‘below’ the aircraft uses local pressure and altitudes are expressed in ft. 6000 is ‘at’ so should be 6000 not FL060. TRANS LEVEL is ‘at’ or ‘above’. FL060 would be correct on descent if it was TRANS ‘LEVEL’ FL060, because again it’s ‘at’ or ‘above’, but if it is the TRANS ALT that is 6000 for climb, FL060 is incorrect.

 

 

 

• When initiating the descent before the T/D waypoint, the aircraft stays in the CRZ phase until intercepting the path. The is incorrect. It should immediately go into DES phase at -1000fpm until intercepting the path, and the green dot path indicator on the altitude tape should immediately appear.

 

• When in OPEN CLB or DES, for example, on a SID, if you put 10000 FT in the FCU and in OPEN CLIMB, but you pass a waypoint with a constraint of AT 6000, you still get the flashing yellow warning box around the altitude indicator when you are 1000ft way from the constraint. This is incorrect, the constraint should be completely ignored when in OPEN CLB with a higher FCU selected altitude and the flashing yellow warning box around the altitude indicator on the PFD should not be displayed.

 

Again, many thanks for the continued work on this project. 

Please do reach out should you require any more information, or any assistance to try and get the aircraft to the level it was marketed and sold at.

 

 

 

 

Edited 23 hours ago by dectenor1

[dectenor1]

@Der Michel Would be interesting to read any comments on these.

Best.

[Swisspilot1986]

nice work! What I understood is that updates will be becoming less frequents after the release of HUD next week because ressources will be more affected to future products. IniBuilds should be clear with their customers until what level the aircraft will be put. Maybe the marketing or/and customers' expectations were too optimistic.

[foliainfx]

6 hours ago, dectenor1 said:

Many thanks for the continued work on the the A350, it is, however, quite frustrating that there are still so many bugs and systems errors. We were told that this update would fix bugs that the community were still facing. The vast majority of these bugs and basic systems errors have been in the aircraft for months now and have still not been fixed. They are all basic level things, that have involved no deep dives into systems or anything like that. Just simple things would be spotted in 1 flight by a tester who knows about the A350 and basic Airbus logic in general.  It is certainly not yet at the level of fidelity it was marketed as being.

Sorry if the above seems negative, it is not intended to be, I just love the A350 and wish it to be as good as it can be in the sim, it certainly has great potential. I have obviously spent hours and hours, testing and writing up reports such as these, gathering the screenshots, uploading clips to youtube etc. It just seems frustrating the hours I have personally spent trying to improve this aircraft, yet all these basic issues seem to go completely unnoticed by any in-house testing. 

Anyway I digress, and please, I really am grateful for the work that has gone into this aircraft, the last update did fix a lot of things, just there are so many more issues out there that still need fixing and more updates.

I make no mention of the flight model, texturing, or sounds here, as they are more subjective, and I would prefer just to report the objective basic things that are wrong first.

 

• Though on the whole in terms of the flight model, the aircraft continues to roll even with no sidestick deflection, which is completely incorrect and against all airbus FBW logic. Put simply, once there is no sidestick deflection, the aircraft should not change roll rate, but unfortunately this is not the case with your A350. It leads to pilot induced oscillation, and the large number of poorly flown approaches that can be said in many videos and streams of the iniBuilds A350.

 

• The sound quality of individual sounds is good I think, but the overall mixing I believe to be generally not so good. There are balancing issues, and sounds fading in and out unrealistically that seems to be done in order to achieve a constant decibel level. Rather as is if the sounds have been modelled on a video or audio recording whereby when things are quieter the mics pick up more of the quiet sounds to achieve a constant audio volume.

 

Anyway, on to the systems. I will provide a description of the bug/error and then a screenshot or video below where applicable.

 

iniBuilds A350 v1.1.0 Bugs

 

These first three are related to GSX, so I am only including here if there is anything that can be done on iniBuilds’ side. In previous versions of the A350, I did not notice these behaviours, so it may that it is something that you guys can fix, or it maybe GSX, but either way it is worth letting you guys know, and it is also an issue I do not experience with other aircraft. Maybe it is something related to how the A350 reacts in slew mode, maybe you can change something so that with slew mode, the aircraft’s current state is preserved.

 

• When using GSX to reposition the aircraft (as the aircraft loads into the sim in the wrong place), the GPU disconnects. You can’t turn on the OIS on the battery alone even though all the other screens are operable with just the battery. This means that you need to start the APU to get power to turn on the OIS to reconnect the GPU, then shut down the APU etc.

 

• Related to this, when repositioning you get the Landing Gear Gravity Extension Warning, which does not go away by even resetting the Panel State.

 

• There is a periodic big stutter every 4 seconds or so, maybe as the aircraft is syncing data with GSX?

 

GSX Out of the way - 

 

• If you have entered custom values for TAXI RTE RSV ALTN FINAL FUEL on the Fuel and Load page for example to the correct values according to Simbrief, changing the value for ZFW or ZFWCG or BLOCK FUEL resets these previously entered custom values. This is incorrect, once a custom value has been entered, it should be persistent.

 

• Turning on the XPDR to Auto from STBY automatically sets the TCAS to TA/RA. This is incorrect behaviour, turning on the XPDR, should not affect the TCAS setting.

 

• The TO CONFIG TEST should be able to be performed and get NORMAL result, even without the cabin being ready, at the moment you have to wait for Cabin Ready before being able to complete the TO CONFIG test, this is incorrect.

 

• Turn Around Time on BVT is still the same regardless of the exit selected. (BTV Information also doesn't now show up unitl A/BRK is pushed, before we used to get the information on the exit, by selecting it on the map, even before A/BRK button pushed. - will check which is correct

 

• When going to Selected Speed from Managed Speed, the FCU window is opening on the Managed Target Speed rather than the current speed. This is incorrect, it should open at the aircraft’s current speed.

 

 

 

• ADS-B TRAFFIC MEMO logic is still incorrect. Here you can see the ECAM showing it ON when it is clearly selected OFF.

 

 

• The logic for showing MACH or SPEED in the FCU window is still incorrect. Here you can see the aircraft is targeting a SPD, 304 IAS, as shown on the PERF CLB page and the PFD. If it was targeting a MACG it would be 0.84 not .775 as shows. The aircraft is targeting a Speed, not a MACH, and so the aircraft should show SPD in the FCU window, not MACH. This window should always show SPD if a speed is being targeted and MACH if a Mach is being targeted. At the moment, it is just simply changing to MACH above FL280 and SPD below it. This is completely incorrect.

 

 

• The VNAV behaviour when approaching a hard altitude constraint is incorrect. You can see here as the aircraft approaches INPIP (AT FL260) it pitches up and adds thrust. The aircraft then ends up above profile and so has to dive to catch it up. If the calculated path after the constraint is the same angle as before, it should just carry on descending and should not have to pitch up and add thrust as it approaches the constraint.

 

 

 

• You can see here that the Approach is selected on the F-PLN arrival page, but there is no frequency or LS identifier. The frequency is also incorrect on the PFD and then had to be entered manually. So the aircraft is clearly not getting the ILS data correctly when it is entered on the F-PLN Arrival page. This is with the latest navigraph data, updated through the OIS.

 

 

• VNAV Logic – the 250kt restriction at ESKDO is shown in magenta on the ND and also has a magenta asterisk next to it on the F-PLN page. This indicates that the aircraft will meet the constraint. This is clearly incorrect, the aircraft is very close to ESKDO and almost 50kt too fast, the aircraft will not make this constraint and so should be in orange not magenta.

 

 

• You can also see in this shot that there is an inconsistency between the managed speed target on the PFD and on the DES PERF page. It is shown as 250 on the PFD but .84/313 on the PERF page. Clearly incorrect. The aircraft is targeting 250 because of the ESKDO constraint, and therefore the DES PERF page should just show 250 with no value (dashed out) for mach.

 

• The number of passengers boarded is incorrect, GSX is saying 367 PAX have boarded but on the OIS it shows 367. The ZFW was correct, so 367 had been boarded but the OIS is showing the incorrect value. Simbrief flight plan was also 367, so it is the OIS that is incorrect.

 

 

• The DES PERF page on the right is showing the first SPD CSTR target as being 230 KT at TARTN, but the first speed constraint should actually be 250 at ESKDO.

 

 

• VNAV Logic – Predictions of whether constraints will be met (magenta/orange on PFD and magenta/orange asterisk on F-PLN page, the actual Altitude Predictions on F-PLN page, and the level-off arrow are still broken, and always inconsistent with each other. Let’s look at INREV as an example. The level-off arrow is indicating we will be at FL200 at INREV (should also be purple arrow not blue, as in managed descent and FL200 is a constraint even though was also selected in FCU, should only be blue if the FCU selected altitude is higher than the constraint on descent and vice versa lower than the constraint on climb). But anyway, arrow, indicating that we will be at FL200 at INREV, so why is the circle around the waypoint on the ND orange? If the aircraft will meet the constraint, it should be magenta. Then on the F-PLN page, it says we will be at FL200 and the asterisk is magenta. How can it be orange on the ND and magenta on the F-PLN page. Doesn’t make sense and obviously incorrect. A lot of the Altitude and Speed restrictions on the F-PLN are just not good or reliable, Altitude predictions are shown at waypoints, but then when you arrive there, you simply are not at the altitude it says you will be at. Of course these predictions can change as wind changes, maybe you level off for a bit due to ATC etc. The FMC should be constantly calculating the vertical path and predicting the correct altitudes and speeds at the F-PLN waypoints. With correct information displayed as to whether speed or altitude constraints will be met or not.

 

 

 

• The lower screens are a different brightness to the upper screens when on the same brightness setting, Look at the lower screens and then the PFD and ND on captain’s side, same brightness setting but different brightness.

 

 

• VNAV Logic – Here you can see the managed target speed has completely ignored the SPD Constraint at TARTN. The magenta dot on the PFD is indicating a managed target speed of 250 KT, but there is a SPD CTSR at TARTN of 230 KT, so it should be 230. Hence had to go into selected SPD.

 

 

• VNAV Logic – Later on, the PFD did indicate a managed SPD target of 230 kts, as can be seen by the magenta bug. But the F-PLN PERF page is showing a managed speed target of .84 and 250 KT. This is clearly incorrect. Once the aircraft is targeting a speed constraint, the MACH value on the PERF page should be dashed out, and the value for SPD should be the same as the constraint.

 

 

• PRED TO logic – Here you can see that manually entering the same altitude in the PRED TO box gives different values to if there is no custom altitude entered and the value there is just the default (which should be the FCU selected altitude). When it is default (small font numbers) FL320 it shows 16:39 and 82NM (obviously changes to 81, etc as the aircraft flies). Manually entering FL320 gives 17:12 and 303 NM. Clearly incorrect, also this is interestingly the total remaining flight distance and estimated arrival time (more on that later). Whether it is the default altitude from the FCU or the same altitude but entered manually, it clearly should produce the same result.

 

 

• LNAV path drawing - INPIP2E, ILS24, TLA transition at EGPH – eugh I don’t think so. Lines not joined up, totally missing out one waypoint, then a loop. Clearly something broken here. This is with the latest navigraph data, updated through the OIS.

 

 

• Predicted arrival time is broken. We are just turning final, 11nm of the flight remaining as shown at the bottom of the F-PLN page. The current time is 10:48 but estimated arrival time of 11:10. 22 mins to do 11 nautical miles. I don’t think so. Even the next waypoint which is 1nm away is predicted at 11:07, that’s 19 mins to do 1 nautical mile, I could walk it faster than that, and the aircraft is doing over 300 mph… clearly incorrect.

 

 

• VNAV Logic – The SPDLIM pseudo waypoint is in a totally spurious place, in fact the aircraft should already be targeting 250 KT at ESKDO which it is predicting to be at at FL163, so the SPDLIM is actually irrelevant. The SPDLIM pseudo waypoint should be shown in the F-PLN page at the point when the aircraft begins to pitch up to decelerate to 250 KT at FL100/10000ft. If the aircraft will not do this, because there is some constraint before FL100 that means the aircraft will already be going at 250 or below, the SPDLIM pseudo waypoint will not be there. Similarly, if the managed descent econ speed is 250 or below anyway – obviously unlikely, but would still result in there being no SPDLIM pseudo waypoint.

 

 

• Here the SPDLIM is in the correct place so it is not about the positioning of the SPDLIM pseudo waypoint, but rather its ALT prediction as shown on the F-PLN page. It is given as 11290. But this above the TRANS LEVEL which at the bottom of the DES PERF page is shown as FL110. So the ALT prediction for the SPDLIM should be FL113 not 11290.            

 

 

• Similarly here, this time on climb. The TRANS ALT is 6000 FT, therefore UMLAT on F-PLN page should be 6000 not FL060. TRANS ALT is the altitude that ‘at’ which or ‘below’ the aircraft uses local pressure and altitudes are expressed in ft. 6000 is ‘at’ so should be 6000 not FL060. TRANS LEVEL is ‘at’ or ‘above’. FL060 would be correct on descent if it was TRANS ‘LEVEL’ FL060, because again it’s ‘at’ or ‘above’, but if it is the TRANS ALT that is 6000 for climb, FL060 is incorrect.

 

 

 

• When initiating the descent before the T/D waypoint, the aircraft stays in the CRZ phase until intercepting the path. The is incorrect. It should immediately go into DES phase at -1000fpm until intercepting the path, and the green dot path indicator on the altitude tape should immediately appear.

 

• When in OPEN CLB or DES, for example, on a SID, if you put 10000 FT in the FCU and in OPEN CLIMB, but you pass a waypoint with a constraint of AT 6000, you still get the flashing yellow warning box around the altitude indicator when you are 1000ft way from the constraint. This is incorrect, the constraint should be completely ignored when in OPEN CLB with a higher FCU selected altitude and the flashing yellow warning box around the altitude indicator on the PFD should not be displayed.

 

Again, many thanks for the continued work on this project. 

Please do reach out should you require any more information, or any assistance to try and get the aircraft to the level it was marketed and sold at.

 

 

 

 

Hi,

 

"The TO CONFIG TEST should be able to be performed and get NORMAL result, even without the cabin being ready, at the moment you have to wait for Cabin Ready before being able to complete the TO CONFIG test, this is incorrect." 

- This is actually an airline option.

"Turn Around Time on BVT is still the same regardless of the exit selected. (BTV Information also doesn't now show up unitl A/BRK is pushed, before we used to get the information on the exit, by selecting it on the map, even before A/BRK button pushed. - will check which is correct"

- The turn around logic is still not implemented, and still WIP.

 

Regarding the A350 in general:

iniBuilds should make the A350 from the ground up, many basic system functions are incorrect. VNAV and VD are currently unable to calculate and properly display missed altitude constraints. This was supposed to be fixed in V.1.1.0 but was, aswell as many other issues, not fixed. There are a lot more issues not included in this post like TOW and LW calculations. There are several failures are incorrectly simulated or just do not work. Here is a list of key things that should be reworked in the iniBuilds A350 which pose a significant issue:

- ECAM

- FMA

- FCU

- MCDU

- Model

- Sounds

- FBW

- Electrical network

- Hydraulic network

- ANF

- VNAV

- LNAV

- EFB

- AC network

- Fuel system

- Flight controls

- DRAIMS

- VD

- Failures

- Effect of mass on MLG and NLG

- Texures

- ROPS

-ROW

- ANF

I could keep going but I'm sure you get the point.

 

[unairspace]

To be honest, I started to lose confidence. I was very worried that in terms of aircraft add-on creation ini would end up being another AxxxxxxT.

Edited 17 hours ago by unairspace

[YS0430]

4 hours ago, unairspace said:

To be honest, I started to lose confidence. I was very worried that in terms of aircraft add-on creation ini would end up being another AxxxxxxT.

Finger crossed they won't go that route... this is by far the single most expensive purchase for flight sim but I really loved the A350 being one of the longest plane flying. but then the issues plagued since day 1 is so frustrating...