PinkPony

Are you referring to the same issue I provided a fix for in the thread? https://www.avsim.com/forums/topic/634720-v54-and-ft-eham-incompatibility/?do=findComment&comment=4970616

I managed to fix it. Solution: 1. Locate the eham_grd.lua file in \FlyTampa\Amsterdam\scripts and rename to .off (or delete it). 2. Replace with my eham_grd.lua file, available here https://www.dropbox.com/sh/vkiu3r1hc4horyb/AACef_0mhafuy17u-k2XjBgca?dl=0 3. Enjoy. Long live P3D! Evidently there has been a change in how P3D v5.4 processes .lua scripts. In the case of Flytampa Amsterdam V2 .lua scripts are used to load the various (seasonal) ground textures which was no longer occuring with the original .lua script. P.S. I will reach out to FlyTampa to share my findings. If someone could be so kind to share my solution here on the main FlyTampa thread https://www.flytampa.org/forum/viewtopic.php?t=36743

This ^ Until the community is willing to pay a few hundred dollars for a study level aircraft, there is no way a addon developer will be able to justify obtaining Boeing PET data for B787/MAX/B747-8 and all subsequent aircraft which no longer have the paper FPPM As a result it does not come as a surprise that PMDG’s B748 flight dynamics are a copy and paste of the B744 flight dynamics, and therefore largely incorrect. Comparare Boeing OPT performance figures to the PMDG B777/B737NG and it is practically spot on. In comparison PMDG B748 performance is off by order of magnitude compared to the Boeing OPT. Wishing for a B787/MAX/B777C that is anywhere as close to the real thing as the B777/NGXu we’re is a pipe dream! Never going to happen. Same applies to the A350, just refer to what Amir at Fenix wrote on the subject

Update, I have completed the North side of Terminal C - Gate: 230/231/232/233/234/235/266/237/238/241/243/245) Next up is working on the (currently) three operational South side Gates: 240/242/244 - The remaining South side gates are a W.I.P. in the real world. Features: Taxi/Apron lines (Google Maps is still out of date so I will need to wait for more recent imagery before further improving the layout of each taxi/apron line and the gates. GSX Level 2 integration(Gate 230/231/232/233/234/235/266/237/238/241/243/245). Currently only Gate 241 - 243 have VGDS (still unsure what the real world setup is). I will update the GSX.ini once additional real world reference is available. Bugs: No taxi lights on Terminal C apron. Although I added lights to the AFCAS and layer the MOD above the T2G scenery entry, I have not been able to get the AFCAD taxi lights to appear above the ramp texture (If anyone knows how to, please reach out to me). There is a texture gap in the middle of a Terminal C taxiway (see bottom left corner of my preview screenshot). This is a T2G bug which is present in the scenery. I should be able to fix this soon (once I figure out how to use Blender). NOTE: As fare as I could tell, the only way to remove the construction crates that surround Terminal C is to modify the T2G Terminal C model file. While doing so was very easy, without written permission from T2G, I cannot share the modification of their Terminal C model. I will contact T2G to ask for their permission to share the MOD of their Terminal C model (the only change is the removal of the construction crates). Previews: https://www.dropbox.com/s/gwugkkvm9rr8ah6/Overview_Day.jpg?dl=0 https://www.dropbox.com/s/zias10fkj603xlb/Overview_Night.jpg?dl=0 Linked to MOD* https://www.dropbox.com/sh/4ebironq87307up/AAAxpu68R9D7t6Mg0UWFUEFLa?dl=0 *The MOD does not contain any T2G files (see above NOTE).

I’m working on it! Removing the construction related objects that are scattered around Terminal C was pretty straightforward. Now I am adding the taxi lines to the ramp and working on the GSX L2 configuration for each of the gates. Early preview, I am going to try and replace the ramp texture as well. https://imgur.com/a/VM93SnO Long live P3D 😀

How, has v5.3 HF2 been so far? I am enroute now for the first time in v5.3 HF2, praying the sudden/permanent FPS drop/spike/freeze is gone for good!

The mso20win32client.dll related P3D CTD is caused by the following: A 32bit MS Access database installed in conjunction with 64bit P3D. RAAS utilizes the MS Access Database (2010) to read runway data (and generate callouts) in 64bit P3D. In this case, ensure you have the latest RAAS installer, v3.3 and run it again. It will install a 64bit MS Access database (2010) and the CTD will not occur again, unless you CTD is caused by Office 365: At some point in 2019 a Office 365 update began causing P3D to crash. Event viewer always showing mso20win32client.dll as a faulting module prior to the CTD. This CTD is unrelated to RAAS as it occurs even without RAAS installed. For anyone suffering from this P3D CTD I assure you it did not begin with v5.3 HF2. I have been able to reproduce this Office 365 related P3D CTD in all versions of P3D v5.x. Event monitor will always show mso20win32client.dll crashing followed by P3D.exe crashing within the next two hours. How one causes the other is entirely for MS/LM to sort out! In this case the only solution is uninstalling Office 365 or reverting to a older Office 365 version. The challenge is that it is unclear after which specific Office update the bug was first introduced. In fact over the past two years the bug disappears and returns between different Office 365 versions). I have been forced to uninstall Office 365 entire from my P3D system. At some point over the past month, the most recent Office 365 update began causing this P3D CTD again.

