No, I didn't get G3D crash per se. I passed the airports which are "supposed" to cause the crash. And it's kinda visible from the LOG, as you can divide timing of the error into 3 separate time-parts.

Ah, yes, I noticed the grouping. maybe I should not log any closer than say 1 second to the previous (though still count them all for the end summary.Would you prefer the separate log enties, or a grouped log, and should i just say that one occurred and forget the (so far) useless pointer value and the filename?

I had everything activated, I made sure I was looking at the airport as I was passing them, I saw them fully load and still I was able to make a fully successful land into LOWI.

Did you notice any side effects at all? No odd graphics glitches?Were there any jerks or hesitations?RegardsPete

Maybe I should just log the fact that a G3D.DLL crash has just been averted, and leave it at that.

I think that's the important thing. I don't care if averted or fixed or found... as long as it lets me continue my flight and land, I'm happy. Logging is a good idea btw., since couple of those lines won't cause any real problems in smoothness, and can only potentially be useful so one could know if g3d.dll would occur or not - left to user to check the file. Or not.

Well, I could have made it a Registered User facility only. But sales are generally good inany case, so I'm not complaining. Maybe more folks will install it as a result of this and may then decide it is worth purchasing.RegardsPete

I think that's the correct attitude. I think you definitely deserve more purchases solely on this one. I think you should definitely make it for registered users only. Maybe as a checkbox and explanation beside it

Would you prefer the separate log enties, or a grouped log, and should i just say that one occurred and forget the (so far) useless pointer value and the filename?

I think a group would definitely be enough, with a timestamp when it occured. I have no idea what those numbers in front mean... or can you explain?Yeah, the filename is useless, pointer too... just leave it out. You can simply state g3d.dll error was prevented or something like that.

Did you notice any side effects at all? No odd graphics glitches?Were there any jerks or hesitations?

Not that I could notice. I mean, I run NGX, with very high settings FSX - of course I have some jerks and small hesitations sometimes. But seriously, I prefer couple of jerks than a g3d.dll crash.We can only run for some time now, let's call it a beta period, and then we'll see if there is some real difference.But, no graphics glitches.

I think a group would definitely be enough, with a timestamp when it occured. I have no idea what those numbers in front mean... or can you explain?

The numbers in front are the timestamp. They're the elapsed time in milliseconds since FSUIPC started. You can get the exact time of day by adding that to the system time logged at the start.1 millisecond = 1/1000th of a second.Pete

Pete, I did not notice any pause stutter or graphic anomaly passing from 81 to 79nm (crash happens exactly at 80) . I would not blame you if you would include this fix for registered users only, it is because of your knowledge and time this is possible ! Even if I'm a registered user, I plan to make a donation to you if further testing is conclusive.I am now flying from CYUL to KDAB with the Flight1 Mustang, with KIAD from Imaginesim enable, fsx usually crash over the airport with high VAS usage (@3.5), I do not recall which module was on the log, I simply disabled KIAD a while ago; Yesterday I flew this route without crash with low settings, will report back with high settings.Thanks again,Alain from Montreal

The numbers in front are the timestamp. They're the elapsed time in milliseconds since FSUIPC started. You can get the exact time of day by adding that to the system time logged at the start.1 millisecond = 1/1000th of a second.Pete

It would be way easier if the display were in minutes, or possibly real local time. I don't know if that's possible...

That's interesting. The G3D routine which is crashing is only processing aircraft and other SimObjects in any case. You'd think the current aircraft data would be held in memory instead of being reloaded each time, so it may well be -- along with its MDLs path name. This suggests that it's an MDL file structure in memory which is being corrupted (by some bug elsewhere no doubt), and may explain why some actions, like AutoSave, can reduce the errors by forcing some things in memory to be reloaded....

What if you could trigger an object reload via AutoSave (or otherwise) when a bad pointer is detected?

There's really no fix without having the FSX source code, debugging the issue properly, and correcting the code. Hopefully Lockheed-Martin will be doing this for Prepar3D....

If Prepar3D eventually has the GD3 bug fixed, could we replace the FSX GD3.dll with the Prepar3D GD3.dll? (Perhaps not, but it's worth a try).Cheers,- jahman.

It would be way easier if the display were in minutes, or possibly real local time. I don't know if that's possible...

Sorry, all my logs from all my programs provide millisecond time stamps. This enable close correlation on multiple PC wideFS setups, and it is also readable by applications via offsets. This system has been invaluable for the 15 years it's been that way. I'm not changing it now, and there's really no need. You can easily compute your "local real time", for whatever odd purpose you need it, assuming your PC's time, which is logged at the start, is correct.Pete

What if you could trigger an object reload via AutoSave (or otherwise) when a bad pointer is detected?

What's the point? I still have to prevent the pointer crashing FS, which is what I'm doing, and after that it looks like it doesn't matter.

If Prepar3D eventually has the GD3 bug fixed, could we replace the FSX GD3.dll with the Prepar3D GD3.dll? (Perhaps not, but it's worth a try).

No. They're not even using the same compiler. There's zero cross-compatibility for individual modules.RegardsPete

If Prepar3D eventually has the GD3 bug fixed, could we replace the FSX GD3.dll with the Prepar3D GD3.dll? (Perhaps not, but it's worth a try).

No, already tried that. Doesn't work.

Well, I could have made it a Registered User facility only. But sales are generally good inany case, so I'm not complaining. Maybe more folks will install it as a result of this and may then decide it is worth purchasing.RegardsPete

Well, I, for one, will buy the registered version just because of this 'fix'. Thanks Pete!! I did fix my g3d CTD's earlier but with LOD 4.5 radius and 1024 textures_max_load. This morning I decided to try HD textures in FTX/PNW scenery. The g3d error occurred again until I lowered the texture_max_load setting from 4096 to 1024. I just installed your FSUIPC update and I had no crash where one occurred 100% of the time with HD textures (4096). So I'm a happy camper too. Just for info, the log stated:521824 **** G3D Bad pointer: 0x0909A0DB521824 Last file="C:Program Files (x86)Microsoft GamesMicrosoft Flight Simulator XMyTrafficAircraftB752MXmodel.HighFSXW-RRB752w-RR-quality"I've been seeing a lot of MyTrafficX aircraft showing up after the bad pointer. I just upgraded to their latest version and wondering if something is wrong with their aircraft. Another point -- I get the g3d CTD with PNW scenery enabled. If it is not enabled, no CTD even at 4096 textures. I think others, such as Word Not Allowed have also experienced CTD's at commercial scenery areas and no crashes in default scenery locations. Thanks again. I'm off to purchase a license for FSUIPC!Best regards,Jim

Sorry, all my logs from all my programs provide millisecond time stamps. This enable close correlation on multiple PC wideFS setups, and it is also readable by applications via offsets. This system has been invaluable for the 15 years it's been that way. I'm not changing it now, and there's really no need. You can easily compute your "local real time", for whatever odd purpose you need it, assuming your PC's time, which is logged at the start, is correct.PeteWhat's the point? I still have to prevent the pointer crashing FS, which is what I'm doing, and after that it looks like it doesn't matter.No. They're not even using the same compiler. There's zero cross-compatibility for individual modules.RegardsPete

It's OK. It was only possibly an useful idea, so that a user can know when it happened - you can easily see when it happened and thus also know where you were. But I can also calculate with miliseconds if I want to.

Pete,Just overflown AS EBBR twice in the NGX, day and night textures, no G3D CTD :)You should now recieve a percentage of the sales from the sceneries that are going to be sold in the run upto xmas. I'm sure many here have held off purchasing certain add-ons in fear of the CTD.

Sorry, all my logs from all my programs provide millisecond time stamps.

Could add a second format as opposed to replace the milliseconds format.

What's the point? I still have to prevent the pointer crashing FS, which is what I'm doing, and after that it looks like it doesn't matter.

The idea was meant in case it turns out later that it does matter.

No. They're not even using the same compiler. There's zero cross-compatibility for individual modules.

That's unfortunate. Thanks for the clarification.Cheers,- jahman.

Can someone test a high VAS usage at OLM - I believe that was around KSEA. On one page someone said flight with NGX to OLM caused 100% crash at or around OLM... make sure through LOD_RADIUS that your VAS usage climbs very high, around 3.8GB and test the area? That way we can also confirm ORBX-problem to have been "worked-around".

Can someone test a high VAS usage at OLM - I believe that was around KSEA. On one page someone said flight with NGX to OLM caused 100% crash at or around OLM... make sure through LOD_RADIUS that your VAS usage climbs very high, around 3.8GB and test the area? That way we can also confirm ORBX-problem to have been "worked-around".

Word Not Allowed, will try that as soon as I finish this flight, but so far on my PNW test flight, I flew right over KOLM and with VAS @ 3.4+, no crash..Alain from Montreal

My goodness, I didn't follow this topic for a few days and now we are at 20 pages and some sort of solution...? Can anyone tell me what exactly is the solution? Should I put that beta dll in my FSX folder or something...? What's the story?