Hi,just an update on the "Beta Testing"....I took a chance yesterday to have some spare time and used it to make some "endurance test" with the NGX 737-800 on my “g3dl.dll areas” ...I started from LFMN to EDDM (intentionally made two go-around at EDDM before landing), then from EDDM to EBBR (intentionally spent 30 minutes in an holding pattern at 20 Nm from EBBR), then from EBBR to EDDF and finally from EDDF back to LFMN ...I didn't exit FSX between the flights and made normal turnarounds (whose duration went from a minimum of 45 minutes to a maximum of two hours). The NGX remained powered during all turnarounds. Total continuous simming time including turnarounds was almost 7 hours.I did not experience any CTD and the FSUIPC log at the end indicated the following: " G3D fix: Passes 1466659, Null pointers 0, Bad pointers 19, Separate instances 19", and a total of 6 lines as "*** G3D bad pointer trapped and crash prevented ***PC settings were as per signature below, FSX settings were in the medium-high end (the scenery was quite enjoyable)...see an extract from my fsx.cfg below:AUTOGEN_DENSITY=3DETAIL_TEXTURE=1LOD_RADIUS=6.500000MESH_COMPLEXITY=100MESH_RESOLUTION=25SWAP_WAIT_TIMEOUT=2TEXTURE_RESOLUTION=29WATER_EFFECTS=4[sCENERY]DAWN_DUSK_SMOOTHING=1IMAGE_COMPLEXITY=5LENSFLARE=1SmallPartRejectRadius=1.0As usual fps was set to unlimited and FPS limiter 2.0 used (limit to 25)No shader Mod 3 installedNo Affinity mask tweak appliedNo FFTF tweak appliedJust had the bufferpools tweak applied as below:[bufferPools]RejectThreshold=131072FSX set up was with a networked laptop running ASE, Radar Contact 4, EFB, through WideFS and Simconnect.AI traffic was set to 60% (UT2)Ultimate Terrain Europe X was enabled with most of its features on.The time of the day was a mix of day, dusk and night, just to test different textures.All flights were smooth and fps steady…..Well, this would have simply been a "mirage" only one week ago...!Regards

I also gave this fix a try, even though I don't have appcrashes anymore since a few weeks. FSUIPC confirmed this because no matter what I did to create a crash, it didn't happen and the log was 'clean'. So I guess I am one of those lucky guys who don't need this fix. ;) Apparently my system is perfect now. :) BTW I am using extremely dense settings and only fly above PNW.Still, it's great to see so many people being able to fly where they want to without problems thanks to this fix!

I did not experience any CTD and the FSUIPC log at the end indicated the following: " G3D fix: Passes 1466659, Null pointers 0, Bad pointers 19, Separate instances 19", and a total of 6 lines as "*** G3D bad pointer trapped and crash prevented ***

The summary at the end should have said "Separate instances 6" then. That silly little bug is fixed in 4.749e. In the d update the number is just another copy of the "Bad pointers" count.RegardsPete

Thanks Pete, will replace it right now with 4.7943.Regards

Hello:I'd like to provide some additional detail to my feedback above in this thread: http://forum.avsim.n...ost__p__2176481 ,and to do so in reply to the well-intended (but incomplete) quote of my post here: http://forum.avsim.n...ost__p__2177945Although I am pleased that the current FSUIPC update(s) have fixed some of the occasional visual anomalies experienced in my flights over OrbX FTX PNW scenery, I do still have one ongoing problem which may- or may not- be related to what could be fixed by further coding changes in FSUIPC.After 5 to 15 minutes of flying, some terrain land class tiles fail to resolve fully... with some land tiles either appearing initially as water (or as "striated bands" ...somewhat like distorted versions of texture files for vector shorelines when viewed in the FSX SDK ImageTool). Often, those "anomalous tiles" end up rendering with what appears to be a very low MIPMAP "globe image" terrain texture of [FSX install path]TextureEarth1.bmp or Earth2.bmp; in some cases these tiles later fully resolve the proper land class texture as I continue flying.FYI: I have not yet tried the proposed OrbX FTX Day / Night "attached light effects" toggle; and I don't know whether this might otherwise simply be an ongoing issue due to the purposely very low powered video card I use on that FSX test system (ex: not being able to graphically keep up) with the custom terrain texture "RenderPriority=" assignments added to [FSX install path]Terrain.Cfg by the OrbX FSX installer.I must further clarify that I have indeed not yet resolved all other possible issues with scenery rendering in my OrbX FTX PNW area (ex: I still have to check for missing textures and object GUIDs in the area which might have not been fixed via proposed "dummy object" libraries intended for distribution via ex: OrbX FTX service packs).BTW: AFAIK, I am not describing "Blurries" as I describe the above OrbX FTX PNW terrain tile texturing "anomalies", as usually nearly all other contiguous and surrounding terrain land class tiles are resolved satisfactorily and immediately ...despite the handful of bizarre tiles that sometimes show up within my preferred "locked spot" aerial field of view. http://www.orbxsyste...-daynight-idea/http://www.orbxsyste...f-missing-guid/But again, not wishing to digress from the main focus of this thread, I'll gratefully welcome seeing any further workarounds that might be implemented via FSUIPC, and I look forward to eventually eradicating other outstanding issues to optimize my enjoyment of flying in the OrbX FTX PNW area ...with and without 3rd party scenery also being installed (and properly rendered "concurrently") in that region.Hope this helps ! GaryGB

