dingerbell100

Members
  • Content count

    4
  • Joined

  • Last visited

Community Reputation

1 Neutral

About dingerbell100

  • Rank
    Ramp Agent

Recent Profile Visitors

718 profile views
  1. Judith, Many thanks. Stephen
  2. Dear Christian & Team. I was wondering if you could consider a further fixed format Wind Data Block format as I have illustrated below (which is in real world use) which would 'lock in' the FLs shown & the DES Winds as shown. I am already using the <&WindData[2]:65> format to (with character setting) achieve something similar; but I was wondering if you could 'fix' or 'SET. the output to ALWAYS display the WIND/TEMP at the flight levels as I have shown? Kind Regards Stephen Bell PFPX Beta Test Team
  3. I am hoping that two more Extended Range EROPS Fields can be added; I am working from template rev 12 & have finished a Kalitta (CKS) OFP albeit bar 2 EROPS entries which PFPX cannot yet parse ... 1. Aircraft Weight at the ETP - PFPX must know this because it knows the ZFW & it is already able to calculate the fuel overhead the ETP, fuel on arrival if a diversion is commenced & if extra fuel is required. 2. ISA Deviation at the ETP - PFPX must know this because it is able to parse this information into the NAV LOG. Looking forward to some input, then I can upload the finished template. Kind Regards Steve Bell
  4. I too have some disappointing problems with this scenery. From a user stand point I find it very frustrating that developers seem to create products 'as if in isolation' from any other addon enhancement & it is not until the user out in the real world has parted with his or her hard earned cash (no matter how small) that issues that should have been flattened out (pun intended) in the development (before) release to market phase are discovered. Firstly my system then: p3D, ftx Global Only (with trees & Vector Road Lights), ftx Vector (with almost all sub options unticked & Arpt Elevation Corrections (AEC) run where required), FS Global Mesh. Please do not simply blame ftx or FS Global Mesh. I have hundreds (literally) of scenery entries on my scenery cfg - many from small independent developers which have integrated perfectly with all of these products so there is no reason why this product should not either. Issues. 1. There is a clear elevation issue present on the airport itself on my system - ftx Vector AEC did not pick up an issue with this airport. Some underlying mesh is clearly appearing through the scenery. 2. In addition the AFCAD which comes with the product has an incorrect airport elevation above sea level which should be 94 feet. The AFCAD has it set to 88 feet (a difference of about 6 feet which, strangely enough is about the same distance that the aircraft in the pictures is floating above the tarmac!) 3. The NDB LON has an associated Marker - this was removed some time ago. 4. The glidepath antenna for the ILS for RWY10 is not correctly harmonised to the PAPI (none ever are on payware scenery). The DME antenna is also in an incorrect position. With the glidepath antenna misplaced you will not see a correct PAPI sight picture & end up low on finals. The DME will also not provide the associated correct DME/height/altitude check. I have provided an image of where they should be placed can provide the exact co ordinates if required. I often wonder at all of the effort that goes into making airport sceneries only to find that the NAVAIDs to guide you into the detailed scenery often let you down, lets face it most of us don't fly into most sceneries we buy in a trike, Cessna 152 or an F22, we'd rather choose a large 'tube liner' & run it by the numbers. Some work is needed to make what could be a fantastic project useable. Kind Regards Stephen Bell The AFCAD, in particular the ADF & glidepath in relation to the PAPI & DME: