!! Windows 7 no longer supported !!

As Microsoft will stop supporting Windows 7 on Jan 20th we will be unable to test any of our
products on that platform. It may work, or it may not, but no guarantees from our side. 

Jump to content

TheFl4me

members
  • Content Count

    21
  • Joined

  • Last visited

Community Reputation

0 Neutral

About TheFl4me

  • Rank
    Flight Student - Groundwork

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Interesting, Interesting, I didnt realize that was out since I cant seem to find any forum update mentioning the new release.
  2. Sorry, forgot to mention that @DaveCT2003 A330 v1.0.0.6
  3. I have noticed that if you dial in a new altitude into the MCP before having reached the THR ACCEL HEIGHT the aircraft will switch to CLB/OP CLB mode. Example LSZH VEBIT3S departure: - Initial climb 5000ft - NADP1 so THR RED at 2900 and ACCEL at 4500ft (MSL) (LSZH elev is 1400ft) I am currently passing 3500ft (MSL) and ATC gives me a clearance to further climb to FL120. If i dial in (DIAL, NOT PRESS/PULL) FL120 before having reached the accel alt of 4500ft (MSL) the aircraft will switch to CLB/OP CLB as if I had pressed/pulled the ALT knob, thereby putting the speed bug at 250kts and accelerating too early. This happens on all departures/airports.
  4. @Secondator It was a one off (so far) It may have to do with the atmospheric pressure changes etc that always happen during CRZ, causing small variations in the indicated altitude and the plane thereby recapturing the CRZ ALT. Its been a few weeks but I think on that particular flight it was happening more than on others... Maybe at some point it just "broke it"? idk...
  5. Hello @Secondator, FPL-DLH438-IS -A333/H-SDE3GHIJ2J3J5M1RVWXY/LB2D1 -EDDF1300 -N0483F340 OBOKA2W OBOKA Z28 DIBIR DCT GODOS P1 ROLUM P13 ASKAM L7 SUM DCT RIXUN/M083F340 DCT 6510N/M082F360 DCT 6820N DCT 7030N DCT 7240N DCT 7350N DCT 7360N DCT MEDPA/N0460F360 DCT 7178N/N0459F380 DCT 6888N DCT 6494N DCT 6096N DCT 5597N DCT LIVBI DCT ABR DCT OBH DCT KK51C DCT IRW DCT IBAKE VKTRY2 -KDFW1109 KIAH -PBN/A1B1C1D1O1S2 DOF/200110 REG/DAIKO EET/EDVV0011 EHAA0022 EGTT0043 EGPX0059 BIRD0159 BGGL0330 CZEG0522 CZWG0734 KZMP0849 KZKC1007 KZFW1044 OPR/DLH PER/D RALT/BGSF CYYQ RMK/TCAS Theres all the flightplan info youll ever need ;). Yes the step climbs and climbs etc were all fully in managed mode, I also attempted 1 step climb in open climb mode to test the bug but the result was the same upon reaching the new CRZ LVL
  6. Pretty simple bug, For the entirety of todays 11h flight, the white box around "ALT CRZ" on the PFD did not go away. Even initiating step climbs (so temporarily changing to CLB mode) did not fix the issue, the white box remained as soon as it went back to ALT CRZ.
  7. Hi @Hanse, My point was not to compare Aerosoft to Fslabs, or insinuate that one is better than the other in any way. I was simply citing Fslabs as a proof of concept for a feature that I believe should be implemented into the aerosoft a330 (directly entering the ZFW). I could have just as well cited the quality wings 787 as an example (similar price range and quality to the 330, they too allow the user to enter the ZFW weight directly. I chose to use Fslabs as an example, not because of the price range or quality of the product, but because it has many similarities with your product (Airbus aircraft, similar loading process with both you and fslabs utilizing GSX etc...). I dont think that this is too much to ask for a product of this price range (or did I misunderstand your previous message?). And it is definitely possible since multiple other developers (not just products with a price range of >100€) offer this aswell, so its less of a question of being able to, but rather more of a question being willing too.. Basically it all boils down to one question. Is aerosoft willing to add a feature to enter the zfw directly as a alternative loading option to the current loading process? Regards, Tristan
  8. Hi @Hanse, Thank you for your reply. It is good to know that this is infact a bug with the fuel planner, however it is imo still of no use to me since it does not consider the Cost Index. (Estimating the fuel consumption based on distance, winds and ALT is nice and all, however not considering the actual speed or rather thrust setting will make the prediction severly inaccurate (we both know there can be up to a 5t fuel difference between the lowest and highest cost index). You are correct about the fact that simbrief does not calculate the CG. Here is my suggestion which other aircraft developers seems to do: Lets take FSLabs as an example (because they are the only other good airbus developer and fully integrated GSX). When loading my fslabs I can choose to either enter a ZFW value, which if I do fslabs will then (I assume) randomize the pax/cargo ratio to fit that ZFW, and thereby also calulcate the TOW and ZFW CG. I (and fslabs) realize that this solution is liked but also disliked by many, so they ALSO offer the alternative option of manually setting the pax numbers and cargo weight. Now obviously once the CG has been calculated the takeoff trim can be seen by simply looking at the trim wheel and seeing what setting matches which CG. The point is that they offer both options. Personally, I do not care how many pax/cargo I have as long as my actual ZFW matches the ZFW on my OFP, but I fully understand that this opinion is not shared by everybody. What you explained (adjusting the sliders to get my ZFW) is what I am doing at this point, however I still would rather have the option that the system does this for me. I think I didn't explain myself properly when talking about simbrief, I still very much need simbrief. The only feature I do not use it for is the auto-generate route feature. Every other feature (such as generating an OFP, Cost index based on WX and approx flight time, ETOPS, NOTAMS etc....) I still of great value to me and obviously not something that can be replaced so easily. Regards, Tristan
  9. Hello @Hanse, I use simbrief as a flight planning tool, or rather I only use it as a fuel/perf calculation tool since I make the routes fully manually (eurocontrol validated etc...). As with every other aircraft, upon loading it into the sim I enter the numbers from my OFP into the MCDU directly. Based on my experience over the past years, I have come to the conclusion that simbrief includes the checked luggage from a passenger into the weight per pax value. (After doing some calculations it would seem that simbrief assumes the weight of 1 pax = 100-120kg), which explains why it then spits out such a low value for actual cargo since it already included it in the pax weight (wether this is the correct way to do this is up for debate, but fact of the matter is this is how it is currently calculated). I accounted for this my adjsuting the pax weight in the setup page on the MCDU. I do not use the Aerosoft fuel planner because I find it to be severely innacurate in terms of actual fuel calculation. (Take your screenshot for instance, it is suggesting 48t of fuel for a flight which yesterday required almost 60t, 55t if the aicraft had had the correct ZFW). Or for the flight im doing today it suggested 20t less fuel than simbrief did (I triple checked the wind value altn distance etc...). Its also missing some key data input values to estimate the fuel such as cost index and step climbs. I have attached yesterdays OFP of that flight in this post incase you're interested. Back to the problem at hand: The loadsheet is marked red because after noticing the problem (in the last hour of the flight) I tried to fiddle around with the mcdu. and since I never used the fuel planner it had no data to import. I started a flight after reading your post and indeed the problem for the incorrect ZFW seemed to have been the too low cargo value. I assume the MCDU didnt input the new value and kept the whatever the actual cargo weight was upon starting the sim (although it never blinked green yesterday). I have several problems with this though: I cannot comprehend why one would add a minimum cargo value? This imo is just asking for problems to happen... If there is a minimum cargo value, then entering a value below that should not be possible, and should instead be met with an error message such as "out of range" or something to avoid all this confusion. Why is it not an option to directly enter the ZFW/CG like in every other aircraft? Why all this jumping around? Dont get me wrong It might be a nice feature for some people, but it should not be the only way of being able to load the aircraft. Kind Regards, - Tristan EDDFKSEA_PDF_06Jan20.pdf
  10. The Value(s) indicated on the A330 MCDU, SD and E/WD make no sense. FOB = 4800kg GW = 175000kg indicated ZFW = 161500kg GW - FOB = ZFW right? not in this case. 175000kg - 4800kg = 170200kg 170200 - 161500 = 8700kg So the actual ZFW appears to be 8700kg heavier than the one i set upon loading the aircraft? No wonder I am arriving at my destination with 4t less fuel than predicted (10h flight). Am I missing something here? EDIT: Aerosoft A330 v1.0.0.6 and whatever the latest P3D4 v4.5 build is.
  11. Greetings, There seems to be an issue with the HDG alignment on the ND. This was on a flight a few days ago with v1.0.0.5 of the Aerosoft A330.
  12. TheFl4me

    MCDU Freeze bug

    Apologies for the bump, This issue is still a thing with v1.0.0.6 I am unable to land at LSZH with the ILS14 approach via RILAX. I dont know if this issue was ment to be fixed in the versions following 1.0.0.2, but I thought id mention it anyways just incase.
  13. Hello @Secondator, This was the route: LSZH/16 VEBI3S VEBIT T50 ROTOS UZ669 VADAR DCT NINTU UN869 MEBAK UP860 TIS UN460 SIVIR DCT 4715N DCT 4820N DCT 5130N DCT 5240N DCT 5150N DCT ALLRY DCT 5055N DCT 4862N DCT TOPPS DCT ENE PARCH3 KJFK/ILS31R The strange thing is that this appears to be a one-off event, or rather it hasnt happend since... I fly the VEBIT3S departure very often and this has only ever happend this once. Actually now that I think about it, I just remembered that on climb-out my COATL crashed and wanted me to restart it (which I did). Maybe this is linked? EDIT: I cannot recall if the speed was already bugged before or after the COATL crash...
  14. During this flight my managed speed seems to be completely broken. I noticed something was wrong when on initial climb it was at 230 kts (Green dot speed). Once I passed FL280-ish (Airspeed to Mach transition) it worked correctly again. Once I reach ALT CRZ however it completely broke again and wanted me to go to 120kts (I assume this is approach speed) and remained there. If I do a step climb (so briefly enter CLB mode) the managed speed is the correct value again, but as soon as I change back to ALT CRZ mode (new FL reached) it goes back to 120kts. Here is a short video example: EDIT: Trying to change the Cost Index value has no effect on the bug. I am using Aerosoft A330 v1.0.0.2
  15. TheFl4me

    MCDU Freeze bug

    I have tried it with the Navdatapro data in the configurator and it was the same result (MCDU freeze) @Mathijs Kok I have also discovered that this happens everytime I manually select a "appr via" waypoint, not just at ZSPD. I tried flying into LSZH ILS14 coming from the waypoint RILAX, when coming from RILAX you do not fly a STAR insetad you go straight from RILAX to the approach (its a IAF). So I had to manually select "appr via RILAX" and everything froze again.
×
×
  • Create New...