PinkPony

The official RELEASE NOTES only cover a portion of the changes in each release. Smaller more technical items are omitted.

Update: They finally replied to someone’s FB comment that they hope to release the an update to address this issue on Friday.

Confirmed bug (As of the first SU3 beta up to and including the official SU3 v1.5.27). Instead of proactively working on a fix (during the SU3 beta) they made excuses and claimed it would surely resolve itself again when SU3 officially released (classic Imaginesim support…). Considering it’s only the top texture layer (taxi lines, gate outlines etc) that are not appearing anymore around Concourse B & D, west cargo and Runway 36R/18L it’s pretty evident that this is a layer conflict. A simple fix that they have yet to even acknowledge to be working on. Their support email does not respond anymore and comments are disabled on most of the FB posts. They advertise the scenery non-stop on FSElite etc. and yet fail to even provide an ounce of customer support.

Ian, try also disabling “Clip Cursor”.

Enable Multi-display Mode in the Lossless Scaling settings.

From the latest release note: http://www.prepar3d.com/latest-news/ If you regularly update your Windows 7/10 installation, you have had 4.6 for a while anyways. If you don't, then do not worry... P3D's latest client installs it for you.

Understood Michael, My last B77F flight is a few months back. 11h sector, departed at 343t. 4t short of MTOW. I dont remember seeing anything out of the ordinary with regards to fuel at destination prediction,, but I certainly believe your eyes arent lying to you either. How about we set up a controlled test scenario and compare what we are seeing on our systems. Of course keeping in mind, that I am running the latest P3D release (3.2.2), and you are running FSX SP2. 0 wind, default clear clies, identical zfw, calc fuel, weights, step climbs and so on. I will run a PFPX plan and share via google drive. Like that we can compare fuel at destination prediction on the ground, at TOC and at a given point in flight. Ill report back in 48 hours latest.

I meant to follow up on this myself quite a while back, and unfortunateky forgot to do so. As discussed previously there are various PFPX performance profiles (from different sources) available. The most commonly used are probably the -300ER and -200LR provided by the fefault PFPX installation. Followed by the far more accurate and FPPM sourced profiles by "FlyPrecisely" which among others, myself and IIRC Michael also use. Indeed there is a range of fuel burn bias when flying the PMDG 777 between flights. This is however a bias, based solely on figures outputted by PFPX. Why is it that on a DXB-DFW with a 15h36m trip time, I am requiring a 102% bias (vs. the profile default 100%), while on a subsequent DXB-DFW with a 15h and 3m trip time, the 100% cruise burn bias is spot on? Static Air Temperature or SAT. As found on PROG page 2/4..... The PFPX performance profiles for the B777 max out at a ISAequivalent of -60C SAT. The longer of my two DXB-DFW flights took place in the winter months, with a Polar routing via ABERI. The latter and more recent one, in April with a more southern routing, via the North Atlantic. The lowest SAT on the latter flight was -51C (within the PFPX performance file data range). The previous flight had a lowest SAT of -66C (requiring a temporary step down to a lower flight level, as is common on Polar routings to remain within the FCOM limitation fuel temp/time range). At -66C the B777 will of course have a higher fuel flow, due to the cooler and thus denser air. This below -60C SAT fuel flow, is entirely outside of the range of temperature/fuel flow values in the very performance files we are using in our PFPX calculations. Thus, on specific flights with OAT/SAT's outside of the PFPX aircraft performance files data range, PFPX is significantly under estimating TRIP fuel burn in its computation. A 2% error is no laughing matter with 120,000kgs of TRIP fuel... Countless comparisons using weight/speed/FL/TAT, show a fuel flow delta within .05% between PMDG's B777 and the latest FPPM. Both for the GE90-110B1L1 powered -200LR, and the GE90-115BL1 powered -300ER. As a result, the only significant error I see, is in the incomplete temperature/FL/fuel flow data range in the available PFPX profiles. The OPT/ MAX CRZ alt values are also slightly off in the available PFPX aircraft performance files. (more for some weights than others). The result being PFPX either plans for too early step climbs when the FMC reports a lower MAX crz value, or step climbs that are computed too late by PFPX. This depending on which aircraft performance file is used in PFPX (default being the worst). There is no delta between the PMDG weight/temp/MAX crz values and the FPPM values. They truly are spot on and straight out of the book! I would like to point out that after having looked at countless OFP's of a very big B777 operator, the fuel burn bias of a specific -300ER, can continuously vary from from a low 1% to over 2% within a few months. Small variations between flights being possible and automatically tracked and adjusted by the dispatch software as a result of fuel burn data downlinked via ACARS and monitored by the operator. This being a requirement of statistical based contingency fuel! As a result, I duplicated my FlyPrecisely based -200LR/-300ER PFPX profiles, and have a range of % cruise bias from a low of 99% to 102% on the -300ER/-200LR (in 1% increments). As a result, even on my longest sectors, I find myself within ~500 to 1000kg of expected TRIP burn and fuel at destination. Easily covered by planned contingency fuel. In addition this TRIP bias is also always attributable in part, to the PFPX planned vs. actual encountered wind/ISA conditions outputted by ASN. Which are of course to be expected and thus planned for to begin with!

