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

I believe you misread him there Chris!

ASN is now compatible with 3.2 in open beta: http://www.hifisimtech.com/forums/showthread.php?5785-ASN-for-P3D-SP4-1-with-P3D-v3-2-compatibility-update-OPEN-BETA

Jason, I was seeing the same results as you last night testing 3.2 when turning off SGSS altogether. I run native 1080p on a 42inch monitor so AA is very important in my case. I decided to give DSR a try and I have never been happier with my setup! If you go to the Nvidia control panel, under global settings, turn on DSR to 2.0x and default smoothness of 33%. Then launch P3D, and under the resolution setting you will now see a higher maximum resolution to select (being made available by DSR). I left my P3D settings at 16xAF, 8xMSAA. My AA is as good or better than when using 4xSGSS and 4x(or 8x)MSAA, and most importantly, when flying in heavy clouds etc. where 4xSGSS would result in stutters/fps loss on my GTX780 6GB (and pretty much any other card) I now do not suffer from any loss in performance. Give it a try!

Rich, We are speaking about the same issue, which first appeared in version 3.0. On my end, the issue was resolved by the 3.1 update. Remember, this was not a PMDG problem and LM were made aware of the issue by their beta team and other users and I a assume also PMDG themselves during 3.1 development/testing. I have flown 200+ hours in the PMDG since updating to 3.1 and as most of of my flights are 12+ hours, I often launch in daylight and transition into the night. In 3.0 the lights would not have illuminated the ground following a natural transition into darkness (unless I launched in the dark and then changed to the intended daylight time). As of 3.1, and continuing now in 3.2 the lights work just like they always were intended to. Dan Downs, confirming problem resolved. http://www.avsim.com/topic/475787-p3d-v3-landing-lights-not-illuminating-ground/?p=3350077 and Kyle Rodgers also confirming that 3.1 resolved the problem. http://www.avsim.com/topic/475787-p3d-v3-landing-lights-not-illuminating-ground/?p=3367502

That was already fixed in 3.1!

Apologies Dan, I should have been more clear. I meant that the first P3D launch will crash due the aforementioned bglmanx.dll. The following launch will succeed. However, after flying and quitting the sim, the next launch will once again fail. Essentially only every other launch is successful. I would not be surprised if by the end of the week couatl has been updated for 3.2 support.

Kyle, are you aware of VpCorrection? A fellow PMDG user (active on this forum) wrote a small and genius .dll that can be turned on and off while flying. It entirely prevents the viewpoint shift from happening. Only downside being that it also disables EZdok for the time being. I simply activate it at pushback, and disable it sometime in the climbout, once again reverting back to normal EZdok use. Like that taxiing out, and taking off are free of the terrible viewpoint shift. I typically enabled it once again when below 10k or calling for the approach checklist, and disable again once approaching the stand/gate. When VpC was enabled, I would pan around as necessary using the default space bar + mouse combo. Made a huge difference in FSX and P3D 3, 3.1 for me! Shoot me a PM if you would like me to put you in touch with the developer.

1. Why are either of your crossfeed valves set to OPEN at any point? This is not required under any point during normal operation of the B777 (assuming no failures etc). 2. You mentioned real weather: Are you requesting/loading accurate en-route wind/temp data and descent winds? 3. How are you determining the fuel figure which you believe to be sufficient for the flight? (Specifically, the TOTAL FUEL/RAMP FUEL figure which will see you arriving with more than the 'reserve fuel' figure entered on the PERF INIT page). Remember the data the FMC outputs is only as accurate as the data that was inputted. Based on the ZFW/TOTAL FUEL/WIND (or lack thereof)/RESERVE FUEL, it is currently telling you that you will be arriving with insufficient fuel. There are various other entries or lack thereof which could be resulting in a incorrect fuel at destination calculation (prediction). If you plan 3-4 step climbs on a long haul and yet your FMC does not have a single populated step climb, it will be making a significantly less optimistic fuel at destination prediction than whatever you used to plan the flight and arrive at a required takeoff fuel figure.

What is going wrong is that the frequency set for the ILS28 at EIDW in the AFCAD (I assume default EIDW scenery) is outdated! Looking at my default EIDW in P3D 3.2, I can see that the stock ILS28 frequency is 108.90 (Same default AFCAD if you are using FSX). Why is your PMDG777 unable to tune that LOC/GP? You are using the latest AIRAC 1603 (always a good thing!), However sometime in the past 10+ years since that default AFCAD was compiled, the frequency for ILS28 changed! In fact if you look at what your FMC is trying to auto-tune on the NAV RAD page, (based on the most current AIRAC1603 navdata) you will see it is set to tune 111.35 which is the current and correct ILS28 frequency. Problem being that the actual ILS28 in that outdated AFCAD is broadcasting on the old 108.90 and hence your FMC cannot find it. Manually tuning 108.90 om the NAV RAD page would have worked. The solution is simple, you need to update the AFCAD with the latest ILS28 frequency (The ILS10 frequency has remained unchanged). Simply set it to match what the AIRAC1603 and latest charts show the ILS28 frequency to be: 111.35. Next time you approach, your PMDG777 will actually be able to tune into the frequency it is looking to tune into! Assuming you were using the default EIDW scenery/AFCAD I have gone ahead and made the change for you. Simply add this AFCAD to your addon scenery/ scenery folder. https://www.dropbox.com/s/ie8ovtlzudk6mtf/EIDW_ADEX_LC.BGL?dl=0 For future reference, it is always a good idea to check this before flying into default scenery. This can also happen with outdated AFCADs of far more recent and payware airports! Considering how many developers don't bother checking the current validity of LOC/ILS frequencies as they are lazy and simply leave the default ILS data in their AFCAD....

Can you please post a screenshot of your overhead panel and EICAS 'AIR' page, just before you set your first FUEL CUTOFF switch to RUN? Also post the same screenshot as soon as the EICAS is no longer showing 'APU COOLDOWN'.