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 whol
  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. @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
  4. 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 navigrap
  5. 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
  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 puttin
  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
  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 similar
  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 s
  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),
  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...