Jump to content

TheFl4me

Members
  • Content Count

    26
  • Joined

  • Last visited

Community Reputation

2 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. I would appreciate it if my thread was not hijacked. This thread is starting to go off the rails and becoming hostile, I only made this post because LSZH was updated a few days ago and it seemed strange to me that parts of the airport were left outdated. I fully understand that developers can't update their sceneries everytime something changes IRL, nor that they are obliged to do so. I do not however understand why when one finally does update the scenery after a few years, one would leave certain parts outdated (We arent talking about something major like a whole new terminal etc.. were only talking about a small taxiway section and a couple stands.) This seems illogical to me.
  2. Title says it all, The new B7 and L7 taxiways were added, however taxiway E1 is still missing. Aditionally, the I stands are also still outdated. I do not know if these feature were forgotten during this update or if they were intentionally left out, so i thought it safer to point them out.
  3. TheFl4me

    MCDU Freeze bug

    @mopperle Yes I am aware the DEGES2S is not a RWY34 SID, which is why I selected RWY16 in the MCDU. I do not quite understand what your point is here. The W201 airway is infact a two-way airway. It is flown both ways IRL for most inbound flights to South Korea and western Japan from Europe (This has been confirmed by a dispatcher friend of mine for a large airline that flies that route daily, you can also confirm this yourself by simply checking out a flight tracking website like FR24 or flightaware). For some strange reason though it is marked incorrectly as a one-way airway on certain map providers (incl Navigraph). It is however marked correctly on SkyVector as a two-way airway. Trust me, I have invested a very large amount of time in investigating this bug. This isnt just a simpleone-off event that only happened in this video or a simple user/handling error. This has happened on multiple flights on completely different routes with different origins/destinations. EDIT: Regarding the SID, it would seem that simbrief somehow changed the rwy to rwy34 instead of rwy16. Be that as it may that is most definitely not the reason for this bug. Since it has occured on multiple other occasions.
  4. TheFl4me

    MCDU Freeze bug

    I built the route myself and entered it into simbrief. Simbrief then generated the .flp file using AIRAC cycle 2003. So the co rte .flp file is version 2003. If it was a simple cycle mismatch problem, then the bug should also appear when I used the navdatapro cycle in the video, since that cycle is infact an outdated cycle (the default 1913 cycle that comes pre-installed with the AS330). But as mentioned, what we are seeing is the opposite. Navadatapro seems to work fine (even though its an older cycle version) while navigraph is the one causing the issues even though navigraph and the .flp file are on the exact same cycle @mopperle
  5. TheFl4me

    MCDU Freeze bug

    Again, apologies for the bump. v1.0.0.8 was released, and in the changelog it claims that the MCDU freeze bug has been fixed. This is only partially correct @Mathijs Kok. The bug seems to be fixed with Navdatapro, but its still broken whilst using Navigraph data BUT ONLY when importing a company route that already has a STAR preselected (or maybe because the last waypoint in that route is already the approach via waypoint? just a theory). I demonstrated 4 scenarios in this video, in the following order (Video timestamps in video description): Navdatapro + no co rte = no bug (00:00) Navdatapro + insterted co rte = no bug (00:49) Navigraph + no co rte = no bug (01:57) Navigraph + insterted co rte = BUG (03:08) The 1913 airac cycle in the video is the navdatapro one, whilst the 2003 is the navigraph one. The company route I inserted here is a fully manually made rte, euro control validated with 2003 etc... LSZH DEGE2S DEGES Z2 UMVEG DCT TOVKA DCT MEBAN DCT BIGLU DCT RATIN N869 BD P865 GINOM A308 SND A575 UKDUM W201 UNSEK A326 DONVO G597 LANAT Y597 MIHOU Y361 SAEKI Y36 ALISA ALISAC RJBB I have added the .flp file to this post if you want to try for yourself. I must once again point out that this does not only happen on this specific route, it happens anytime I have to manually select a approach via waypoint whilst using navigraph data and having inserted a co rte. LSZHRJBB01.flp
  6. Interesting, Interesting, I didnt realize that was out since I cant seem to find any forum update mentioning the new release.
  7. Sorry, forgot to mention that @DaveCT2003 A330 v1.0.0.6
  8. 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.
  9. @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...
  10. 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
  11. 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.
  12. 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
  13. 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
  14. 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
  15. 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.
×
×
  • Create New...