silentsage

No, it causes problems in various aircraft.

I'd like to confirm the correct way to save a flight in P3D V4. I'm having problems with flights previously saved and then reloaded. What I'm doing is: 1. Pause the simulation, making sure that that the aircraft is in a stable condition (e.g., wings level, power steady, etc.), time compression is off, and the simulation is paused. I'm using the standard P3D drop-down menu selection for saving flights. 2. Exit P3D. 3. Return at a later date and start P3D, and then select the saved flight from the scenario screen. I never start a PMDG flight without a clean restart of the sim. The default flight when the scenario screen loads is the default F-22, engines off, parked on a runway (some aircraft from third parties (e.g., Milviz) are very sensitive to the default scenario even if it is never loaded or used). 4. When the flight loads, about 70% of the time it never enters the countdown for initialization. Instead it simply starts flying, but all displays are blanked and the aircraft ignores all inputs. I've tried using the panel state save feature, hoping that if the restart fails, I might be able to load the saved state. But since the controls and displays are unresponsive that won't work. I'm trying to practice hand-flown instrument approaches, and it would be nice to be able to reliably save/load a flight prior to TOD. I'm running P3D V4 with all the latest updates, and the PMDG aircraft with all the latest updates. This problem is common to all of them (e.g., 737, 747, and 777). I use FSUIPC, and I've disabled autosave, and use the P3D save feature exclusively. Any suggestions will be welcome, thanks.

I have a problem in which it appears that I can't get the parking brake to release (or the brakes are stuck on). I'm running P3D V4 and using FSUIPC. Everything seems to work correctly in the cockpit, but when I view the aircraft from the outside I get smoke and sparks when I taxi. My understanding from other threads is that when I set/release the parking brake I should see the rudder pedals move, but they don't. The parking brake appears to work correctly in the cockpit (i.e., the keyboard command works properly). I've tried everything I can think of to fix the problem, but have run out of ideas. Any suggestions would be appreciated. Thanks.

I have a general question about the difference between the FPS I get when in the virtual cockpit vs. "View Cockpit Forward" in P3D V4. Not a complaint - I'm getting good performance overall. It's just that when in the VC I'm running ~24 FPS, and in View Cockpit Forward I get better than 70 FPS. I'm using a i9 7900x and a GTX 1080i, with ORBX scenery and Active Sky P3D V4. The issue is that when I'm in the VC, I get a stutter due to the low frame rates, and I'd like to improve that if possible. I've done a lot of experimenting, and my results are that the VC frame rate appears to be largely insensitive to terrain settings, lighting settings (including dynamic lighting and reflections), scenery objects, shadows, water, etc. (as long as I stay at reasonable settings). Also, using airports and flights in areas that don't involve Orbx or HD airport scenery has no effect. I suspect the issue involves rendering the VC itself. I've adjusted all the VC-related settings I can find (e.g., texture size) but no luck. I'd like to know if anyone has any any clever ideas to improve the VC FPS. Thanks in advance.

I've searched the documentation, but haven't been able to find an answer to this question. In general, when are the flaps lowered to various levels, and when are the gear lowered? How is it done in the real aircraft? I've tried methods based on altitude, or distance from the runway, or speed, but I'm not convinced I'm doing it right. My impression from the tutorial is that 1 degree is lowered when the aircraft decelerates to around 200 knots, and then successively lowered each time the target speed is reached for that flap setting until the landing flap setting is achieved. Is this correct? I live near an airport, and I've noticed that the airliners drop their gear about 5 miles from the runway at an altitude of about 2500 feet. Seems like in the sim I'm lowering gear and flaps at a much greater distance, and then flying slowly to the runway. I have the same questions for the 747 and 777, so if anyone wants to comment on differences in technique between these aircraft I'm interested in hearing your thoughts. I've been flight simming since the 1980's, and these PMDG aircraft are far and away the most interesting and challenging I've seen. Thanks in advance.

JustanotherPilot - I agree. I used the Flight1 GTN 750 whenever I could in P3D 3.4. Bert Pieke is a genius (as are others who contributed to it). F1 says it may be a while before the P3D v4 compatible version is released. Guess I'll just have to wait.

Martin - Thanks for the help. Prior to my post I read the entire thread and tried (as best I could) to implement its suggestions. Part of the problem is that the edit to dll.xml assumes the file Carenavigraph.dll is in the same path as dll.xml. On my system it isn't, so the patch doesn't work. If there is a "Carenavigraph.dll" file on my system I sure couldn't find it. If Carenado knows, they aren't telling anyone.

Yes, I read the entire thread and tried all the ideas in it. There are multiple threads like this on this forum and elsewhere. As best I can tell, no comment from Carenado on things to try.

I have about a dozen Carenado aircraft of various kinds. As they are upgraded to P3D V4 I've been adding them to my system. I am appalled and dismayed that the dreaded "Building Navigraph Database" problem is back (at least for me). I understand that these sims are complicated, and with the release of a new version problems are to be expected. But this problem has been afflicting Carenado users for years, and there is absolutely no support provided by Carenado for this. Browsing this forum and the web yields numerous postings where various folks have attempted to fix the problem. The silence from Carenado on this topic is deafening. I don't mind spending time applying fixes, but it would be nice if Carenado would at least attempt to help. Carenado has a reputation for aircraft that are great eye-candy, but which have very poor (i.e., buggy) systems. I have reached a point where I'm not purchasing any more Carenado products until the support is improved and the product launches are higher quality. That 390 Premier 1A looks great, but I'm not buying another product so that I can get more database build errors and Navigraph avionics that don't work.