I got a G3D.dll at AS_ENGM with 4.749d. The first time I landed at that airport since purchasing a few days ago. This airport is well known for missing libaries, but FSUIPC did not save the day at this airport, but not expecting it to save every error due to many variables. I checked the fsuipc log, but nothing recorded in regard to G3d error in this instance.( Must have stopped logging when error occured. G3D fix was loaded in the log). Please note, only ENGM this has happened with Pete's fix.

I'll gratefully welcome seeing any further workarounds that might be implemented via FSUIPC

Sorry, but i know nothing whatsoever about graphics nor any of what FS does in that area. The only reason I could trap and recover from those very specific G3D crashes was only because (a) they crash at a specific place in the G3D code, and (:( the place in the code was conveniently a small routine with an exit close by which only returned a True or False result. I simply forced it to return False if any of the sequence of pointers it was about to use proved illegal.I have not the foggiest idea what that routine I am patching does, not the results of returning False instead of True. It was simply fortuitous that there appeared to be no noticeable adverse results other than the averted crash.RegardsPete

I got a G3D.dll at AS_ENGM with 4.749d. The first time I landed at that airport since purchasing a few days ago.

You haven't posted the details, in particular the offset in G3D.DLL, but there are probably a large number of other possible crashes which aren't specifically the one being trapped. In fact there are a few others reported earlier in this thread. Maybe yours was one of those?Pete

Sorry, but i know nothing whatsoever about graphics nor any of what FS does in that area. The only reason I could trap and recover from those very specific G3D crashes was only because (a) they crash at a specific place in the G3D code, and ( the place in the code was conveniently a small routine with an exit close by which only returned a True or False result. I simply forced it to return False if any of the sequence of pointers it was about to use proved illegal.I have not the foggiest idea what that routine I am patching does, not the results of returning False instead of True. It was simply fortuitous that there appeared to be no noticeable adverse results other than the averted crash.RegardsPete

Thanks again, Pete, for following up on this ! In light of what you had achieved thus far dealing with error trapping / recovery via FSUIPC, I was just wondering (as a non-programmer) if anything related to a FSX rendering error condition might be trapped and dealt with via FSUIPC relative to an initial "delay" in locating a mapped object GUID or texture, which AFAIK compels an FSX "internal search" for a specified period of time before 'giving up'... which I would then assume also might be treated as a type of "error result" when the rendering engine finally "moves on"I would speculate for the sake of exploration here, such a delay might be due to: 1.) File I/O2.) Rendering complex custom multi-layer texture tiles with associated modifications as to "Render Priority=" in Terrain.Cfg3.) Just plain slow graphics hardware throughput on that particular video cardPerhaps I'll experiment with a 'deprecated' (but IIUC still functional ?) "tweak" to FSX.Cfg based on this info from my rather abundantly annotated FSX.Cfg file, to see if I can minimize / eradicate the above terrain tile anomalies in in my FSX SP2 / Acceleration install of OrbX FTX PNW on that system. [TERRAIN]SWAP_WAIT_TIMEOUT=2// SWAP_WAIT_TIMEOUT= The default is 30 frames; Al Jordan uses SWAP_WAIT_TIMEOUT=90 !// SWAP_WAIT_TIMEOUT=30// Number of frames terrain engine waits for textures to load in video memory before forcing new tiles of terrain triangles to be rendered.// This is because terrain triangles are bound to specific texture resolution by texture coordinates contained in each vertex.// When the terrain engine wants to increase the texture resolution on a tile of terrain, for example when you fly closer to the// tile, the texture coordinates must be updated to reference the higher resolution texture.// However, the new tile can't be rendered successfully unless the new texture is available in video memory.// The terrain engine will wait for a number of frames determined by SWAP_WAIT_TIMEOUT for the new texture to be loaded into// video memory.// If after SWAP_WAIT_TIMEOUT frames the texture still isn't available, the terrain engine starts using the new triangles anyway.// This usually results in a tile of terrain that is either missing or textured strangely/incorrectly for a few frames until the texture// finally shows up in video memory.// (Bojote said: "A warm thanks to Adam Szofran, a Microsoft ACES team member and well known community member for his clear definition")//http://blogs.msdn.co...aks-in-sp1.aspxhttp://forum.avsim.net/topic/61690-swap-wait-timeout-blurries-please-clarify/NOTE: My test system also uses D3D9 AntiLag config file "RenderAheadLimit=2" and "FPSlimit=20"Possibly this info might stimulate some ideas for others to consider in fine tuning FSX performance with OrbX FTX PNW as well. Regards,GaryGB

