EGSC9

members
  • Content Count

    18
  • Joined

  • Last visited

Everything posted by EGSC9

  1. EGSC9

    PFPX Dark Mode

    ­čśé
  2. It is actually as fundamental as EDTO (ETOPS) or take-off speeds calculation, but ignored by most people flying flight simulators. Per legal requirements, to put is simply, you have to ensure that aircraft will be capable to operate by at least X margin (typically, 1000 feet) above terrain elevation along any point of your route (plus some width margin buffer) with one engine inoperative (for twins), given actual planned weight. If this criteria is not met, you either reduce takeoff weight to achieve it, or re-route to avoid high terrain. These requirements vary from authority to authority. You may find more about this subject by googling terms such as 'net level off altitude' and 'drift down analysis'. PFPX implementation is simple and does allow second method (full drift down analysis), but it is good enough. To manually determine compliance with this requirement you would take net level off weight chart from FPPM (for Boeing aircraft) and terrain elevation data; PFPX automates this process to a certain degree. Another area which is really missing in PFPX is oxygen profile (you have to ensure that in case of decompression, aircraft will be capable to descent to X altitude within specific time limit, considering actual terrain profile along your route).
  3. First of all, thanks for the version 2, many things been corrected and many new handy features added. I would like to ask for an easy feature request. It is good that NOTAMs can now be filtered by their relevance - time window relevant for the actual flight, however, these filtered NOTAMs are only displayed within application interface itself, not in OFP (so one would still get hundred pages in OFP for a typical pan-European flight). So the only practical use for NOTAM filtering is during flight planning, but as a pilot I would like to be able to scan relevant NOTAMs as well. Unfortunately, as I also used to do in the past, I still have to use some external service for NOTAM filtering based on their applicability and generate a document, in addition to PFPX OFP. Also, it would be nice to mark NOTAMs in OFP by their category, as in application itself (e.g. 'airspace', 'runway', 'airway'). Anyone who actually uses NOTAMs knows what a headache it is to scan through dozens of NOTAM pages, 90% of which are either irrelevant due to time applicability or some non-sense messages, easily missing among that garbage a NOTAM about closed runway for example. Please, consider these things for the next update. Thank you!
  4. EGSC9

    PFPX hotfix 1.28.9i

    FS9/2004 export changed, but flawed again. Example: N56┬░ 15' 49.00" E040┬░ 35' 58.00" exported in previous versions as N56* 15.49', E040* 35.58' (no conversion to decimal minutes) exported in this version (1.28.9i) as N56* 15.00', E040* 35.00 (decimal minutes completely omitted)
  5. EGSC9

    RF-legs

    Could someone please confirm that NavDataPro supports RF-legs for PMDG with at least adequate pseudo-waypoints? Thanks
  6. I fly various types of aircrafts, some with basic INS requiring manual coordinates entry. For various route conversions in other tools/formats I initially use .PLN route export feature (FS2004 FS9.1 format). I noticed that there were some inaccuracies in my navigation, upon further examination I discovered that they were rooted to PFPX, which really astonished me. 1. Upon export to FS2004 FS9.1 .PLN format, PFPX does not convert seconds to decimal minutes. Example below Actual point latitude N55┬░ 12' 40" (i.e N55┬░ 12.67') Converted by PFPX to FS2004 FS9.1 .PLN as N55* 12.40' - this is wrong since FS2004 PLN requires decimal minutes, not seconds VFR planner, Plan-G upon export to FS9 .PLN correctly converts the same latitude to N55* 12.67' Obviously, same about longitudes. FSX .PLN format, on the other hand indeed requires degrees, minutes and seconds (exported by PFPX correctly). 2. Wrong coordinates rounding in navlog In navlog seconds are converted to decimal minutes, but rounded incorrectly. Same latitude as above (N55┬░ 12.67') shown in navlog as N55 12.6, which is incorrect rounding for one decimal place (correct would be N55 12.7). Wrong rounding of longitudes too. Please correct these errors as this is pretty critical for navigation and in my opinion unacceptable kind of error for the kind of payware product ! I haven't checked other export formats, but I'm definitely less confident in the export feature now.
  7. EGSC9

    PFPX hotfix 1.28.9c

    From my understanding PFPX was never intended to be used in-flight (apart from actual printed OFPs), this is flight planning tool and there are still a lot of flight planning features to be added/refined.
  8. EGSC9

    PFPX hotfix 1.28.9c

    I noticed that "Ignore route charges" option has been added in route construction dialog. This feature is not documented, could you explain it's usage? It's great to see such enhancements. Also, is it possible to define runways for custom airfields (i.e. it is possible to define properties of custom airfields - entry/exit points, etc, but not actual rwys)?
  9. Although I have several issues with PFPX, there is generally no problem with route finding function, you can't really blame it here. You have to realise that PFPX, like most other planners, use math algorithms to find the shortest path between two points through a series of nodes with certain weight attached to them (like distance, time, cost, fuel - check https://en.wikipedia.org/wiki/Dijkstra's_algorithm ). These nodes are either airways, specific DCTs, oceanic tracks, etc. It is pure math to find the shortest path (distance is not always the factor, you should really use fuel, time or cost optimisation) through the network interconnected nodes. Now, when it comes to European routing, just get used to the fact that it is the most regulated airspace on the planet. You have to respect RAD restrictions and it takes time to find IFPS valid route. Whenever I plan short-hauls within France-Switzerland-Italy-Germany-Austria region, it sometimes takes me 10+ different route options with multiple level changes and up to half an hour only to find IFPS valid route and it does look weird and not economical at all, but this is regulation. Beleive me, real-world dispatchers face the same problem. Whenever you have IFPS error, do not rebuild entirely different route, sometimes it just needs different flight level, or minute leg change. Go to https://www.nm.eurocontrol.int/RAD/ , click current airac link on the left (atm AIRAC 1703 - 02 Mar 2017) and download the last file called "Annex - Pan Europe". There you lookup error code you got from IFPS and check the reason for that error, correct your route accordingly. Although using someone else's route (like through SimBrief) saves time, it is a totally flawed concept that is so engrained in FlightSim community whereby people for ages been relying on route-bank websites as there was no proper flight planning engine, like PFPX. No days are ever the same, you will encounter different weather, day-specific restrictions, etc. Routing should be prepared for specific day and specific flight.
  10. I have made a custom OFP format which shows tropopause for each waypoint and it always displays value of FL361. I know this is wrong by comparing with SIGWX charts. Could developers either correct this error or remove this feature so to not to mislead pilots/users?
  11. EGSC9

    FIR definitions

    Vallewip, yes, FIRs EETs are mainly for ATC FPL, but also for situational awareness. I can surely adjust EETs manually, but what's the point of doing this manually given we use payware flight planning system? Developers, please update FIRs!
  12. I noticed that FIR definitions are no longer valid and outdated for many parts of the world to the extent that I have to manually adjust EET/ when flying in certain regions for filing FPL in online network. Can we expect FIRs update with the next version of PFPX? Best regards
  13. EGSC9

    FIR definitions

    The following FIRs are still present in PFPX, they are now incorporated into other major FIRs: ULOL UWPP UWKD UWOO UWUU UUYW USHH USRR USUU UNOO UNBB UNIT UENN UEST UHBB UHSS UHMI UIAA Marco, here is Russian AIP, part ENR: http://www.caiga.ru/common/AirInter/validaip/aip/enr/enr2/1-enr2-1.pdf
  14. EGSC9

    FIR definitions

    For instance the following FIRs in Russia are now encompassing many neighbouring FIRs present in PFPX as separate FIRs: UWWW, USTR, UNNT, UNKL, UIII, UEEE, UHHH, ULLL. Some of these changes have taken place as long as more than 1 year ago.