FYI, when the Aerosoft OV-10 for P3D V4 is installed on my P3D V4 system, it interferes with the the PMDG 777x and 747 QOTS II for P3D V4. When I tried to use the 777X or 747, they would not initialize and all cockpit controls were dead. Disabling the OV-10 add-on seems o fix the problem, but I just deleted the OV-10. This was surprising thing for me was that the P3D V3 version worked fine for me in P3D V4, the problem only occurred when I upgraded to the P3D V4 version.

I worked further on this and I noted that the waypoints as programmed in the CDU starting at DYAMD through CEPIN have "at or above" restrictions on the lowest permissible altitude at the waypoint (with the exception of ARCHI). The IFR charts at the end of the tutorial document specify specific altitudes starting at FRELY through AXMUL I understand the reason for the at-or-above restrictions (I'm a pilot in the real world). I believe that what is happening in the sim is that the at-or-above restrictions keep the aircraft above the glideslope. I removed the at-or-above restrictions, and changed the altitude at waypoint values to 100 feet below the chart values on ZILED GIRR, DUMBA, and CEPIN, and now have no trouble with glideslope capture. The glide slope is above the aircraft and it is captured as the aircraft flies through it in the descent. A second issue is that the tutorial (correctly) states that the MDA be set to 1800 feet. The AXMUL waypoint specifies an altitude of 1800 ft., but the preceding waypoint (CEPIN) has an at-or-above restriction, so the aircraft enters the CEPIN - AXMUL leg on a path above the glide slope, and appears to never capture it (at least for me). When the aircraft arrives at AXMUL, GS hasn't been captured, so the FD uses the 1800 ft MDA and flies over the airport at 1800 ft. Does anyone know if the simulation is limited to glide slope capture from below? I have not been able to capture the glideslope from above. My impression is that the limited GS capture range in P3D, combined with the at-or-above restrictions in the CDU waypoints, can cause issues.

I'm following the tutorial, and everything works perfectly up to the point where the glideslope should be captured. Any ideas for troubleshooting this? The only thing I can think of is that when I save the flight immediately prior to descent, the aircraft reloads with something missing. The aircraft, aircraft , flight plan, and all switch settings match the tutorial. Thanks.

I recently purchased the PMDG 777 and have a question about VAS use. I have most of the ORBX products on my system, including the various scenery regions. I also use FS Global Ultimate Americas. I know that VAS usage is an issue, and I've restricted my 777 flights to airports that are far from the ORBX scenery regions. A route I often fly is from Chicago to Detroit, and I believe it uses only the default P3D scenery. I also follow the PMDG guidelines for minimizing VAS use. My question is, would the ORBX products still consume memory on such a flight? I'm used P3D v3.2 on Windows 10. I'm considering running two parallel P3D installations, one which has ORBX, and one which does not. I have a few other aircraft where VAS usage is an issue, and if running without ORBX is a solution, I will try this. Thanks

GLEXpert - Thanks. I see the yellow indication, now I know what it is. I do get a localizer deviation bar for ILS approaches. My guess is that the Proline PFD doesn't support it when flying between waypoints using GPS. No big deal, just wanted to know if I was missing something. With these mods this is my new favorite plane.

Thanks very much for all the hard work. These upgrades are an outstanding addition to the CJ2 (which itself is a great product from Carenado). A few questions about the PFD: Is there a manual anywhere for the PFD? If not, does the PFD provide any indication of standard and 1/2 standard turn rates? Finally, is there any way to get the PFD to display a CDI while enroute using a GPS flight plan (like the Garmin 1000)? Again, thanks very much, these are the kind of innovations that keep the hobby fun.

WarpD - In my job, I design Intel motherboards, and work with quite a few folks who also design hardware and software using Intel CPUs. None of us have ever heard of CPU parking increasing CPU temperatures - it just does't work that way. If you have actual data, or can point to benchmarks that demonstrate your claim, we'd like to see it. Our Intel and Microsoft reps don't have issue with using it, but perhaps you have some information that they lack. StoreydTrain - Someone in another forum, using a different name, wrote a response that is worded very similarly to yours, and I'll post this same reply there. I read the thread that you listed, and many others, before posting my original question. The thread you quote points out that Microsoft itself, in published documents, acknowledges that disabling CPU parking improves performance. Also, the thread contains comments by several folks who tried it and got positive results. Sorry if this seems harsh, but when I posted the original question, I was hoping that someone could discuss some of the details as to why CPU parking may, or may not, help with the software architecture used in FSX and/or P3D. That's why I posted the same question on the P3D site, where I asked the LM experts for their opinions. Hand -waving arguments not backed by data just don't help anyone.

This topic is quite active for other types of games, I'm not sure why there is such reluctance to discuss it here. A number of folks have said it reduces microstutters in quite a few different games (including FSX), and that suggests there is something behind it. Let's try to keep responses data-driven. If there are facts about this (positive or negative), it would be good to know them. If not, we can all move on. Philosophical responses not linked to data are not all that helpful. FYI, the CPU park settings are not affected by the power settings in Windows (i.e., setting opwer to "high performance" does not change them). Thanks.

There is a topic in this forum* that discusses CPU parking, and it has been locked. In that thread, there is a link to a post that ostensibly discusses why CPU parking is a bad idea. When you go to that link, the text for that post is missing - the title is there, but the actual text is missing. Could I please ask whoever provided that link to please explain why disabling CPU parking is a bad idea? It's getting a lot of attention in other games, and appears to be successful and witjhout risks (though I could be wrong). FYI, I'm an electrical engineer whith 30 years experience in designing motherboards for Intel processors. The concept seems sound to me but, if not. I'd like to understand why. I've tested it on my system and it is a huge improvement. Thanks. * Since this thread was moved, the topic the OP is referring to may be found here: http://forum.avsim.net/topic/432634-bad-idea-regedit-for-windows-7-microstutters/