dectenor1 Posted July 3 Posted July 3 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. 13
dectenor1 Posted July 3 Author Posted July 3 @Der Michel Would be interesting to read any comments on these. Best.
Swisspilot1986 Posted July 3 Posted July 3 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 Posted July 3 Posted July 3 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. 1
unairspace Posted July 3 Posted July 3 (edited) 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 July 3 by unairspace
YS0430 Posted July 4 Posted July 4 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... 1
AFR276 Posted July 5 Posted July 5 Not to mention that the NAV button is broken on takeoff and cannot reset. Well I guess I can park this for a while until 2.0
Farlis Posted July 6 Posted July 6 (edited) 16 hours ago, AFR276 said: Not to mention that the NAV button is broken on takeoff and cannot reset Huh? Could you be more specific? Guys, this is not a place to vent, it's to report bugs. "NAV button is broken on takeoff" is not a bug report. Edited July 6 by Farlis
dreamboi Posted July 9 Posted July 9 I also encountered a similar issue; planes do not intercept blind landing signals and loc also includes the airport's VOR signal station, which does not display distances on the nd panel.
balus Posted July 9 Posted July 9 At present my A350 is in the hanger until the constant WASM issue on load is resolved, the aircraft cannot be powered on. There are plenty of posts in the various forums but no reponse other than, "we are looking at it" I have reported the WASM crash but have received zero response - it's sad, this aircraft had so much potential. 1
dreamboi Posted July 9 Posted July 9 4 minutes ago, balus said: At present my A350 is in the hanger until the constant WASM issue on load is resolved, the aircraft cannot be powered on. There are plenty of posts in the various forums but no reponse other than, "we are looking at it" I have reported the WASM crash but have received zero response - it's sad, this aircraft had so much potential. If these issues cannot be resolved I will try to get a refund.
dectenor1 Posted July 9 Author Posted July 9 (edited) @Eddie Following from DM, here is a bunch of stuff with v1.1.0 to get started on. Do feel free to ask here or DM, if you need any more info. Best Edited July 9 by dectenor1
chumley Posted July 10 Posted July 10 1 hour ago, dreamboi said: If these issues cannot be resolved I will try to get a refund. Start the batteries and use them to start the APU. When it is online attach the GPU and switch off the APU. That's how I get mine started. 1
dectenor1 Posted July 11 Author Posted July 11 On 7/10/2025 at 2:31 AM, chumley said: Start the batteries and use them to start the APU. When it is online attach the GPU and switch off the APU. That's how I get mine started. You can actually click the button next to the lower screens to just display the OIS on those, and then connect the GPU.
dectenor1 Posted July 13 Author Posted July 13 (edited) VNAV seriously needs a proper look at and an update dedicated to it. There are so many issues relating to how the aircraft targets constraints and speeds. How it displays these targets and predictions, how the F-PLN page target speeds, relate to the PERF pages and indications on the PFD, ND, like the level - off arrow, like magenta and orange dots around waypoints etc., etc. Level-Off Arrow in OP DES for example, it just most off the time in the completely wrong place on the ND. Makes doing continuous descents so much harder than it needs to be for example. How it calculates descents etc. Like here, as can be seen, there are no constraints before EGNUG, but the aircraft is planning to be at EGNUG, 3000ft too high. It should simply start the descent sooner to meet this constraint. There are no speed, or altitude restrictions that mean it can't do this. It should simply start the descent sooner to make this constraint. Edited July 13 by dectenor1 1
dectenor1 Posted July 13 Author Posted July 13 Another regression with v1.1.1 is the LDG INHIBIT ECAM memo that comes up whilst taxiing after landing. Seems to be related to the brakes somehow.
foliainfx Posted July 13 Posted July 13 6 hours ago, dectenor1 said: Another regression with v1.1.1 is the LDG INHIBIT ECAM memo that comes up whilst taxiing after landing. Seems to be related to the brakes somehow. How long after taxiing? The message should stay 1 minute after reaching 80kts.
Matthias0412 Posted July 13 Posted July 13 It's getting realy frustrating now... they release fix after fix, but essential bugs have not been addressed for many updates! 2
Wilford Posted July 13 Posted July 13 (edited) Of all the bugs, this is probably the most annoying one and unacceptable for such a high priced product. "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."dectenor1 Edited July 13 by Wilford
Swisspilot1986 Posted July 14 Posted July 14 Luckily for us there are no major implementation anymore. The ULR and HUD are released. Despite IniBuilds will concentrate on other products that involve less frequent updates I hope it will give chance to fix existing reports.
CS-TMT Posted July 14 Posted July 14 I don't know if it is a bug specific to this approach, but I tried twice the RNP-Y for VNKT runway 02 and for the aircraft to go below 7500ft (the FAP altitude constraint) I have to manually do an open descent to 4600ft even though I have the APPR armed (and shown in blue on the PFD). Only then it will capture the slope when reaching it. Tried it twice. Same behaviour both times. Plus, about 1h ago, when departing VNKT02 on DARKE1C, after overflying KTM VOR, when I was supposed to go direct to DARKE, although it was shown correctly as next waypoint on the ND, the aircraft started turning southbound to HDG 202 (the heading of runway 20).
dectenor1 Posted July 14 Author Posted July 14 On 7/13/2025 at 8:37 AM, foliainfx said: How long after taxiing? The message should stay 1 minute after reaching 80kts. Yeah beyond that, was still appearing and disappearing as I reached the gate, which was well after 1 minute.
Eddie Posted July 15 Posted July 15 Hello, We've been tracking this thread as @dectenor1 had previously messaged me regarding it. I only now noticed it had not been marked as LOGGED. We've been reading and noting everything said here and I appreciate the effort from everyone. 1 EddieCommunity Manager IniBuilds Ltd. | inibuilds.com
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now