Sorry, but i know nothing whatsoever about graphics nor any of what FS does in that area. The only reason I could trap and recover from those very specific G3D crashes was only because (a) they crash at a specific place in the G3D code, and ( the place in the code was conveniently a small routine with an exit close by which only returned a True or False result. I simply forced it to return False if any of the sequence of pointers it was about to use proved illegal.I have not the foggiest idea what that routine I am patching does, not the results of returning False instead of True. It was simply fortuitous that there appeared to be no noticeable adverse results other than the averted crash.RegardsPeteYou haven't posted the details, in particular the offset in G3D.DLL, but there are probably a large number of other possible crashes which aren't specifically the one being trapped. In fact there are a few others reported earlier in this thread. Maybe yours was one of those?Pete

Yes, i made a mistake there Pete, forgot to copy the log before restarting FSX. It is only ENGM that has not passed muster, so will re-install in case I have done something I should not have.

I was just wondering if anything related to a FSX rendering error condition might be trapped and dealt with via FSUIPC relative to an initial "delay" in locating a mapped object GUID or texture, which AFAIK compels an FSX "internal search" for a specified period of time before 'giving up'... which I would then assume also might be treated as a type of error when the rendering engine finally "moves on"

I wouldn't know even where to begin to look, let alone understand what such things were doing merely from examining assembly code. FSX is all written in C++ and compiled with an optimising compiler which takes advantage of pipelining, moving code around for efficiency.. I've got no idea what most of it is doing, not a chance without source code. I only just about understand the assembly code the compiler produces from my own C, but that's mainly because it is C, not C++, and so has a much much closer relationship with the underlying machine. Even then the rearrangements to get parallel processing done in the various pipelines can make the mind boggle quite easily.When a definite break in an FSX routine occurs there's always a chance of seeing if one can intervene, at that point, and that's all that happened with this main G3D crash -- there are still a multitude of other crashes no doubt. Maybe some others can be trapped too, but I doubt if I'd be so lucky very often to have such an obligingly short routine with easy exits. When there's no crash, there's no identifiable code to even look at!Sorry to be so negative.RegardsPete

Still working 100% here Pete. You are either a good shot, or very lucky if finding this cure is as difficult as finding a needle in a hay stack. I think the former.Kind regards,

To better undersnd the effect of the patch on FSX stabiliy, as a test it would be interesting to see what would happen if FSUIPC patched the return value of all calls (and not just the ones with invalid addresses).Cheers,- jahman.

Why can't we all just enjoy the patch and leave it at that? It's like a nature of the man to doubt everything and not to enjoy. I did couple of flights since (mind that, that's more than I did in last couple of months), and I've been greatly satisfied - tonight Openskies is coming and I'm really looking forward flying into extremely busy airports.

Why can't we all just enjoy the patch and leave it at that? It's like a nature of the man to doubt everything and not to enjoy. I did couple of flights since (mind that, that's more than I did in last couple of months), and I've been greatly satisfied - tonight Openskies is coming and I'm really looking forward flying into extremely busy airports.

Fully agree...... I hadn't been flying for months the way I flew two days ago (see my post above).......let' s enjoy the sim ...!

Pete should get a dozen of FlightSim Oscars for his lifework

+100

I don't drink, but if I could, I would buy a round for everyone here, and propose a toast to all those like ORBX, PMDG, Aerosoft and the many others who have elevated FSX to much more than we all thought possible! ...and to geniuses like Nick, ******* and Pete who helped us make it work... and to all the others who kindly spent untold hours freely listening to, researching for, coaching with and working alongside those who needed it to make their hobby fun. There is still honour and respect in this place. I am proud to be a member of the AVSIM forums and share in the benefits.Kind regards,

Absolutely well said, with one difference, Here we can/are allowed to differ with each other and still get the job done.Absolutely amazing what some people can accomplish given them opportunity to list their issues/differences and still move forward.Well done to all...!!