I have seen a Dec. 2014 dated B777 customer options list. Definitely was not listed there and I doubt it was ever a official option offered by Boeing. On the other hand, Boeing is known for "if you pay for it, we will do it for you" when it comes to customer options. I am sure there was a period of time where any operator who really thought it was necessary for crew commonality, could have optioned the separate standby indicators for a absurd price. For example, later in the B747-400 production line, the taxi light became standard equipment. Two forward facing bulbs, placed on the nose gear, linked to the air/ground switch and actioned by a single switch on the overhead panel. One specific operator did not want a single remaining -400F aircraft (delivered various years after their previous -400F batch) to have this standard equipment. They paid Boeing to build/deliver it without the taxi light.A notorious penny wise and pound foolish airline, who with a subsequent -400ERF order finally came to their senses and received aircraft with taxi lights (Crews wanting them all along). Many chose the no taxi light option, (when it was the cheaper customer option), to maintain commonality with their 747 Classic fleet. Some eventually realized that Boeing had created this option for a reason (for the pilots). Using wing mounted inboard/outboard landing lights to taxi, does not make other pilots happy, specifically when facing 747's while on the ground at night.

Could you please go into more detail describing what you are seeing on tour end? Based on your vague reply, I can only draw the following possible conclusions: 1. You are not correctly replicating my method. Watch the video at 0.25 speed to better see the keystroke order. 2. You are not running the latest PMDG B777 build, let alone the one which successfuly corrected a previous reverse thrust bug (IIRC corrected with SP1d). I want to be clear, that the method in the video has worked every single time, on over 100 landings in the PMDG B777 from when I began using it. After I recorded the tutorial above, I decided to do some further testing,with the goal of finding a alternative solution to my current method. Ideally a single input or keystroke via a throttle axis or button. Knowing that F1 is a immediate "throttle cut" input, and F2 being a "throttle decrease" input (by default). In theory a sufficently large (single) throttle decrease input should result in a successful reverse thrust application. By assigning the "Throttle decr" command to one of my CH throttle quadrant buttons via FSUIPC and a -10 in the parameter field (the size of the decrease command) with "repeat when held", now results in a perfect idle reverse thrust application when the button is pressed once upon touchdown. Touchdown being verified by the speedbrake handle moving to the up position automatically (when armed). No need for anymore F1 or F2 keyboard inputs. Note you can also assign this directly via theFSX/P3D interface (no FSUIPC needed). Just select which button to link with the default F2 command, a repeat rate that gurantees sufficent throttle decrease to activate reverse thrust upon a single press of said button.

Hey Rob, Any news? I have since flown GRU-DXB, countless 1-3hour NGX flights, and DXB-ORD-DXB. All without issue as was always the case in P3D V3. I dont know if sfc /scannow or repairing the VC++ 2010 did it, but its all back to normal on my end.

Indeed N5016R was fitted with the three separate standby indicators. Why? By the time is exited the production line, the ISFD was not ready yet! It flew in this configuration throughout most of the certification period and once it was reconfigured for delivery to JAL as JA731J, it was of course fitted with the ISFD as specified. In summary, there has only ever been one temporarily non-ISFD fitted -300ER. Furthermore, various operators such as EK, UA, CX, SQ have over the past few years been replacing the separate standby indicators with the ISFD on their older -200/-200ER and -300 aircraft.

