As more and more add-ons will be ready for P3D v4, today, Robert Randazzo – CEO of PMDG, is sharing with us some technical know-hows, with reasons behind, when you install the add-ons on P3Dv4.
With the advent of P3D v4, many of us are breathing a sigh of relief that we can finally get back to flying full flights without the risk of the machine running out of memory during the final approach phase of flight. As hard as it is to believe, there are a whole generation of simmers who have never had this level of freedom- but those of us who have been at this since the early 80s can tell you that we are finally back to the good old days!
With that, I think it is important to have a brief discussion of basic survival skills- because our support team is beginning to see some really wild stuff taking place with Prepar3D v4- and nearly all of it is “user induced.” We really want you to avoid these pitfalls so that you can enjoy the new, stable, smooth simulation without having to waste time sorting out “what screwed up my sim now?”
THINGS YOU MUST STOP AND CONSIDER:
• Prepar3D v4 is stable. It is probably one of the more stable simulation releases we have seen in years.
• Prepar3D v4 is not v3. It is not FSX. It is not FSX-SE. (And I know how XPL users hate being left out, so no, it isn’t XPL either)
With those things, considered- here are some rules to live by:
• Do NOT install aircraft, scenery, utilities into Prepar3D v4 that were not designed using the Prepar3D v4 SDK. (Re-read that sentence it is important!)
• Do NOT force Prepar3D v4 to utilize scenery that you previously had installed for Prepar3D v3, FSX, FSX-SE (or yes… XPL!)
• Do NOT use utilities designed to allow you to “unify” your installations by feeding non-Prepar3D v4 scenery/utilities into Prepar3D v4.
The most important piece of knowledge you can have to maintain stability of Prepar3D v4:
Before you install ANYTHING into Prepar3D v4, you should take the time to research whether the developer merely adjusted their installer to account for Prepar3D v4, or whether the developer actually took the time to re-export BOTH the code elements AND the model elements of a product using the developer/SDK tools that were provided by Lockheed Martin for use with Prepar3D v4.
This sounds rather persnickety- but if you follow the guidance above- you will have a largely problem free experience with Prepar3D v4. If you would like to know more information on the how and why of these recommendations, please continue reading… Otherwise, simply follow the above guidance and you should be good-to-go!
After a few thousand man hours working with, developing for and providing technical support to the Prepar3D v4 platform- we have learned some things that we boiled down to provide the guidance above. These things are as follows:
• Lockheed Martin has provided guidance to developers via their Software Developers Kit (SDK, for short) that explains very specifically that all code elements and modeling elements used within Prepar3D v4 should be exported using the SDK tools that ship with Prepar3D. This means that simply moving an FSX/Prepar3D v3 scenery into Prepar3D v4 will put your simulator at risk of becoming unstable, or working irregularly. (Airplanes generally aren’t a drag-and-drop factor here because they need to be recompiled in x64.)
• With this in mind, it is incumbent upon developers to not simply “re-wrap” existing products to make them “installable” within the Prepar3D v4 environment without ALSO taking the time to re-export the code and model elements using the Prepar3D v4 SDK tools. If a developer simply updates their installer to allow you to install in the Prepar3D v4 environment without also taking the time to re-export the code and model elements- your sim is at risk of becoming unstable, just as if you had drag-and-dropped a non Prepar3D v4 product.
• Tools that allow users to alias older, Prepar3D v3, FSX, FSX-SE scenery and utilities into Prepar3D v4 are a sure-fire way to make your simulation unstable.
• Through our efforts to trouble shoot user installations that exhibit significant FPS drops when using dynamic lighting, we have found a direct correlation between performance while using dynamic lighting and whether-or-not the scenery was created using the Prepar3D v4 SDK tools. Users who turn on the landing lights in a Prepar3D v4 exported scenery will generally see only a slight performance hit, but if the same user then moves to an airport that was exported using the FSX, FSX-SE or Prepar3D v3 scenery tools- that user will almost always see a significant performance hit. This is to be expected, since the new exporting tools contain many of the programmatic elements needed to allow things like dynamic lighting to work properly with the Prepar3D v4 rendering process.
• We have found that our technical support team is able to clear a significant number of CTD issues within Prepar3D v4 by simply removing aliased and non-compliant scenery and utilities.
• Developers within the simming community have enjoyed relatively straight forward portability of products between FSX, FSX-SE and Prepar3D for a number of years. That portability has been beneficial to customers, but has served to mask the fact that the “Microsoft Flight Simulator” origin product lines are growing more and more distant, and need to be treated individually by developers.
• Developers cannot simply shoe-horn products developed for FSX/FSX-SE/Prepar3D v3 into Prepar3D v4, but should instead treat the transition to Prepar3D v4 seriously, exporting new code and model elements as recommended by Lockheed Martin in order to ensure the stability of the platform for all users and developers.
• Users need to be mindful that Prepar3D v4 is a unique platform, and just because an old favorite scenery will load does not mean that it will run without undesired side effects.
The following list is a trouble shooting checklist we have found that helps users to identify and self-resolve reports of FPS and performance loss when using our products. I’m tacking it on here free-of-charge in hopes that it helps you to see the methodical ways you can self-diagnose performance issues within Prepar3D v4:
1. Are you running the latest GPU drivers?
2. Are you using PMDG’s product at a legacy airport (FSX/FSX-SE/Prepar3D v3 scenery imported by drag-and-drop or aliasing tool), if so, you should check with the scenery developer for a version of the scenery that was recompiled specifically for Prepar3D v4 using the Prepar3D v4 SDK tools.
3. What are your Anti-Aliasing settings? SGSS causes pretty hard FPS drops while MSAA up to 4x does not impact too much. MSAA 8x has a small impact but is manageable on most machines.
4. Are you running both Dynamic Lighting and Dynamic Reflections? There have been reports on LM beta forum saying that Dynamic Reflections on high while also using dynamic lighting together will eat FPS performance significantly. With PMDG products its recommended that Dynamic Reflections be turned off completely unless you find the performance hit to be acceptable.
5. If you are receiving odd CTDs or performance loss, look carefully through the tools, utilities, scenery, add-ons that you have installed and make certain that they are actually Prepar3D v4 compatible. When I doubt, ask your tool/utility/scenery/add-on developer the following question: “Was this product exported using only the Prepar3D v4 SDK tools?” If the answer is anything other than “yes” then it COULD be a problem within the sim.
I know portability is a great thing, and users have asked for years that all products be made compatible with all platforms- but portability takes work. With that work comes the responsibility of the user to make sure you aren’t introducing something to your sim platform that could potentially make it unstable. While some utilities/tools/scenery/add-ons might work just fine when forced into Peepar3D v4, many others will not- and those will decrease your enjoyment of Prepar3D v4 as you hunt down the problems and manage the frustration.
None of us want to see that- so be protective of your installation!
*With special thanks to PMDG’s Jason Brown, as well as our support team for their efforts to rapidly build our internal knowledge and working understanding of the impact of non-Prepar3D v4 software on the platform.