Thank you Rob, fingers crossed. Is this Fix referring to the main subject of this thread? The sudden/permanent FPS drop/freeze/fluctuations in V5.3 which occur sporadically between sessions and seemingly not for every user (albeit for most). I say this because we don’t know for certain if the pauses/stutters caused by the Helsinki coastline (and other locations) are related to the main subject of this thread. Not to mention that this bug has been present long before V5.3. The pauses/stutters near Clayton VOR (coastline related) date back to the FSX days and live on in v5.3 HF1.1 (cured if you use OrbX England as it replaces the default .bgl)

Would you mind reverting your GSX prompt menu to Scaleform and performing a few sessions to test? Modify the missionpanels.cfg in the gauges folder in your Prepar3D installation directory. Changing these entries will revert these windows back to the Scaleform version: [Window12] ; for GSX change: html_file = Menu; html_instance_name = SimConnectWindow; to: scaleform_file = menuwindow; scaleform_instance_name = SimConnectWindow; If GSX is inducing this it would only be because the GSX prompt menu is a HTML5 window and the HTML5 window is the one causing the subsequent performance loss/pauses. HTML5 menus/windows introduced some serious pauses/freezes in V5.2. Although LM believes to have fixed this in v5.2 HF1 they nevertheless disabled HTML5 by default in the Prepar3D.cfg as of v5.2 HF1 (out of an abundance of caution). However, I believe that the GSX menu prompt is nevertheless being rendered in a HTML5 window (can anyone confirm this?) If this is a HTML5 bug then reverting GSX to the Scaleform window will help us confirm wether that is the case or not. And yes, I am aware that this bug has also occurred with a vanilla V5.3 HF1 (I experienced it myself).

Another four flights in V5.3 HF1 Three uneventful, while during the fourth I once again encountered the sudden/permanent FPS fluctuations/drops/freeze from 0 - 100+ FPS. This time cruising at FL380 near KBUF in the FSL A321. I was forced to save the scenario and restart P3D. FSLabs have announced that they will not be releasing the A320 Family V5.1HF1.1 compatibility update to their public release channel, until LM sorts this bug out (the comparability update is already available through the experimental channel). That was unfortunately my last time using V5.3 HF1.1, such a shame and very frustrating considering how well it performs when it doesn’t suddenly turn into a slideshows. Back to V5.1 HF1 for now.

Rob, does this confirm that the cause of the MK EHFK bug in V5.3 is completely unrelated to the subject of this thread? I always use Medium Scenery Draw Distance and continue to reproduce the bug being discussed in this thread in the 215+ posts P3D forum thread. I can’t wrap my head around the fact that I can fly between two airports with perfect performance (as I always experienced in V5.0+ and upon repeating the identical flight again (to test this very bug) I suddenly encounter my FPS alternating between 0 and 100+ How can an identical v5.3HF1.1 .exe behave so differently between sessions/restarts? Not to mention yourself a few others who seem unable to reproduce this at all. Although that appears to be a minority of users who are free of this problem, as there are dozens of users who reported the same bug in V5.3+

I always use unlimited (30 FPS via P3D VSYNC and 30Hz monitor) so the bug definitely has nothing to do with that. I seriously doubt it has anything to do with a specific setting. There were some significant changes made between the V5.2 and V5.3 clients (this the excellent performance improvements) but clearly something was broken!

I was able to replicate the bug using Upgrade_Process_Priority=1 Like Rob I was curious if this would help make a difference as this option was first introduced in V5.3

Rob, Thank you for testing and sharing your results, very helpful! I see that your FPS was alternating between 0, 0.6 and 40+ When the sudden/permanent FPS drop/freeze occurs on my system I noticed that P3D FPS counter alternates between as much as 0 FPS and 100+ FPS. The normal 30 FPS via VSYNC (30Hz Monitor) are completely ignored. GPU usage also drops significantly. Whatever is causing this issue at MK EHFK may also be the cause at other airports or during cruise as scenery is paged. What I still don’t understand is why it only occurs occasionally for some of us and at random locations or stages of flight. +1 I can’t believe there are some trying to deflect to monitor resolution as a culprit here. I used 4K resolution beginning in P3D v4 with a 1080Ti and my system NEVER encountered the bug being discussed here. Still using 4K with a 3080Ti since July 2021 and NEVER encountered this bug until V5.3

I agree and I hope that the two are related! I must say I am both shocked and disappointed if LM really have failed to reproduce this after weeks of bug reports. Myself and dozens of other experienced P3D users can reproduce this consistently yet LM haven’t a single time? Not to mention, the FSlabs dev team have already confirmed this bug in their own testing of V5.3 and V5.3HF1 and have downgraded back to V5.2HF1 as a result… Can’t be that difficult for LM to reach out (or vice versa). I’m sure the FSLabs devs can share insight form their own debugging. 215+ posts on the main bug thread over on the P3D forums. Numerous users detailing how they are consistently able to reproduce this and outlining steps to do so. Yet LM can’t reproduce a single time? Blackbox711 (a highly respected P3D user and Twitch streamer) experienced this bug on multiple occasions during livestreams using V5.3 Not to mention P3D Core Lead Rob McCarthy recently stating that they implemented some fixes in HF to try and solve this. Sounds more like they know very well what is going on but simply don’t know what is causing it or how to fix it yet.