Here is my video. I apologize for the resulution, the default windows 10 virtual keyboard does not display the physical keyboard inputs. I downloaded a freeware virtual keyboard called NohBoard, which unfortunately cannot overlay when P3D is in full screen, thus I had to use P3D in windowed mode at half my normal resolution (I use 2.0x DSR in full screen). Below the P3D window you will see the F1 and F2 inputs I used. Pay particular attention to the order, refer to the EICAS to see the result. I suggest you save a scenario similar to where I began my video. Established on a ILS approach, with A/P and A/T active. Then you can keep restarting from that scenario in order to get a hang of it! I hope this helps!

This is unfortunately a result of the limitations PMDG faced with the FSX engine. The reason your assigned reverse thrust axis/inputs do not work, until a short while after touchdown is because they interfere with the SPD to IDLE when A/T is used on landing (as is normally the case on the B777). PMDG modeled this transition 100% accurately, in essence it is a behind the scenes throttle input! Hence overriding (rightly so) our assigned throttle axis/inputs until complete. Note: When A/T is not used on landing, there is no interference whatsoever as there is no automatic SPD -> IDLE transition. Although it may appear that your assigned axis/input is being overridden until nose gear touchdown, this is not the case. It is rather a few second delay as SPD to IDLE transition takes place. The only way to assure that you successfully unlock reversers upon main gear touchdown, is to enable the A/T override in the PMDG menu (as you have done before), and then when the A/T goes to IDLE as enunciated on the FMA during the flare, you press and hold down F1 and then also briefly hold down F2 once the main gears have touched down. If all you need is idle reverse, then simply let go of F2 and then F1, if you need more than idle, let go of F1 and hold F2 until you have reached you desired setting. Note: Once you have used the F1/F2 combination to unlock and transitioned to idle reverse, you can use any assigned reverse axis to further set your desired reverse thrust! (Without having to further hold F1/F2). In simple terms, F1 is forcing idle, and F2 is sending the reduce throttle input to FSX. Once unlocked, they will not re-stow again. This question still tends to pop up every once in a while, so I am going to make a short video while displaying the virtual virtual keyboard to show how I make this work every time. If anyone has any suggestions, on how to display key inputs while recording with Nvidia Shadow Play, feel free to chime in

Rob, I upgraded to Windows 10 Pro last week, and while it was a surprisingly hassle free process, my P3D 3.2.2 began crashing due to ntdll.dll etc. Twice on 2-3 hour NGX flights and two days ago on final approach after a 14hour OMDB-SBGR in the PMDG777. The NGX crashes never resulted in a Windows error report, the PMDG777 did, and ntdll.dll was the faulting module. First time I have ever suffered CTD's in P3D V3 and this made me instantly regret upgrading to Win 10 as I never had anything of the sort under Win 7. Here is what I did after: 1. I repaired/re-installed the Microsoft V C++ runtime packages. (PMDG upses VC++2010 for the NGX/B777). Not sure how relevant this one was, but I wanted to make sure i corrected anything if it had become corrupt following the Win 10 upgrade. 2. Open a command prompt (admin) by right clicking on the windows button on the task bar (bottom left), then enter sfc /scannow This will run 5-10 minutes and scan the windows components for any corrupt files. To my surprise it found quite a few and made the relevant repairs successfully. Subsequent runs confirmed there were no longer any corrupt windows files. I suspect this was caused by the Windows 10 upgrade process and may be at fault here! 3. Just in case and to play it safe with permission etc., I now set P3D to permanently run as admin (you can set this under the properties/compatibility tab). 4. I know you use FSX, and so this last step doesnt apply to you, but I went ahead and uninstalled the P3D 3.2.2 client and installed the 3.2.3 client. Supposedly the latest minor client update only addressed a license activation issue, so it may be irrelevant anyways. In any case we both suffered from the same ntdll.dll crash which I never had before upgrading to Win 10... Following these steps I successfully flew a ~14h SBGR-OMDB return, and had no issues whatsoever. I also went ahead and did a problem free TNCM-KMIA in the NGX. If I can knock out another 2 flights on each type, without issues then it is back to normal and not having to save the flight every few hours (just in case). I suggest you try step 2. first and see if what the sfc /scannow tells you. Here is