Jump to content

Will C

  • Posts

  • Joined

  • Last visited

About Will C

Recent Profile Visitors

884 profile views

Will C's Achievements


Contributor (5/14)

  • Reacting Well Rare
  • Dedicated Rare
  • First Post Rare
  • Collaborator Rare
  • Conversation Starter Rare

Recent Badges



  1. My two cents are that I would add this in the Aircraft Editor, since MELs are specific to the aircraft. Enter it in the Aircraft Editor when the item is deferred or INOP, and then clear it on the Aircraft Editor when the item get fixed. 🙂 As Stephen says, not every OFP is configured to display the aircraft remarks, so you'll need to be using an OFP that does.
  2. Well, it's not really what I'm trying to do in PFPX, rather what I'm trying to get the OFP template to display. The problem was that the displayed format was incorrect unless an alternate was supplied. However, using the fix above, the template now prints with the correct layout, regardless of whether an alternate is used or not.
  3. Hello Alicia, I don't know any of the answers to your questions, but I wanted to wish your brother all the best, and say thank you for sharing his art! Will
  4. Just added in the downloads section. https://forum.aerosoft.com/index.php?/files/file/6484-ofp-template-optimized-for-747-400/
  5. Version 1.0.2


    Just for fun, here is an OFP template for PFPX that is optimized for the 747-400. (Specifically, it is optimized for the PSX simulator, but you could use it with any other platform. Also, I guess you could use it for any other aircraft, but that would be at your own risk.) Why create a fictitious OFP template? If you've been around airline ops for long, you'll have noticed that most OFPs look like they are stuck in the 1960's in terms of layout. Data was expensive those days, and printers weren't very robust -- just simple characters, often dot matrix, on fan-folded perforated paper. Fast forward to now, and we live in the world of paperless cockpits and electronic flight bags, so the whole concept of a paper OFP may be anachronistic. Still, maybe there's room in the world for a PFPX-style paper OFP that doesn't skimp too much on the data. Meaning, we don't have to live with all the arcane abbreviations. It could be more user friendly, in other words. So here is what a more user-friendly OFP might look like. In addition to the OFP template itself, there are two examples here, so you can see what I'm talking about. Example number 1 (called Sample-Simple.pdf) is a simple flight plan: just the basics: origin, destination, and one alternate. No remarks, and no bells and whistles. Example number 2 (called Sample-Complex.pdf) is a more complex example, with origin, destination, two alternates, re-dispatch point, re-dispatch alternate, speed restriction, and EDTO ops. Plus some sample text in all the possible remark fields. Both of these are created with WJC-OFP.txt, the template itself. Just put it in your folder with your other PFPX Flightplan Templates and you are good to go. Any needed fields (re-dispatch, EDTO, remarks, etc.) will automatically make it to the OFP if you enter the data into PFPX. I'll let them speak for themselves generally. But if you look at Sample-Complex, you'll see it starts with the airline and flight info -- I just picked something random for the example; whatever you pick will make it to the OFP. Then comes a summary of all the relevant airports. After that are the flight plan remarks and the messages to crew (if applicable). You'll note a convention here: every section is introduced with its name in boldface, underneath a dashed line. Anytime you see the full-width dashed line, you're dealing with a new section. Under Flight Summary, I picked a fictitious dispatcher. PFPX as you know has a way to pick the user as the dispatcher; I removed that because I want to be the captain, and it didn't make sense to have both the captain and the dispatcher be the same person. If you want to be the dispatcher, just change this line back to the PFPX OFP default. Load Summary lets you write in the CG that you get from your load sheet. Fuel Upload lets you check that the loaded fuel (from your fueler's report) matches what you expect to have on board. Optimized for liters and pounds, sorry about that. If you want to change to other units that's fine, just put in the correct conversion factor. (The PSX fueler's report gives the fuel density in kg/L, hence this default. Note that the first section called "Onboard" represents the fuel on the aircraft prior to fueling. Fuel Summary gives you the FMC reserves on the right. The performance adjustments are in (more) plain English. The EDTO Critical Fuel Summary is more readable here than these things usually are. Not much to say until the Navigation Log, where I simplified the data. We can assume that the FMC stores the wind data, which is interpolated anyway from the data at the bottom of the OFP, so I don't feel obligated to reproduce it here. The Lat/Long Coordinates format is exactly what you would enter into the FMC if you need to do that (like creating fixes for switchover points between nearest suitable airports, or FIR boundaries). Just type what you see directly into the FMC. The two areas for doing some math are on the far right: Time, and Fuel. Write in your actual elapsed time and your fuel on board at each waypoint (or just once every 250 miles or so), and see how you're doing with your schedule and predicted burn. The Oceanic Entry table is optimized for the 744, like everything else. Things like "ANP" and "VTK ERR" will be familiar to users of the 744 FMC. You can see a speed restriction before 3230W that is lifted after 50S00. And really, that's about it. In sum, the advantages are that this OFP is more readable than most. The disadvantages are that it's entirely fictitious (and I know simmers usually gravitate towards "maximum realism" so I can understand any aversion to a fictitious format). Also as I said it's optimized for the Boeing 747-400, and the fuel upload section is even more specifically optimized for PSX. Gratitude and credit to the creators of the generic PFPX OFP template, which was the parent for this one. Thanks also to Stephen Cooke who has been generous in answering my questions on the support forum. Thanks for reading this far! Comments and feedback are welcome.
  6. Hello Stephen and all, For the route between the redispatch airport and the redispatch alternate, we have the value <&RedispatchAltnGridMORA>. Is there an equivalent for the stretch between the redispatch point and the redispatch airport? I've tried a few permutations but nothing seems to work. If there is one, I obviously haven't stumbled upon it yet. Thanks.
  7. Okay, it's working now. The secret is to enclose the whole thing in <&RedispatchAlternate>. It looks like this: <&RedispatchAlternate_Begin> ... insert text header here ... <&RedispatchAlternateNavLog_Begin> <&RedispatchAlternateNavLog_End> <&RedispatchAlternate_End>
  8. Thanks for the speedy reply. This works if there is a redispatch alternate, but I'm having a problem if "Isolated" is selected and there is no redispatch alternate. It seems this section is called and sent to the OFP, even if redispatch alternate is undefined. Is that my error? In other words, whatever is contained within <&RedispatchAlternateNavLog_Begin> <&RedispatchAlternateNavLog_End> ...is still being sent to the OFP, even when <&RedispatchAltn> is blank.
  9. Hi all, Sorry if this has been asked before. I searched the forum and couldn't find anything. I'm looking for a way to create a NavLog on the OFP from the redispatch destination airport to its alternate. I can find the distance, fuel burn, time, and ATC route from the redispatch destination to its alternate, but I can't find tags to delimit a NavLog section. Obviously you can make a NavLog from the redispatch point to the redispatch destination with <&RedispatchNavLog_Begin> <&RedispatchNavLog_End> so I was hoping for something analogous, like: <&RedispatchAltnNavLog_Begin> <&RedispatchAltnNavLog_End> ...but it doesn't seem to exist. Is making this NavLog a possibility, or just something that PFPX doesn't support? Thanks, everyone.
  10. Hello all, Is there a way to exclude an entire country, or do you have to exclude each of the country's FIRs individually? Thanks.
  11. Mine only has files that go back to the last time I used PFPX (a week ago), 16.6 Mb in total. Just for what that's worth. But thanks for the tip, I'll check it from time to time.
  12. Never mind, I think I can answer my own question. The ISA deviation isn't given so that you can change your flight while enroute, instead it's given so that you can feed it into your FMC (or equivalent) before you take off. PFPX will calculate the performance according to given parameters, but for your FMC to calculate performance, you need to pass those same parameters to the FMC. Hence the OFP includes wind and temperature data. Obviously most FMCs get their flight plan data downloaded through something like ACARS, but you could still enter everything manually, and if you do enter all the data manually, then you'd need to enter the weather manually too, and that includes the temperature at the flight planned altitude.
  13. Hi all, I'm trying to learn more about flight operations. What is the relevance of including the ISA deviation on each leg in the OFP? (I'm asking because some of the OFP templates I've been looking at have the ISA deviation listed at each waypoint in the Navigation Log.) Prior to departure, I'm aware that the temperature at various altitudes is important for performance calculations, so PFPX certainly takes it into consideration. But once the flight has been dispatched, I don't see the advantage of putting the ISA deviation on every leg of the OFP. It would seem to only be relevant if performance numbers were varying from predicted. (If the performance numbers were spot-on, then I doubt a flight crew would ask for a different altitude just because the OFP's temperature was two degrees warmer that the SAT measured by the aircraft.) But assume the performance is off a bit, the aircraft is using more fuel than predicted, so you want to find a more economical altitude. That would usually depend on the winds more than the temperature, but let's say for the sake of argument that we're in completely still air. Specific fuel consumption drops as temperature drops, so you'd want to climb higher if able, and the only thing arguing against a higher altitude (remember we're disregarding winds here) is a temperature inversion or else the plateau you see at the tropopause. But giving the ISA deviation for a particular waypoint doesn't rule in or rule out a temperature inversion, and the ISA is corrected for altitude, so the deviation alone doesn't tell you where the tropopause begins. Another argument for the ISA deviation might be that you could tell if your flight plan is crossing isotherms. Fine, that may be interesting information to have, but PFPX has already calculated the optimum route, and besides, the ISA deviation is only given on along-route waypoints, not throughout the atmosphere, so it's not like the pilots could use the ISA deviation information on the OFP to pick a parallel track that has better performance. What am I missing? How might knowing each waypoint's ISA deviation influence operations once airborne? Thanks.
  14. Hi Stephen, Thanks for your help but I think we may be able to consider this closed. I read more posts by searching the forum under "Not Responding" and I found a thread where a user was reporting a different problem that led to seeing "Not Responding," but what caught my attention was the fact that he said the flag would disappear after a while. So I decided to wait it out. Here's what I found: PFPX wasn't getting stuck in an infinite loop, it was just taking a long time to come back to life. I started a flight plan from KORD to VNKT, using the correct UTC date, and put in the bare minimum data to compute the flight, and then pressed "Compute" and waited... Sure enough, after about 15 seconds I saw "Not Responding" but after just over a minute, PFPX came back to life and computed the flight. When I saw "Not Responding" I assumed it was stuck for good, but that's not the case. I ran exactly the same test using today's date in the computer, which was yesterday in UTC. This time, I did not see "Not Responding," and the flight computed after about 20 seconds. So here are my takeaways: (A) My problem was that I wasn't waiting long enough. (B) Computing a flight with the correct UTC date takes significantly longer. (More weather data available to parse?) (C) Seeing "Not Responding" doesn't mean PFPX won't reanimate itself if you're sufficiently patient.
  15. I'm having trouble computing flights when the departure date on my computer doesn't match the UTC date. For example, I was sitting at my computer at 20:00 tonight (Feb 1) to plan a flight that will leave in an hour (21:00 on Feb 1). However, we are UTC-6 here, so I'm doing my flight planning at 2:00 UTC on Feb 2, and planning a flight that will leave at 3:00 UTC on Feb 2. Since my computer is on Feb 1, but the departure date is Feb 2 (UTC), I get issues... Setting Feb 2 as the departure date leads to PFPX locking and saying "Not responding," and I have to shut it down and restart. But if I leave everything about the flight the same and change the departure date to Feb 1, then the flight computes, but now the weather forecasts don't synch because Feb 1 is the correct (local) date but already yesterday in UTC. Has this been seen before? Anything I'm doing to cause this problem, and anything I can do to fix it? Thanks.
  • Create New...