Jump to content

G3d.dll Errors With Aes And 3gb Patch


Recommended Posts

  • Developer

Ok,

I think we can stop here for the moment.

The good news: I think I know what happens.

The bad news: I have no solution yet.

AES is not Compatible to the 3GB Patch auf the FS. It can work, but not allways.

Why:

AES is designed as a build in to the scenery engine of the FS, so that all the nice animation can be done.

The code needs to have access to a globle memory, so that all the variables can be stored outside the BGL code

area. Otherwise the objects can't be triggered based on the operation.

Therefore, Inteliscene provides operations to allocated memory and to provide offset to the access of this memory

to MS internal opcodes within the BGL Codes.

The MS opcode is limited to a delta in this offsets from -2 to +2 GB (long integer), as MS never think about larger deltas in the plannings.

Now, we get into the problem, that the BGL code is loaded and unloaded on runtime. This mean, the BGL code for AES is not allways in memory, only as long as it is needed. On flighttime, the Code is removed from memory and only loaded again, when you near to the airport. So far so good.

The IS allocaded memory is allways active in memory, as long as the FS is not restared.

Now, multible situation can happen:

You start the FS on a low memory consuming area (AES active)

- All codes and memory are within the 2Gb area, no problem all is fine

You start the FS in a heavy memory consuming area (AES active):

- FS load BGL code first, later he run this code, where IS will allocate Memory. As long as the BGL code and the Memory is within a 2G range, all is fine. If not, because the BGL code was loaded first and the IS Memory allocation is much later, when allready more then 2Gb is needed, AES will fail on access.

You fly from one Airport to the other:

- While the fight, the BGL code is gone out of memory.

- When you arrive at the destination, the BGL code is reloaded.

Depending on the situation on depature and arrival, it can now happen, that the offests between BGL code and IS Memory will be > 2GB, so it is possible that all works fine, when you start on a heavy load airport, but crash when you land on a low memory area.

Based on the different situations in load of BGL code, it could generate different siutation where the CTD happens.

The problem is, that we can't overrules the limits of the FS BGL opcode here, so even when we see, that the offset are to large, we only can stop operation (to prevent the CTD), but we can't bring AES to work.

I am now discussing the options we have with Maurizio, but I am not so optimistic that we find a fast and easy solution. In the worst case, we need a totally different approach to the complete product.

I am back, as far I see a way to solve this issue. Sorry.

Link to comment
Share on other sites

  • Replies 181
  • Created
  • Last Reply

Top Posters In This Topic

Hi Oliver,

I could not agree with your statement. I could only speak for my configuration for FS9, but the "magic" boundary seems to be nothing to do with 2GB. I can reproduce the CTD at round about 700-800MB which the FS9.exe is allocating. If more the FS9 is crashing at 6 mile final.

Possible that my problem is not related to the 3GB patch?

Stefan

Link to comment
Share on other sites

  • Developer
Hi Oliver,

I could not agree with your statement. I could only speak for my configuration for FS9, but the "magic" boundary seems to be nothing to do with 2GB. I can reproduce the CTD at round about 700-800MB which the FS9.exe is allocating. If more the FS9 is crashing at 6 mile final.

Possible that my problem is not related to the 3GB patch?

Stefan

But you have the FS9.EXE patched? If so, you never know, how Windows will controll the memory. It is possible, that them delta is bigger then 2GB, even when only 10 KB are used.

At the moment, I have no statement of any user, who uses the standard (non patch) FS9.EXE, that he has any problems like this. Ok, maybe OOM's but non AES related CTD's.

Link to comment
Share on other sites

But you have the FS9.EXE patched? If so, you never know, how Windows will controll the memory. It is possible, that them delta is bigger then 2GB, even when only 10 KB are used.

At the moment, I have no statement of any user, who uses the standard (non patch) FS9.EXE, that he has any problems like this. Ok, maybe OOM's but non AES related CTD's.

Make sense to test the unpatched FS9.exe? Then we have a clear statement if my posted problem is 3GB-patch related.

Stefan

Link to comment
Share on other sites

  • Developer

Only one point: Did you ever seen problems with your Aircraft Model or with AI Aircrafts, that Animated parts (Flaps, wheels and so on) will not work as expected?

Based on the situation, that MS will use the same Opcode for Memory switches within the Code of the Aircraft models, I is possibles, that with the 3GB patch, the Modelcode is also loaded at a area, so that the offsets to the Aircraft parameter block (which is the base values for the animations) is >2GB.

This situation can maybe happen more often, when you start the FS on a heavy memory using area with the cessna, an then later change the Aircraft complex model.

As there only read access will happen, this will not generate Crashes, but I would expect funny and unnormal movements of the animation. It's possible that you never see it, but maybe you keep an eye on it.

Ok, is only a sidenote.

Link to comment
Share on other sites

  • Developer
Make sense to test the unpatched FS9.exe? Then we have a clear statement if my posted problem is 3GB-patch related.

Stefan

As long as you don't get OOM with the unpatch Version, AES will work there. We have several users of AES, if this problem will be a "global" one with normal FS9.exe, we will not see only 2 pages here.

It is possible, that when your memory is full used and you come to the airport and AES must load, that no memory is available and this will generate other problems. Maybe the Teststep 6 code is more stayable in this case and maybe you get the "Memory Allocation" error or AES will not work.

Link to comment
Share on other sites

Only one point: Did you ever seen problems with your Aircraft Model or with AI Aircrafts, that Animated parts (Flaps, wheels and so on) will not work as expected?

No, never. As to my knowledge all the FS related addons are really working fine. I have never seen abnormal things like problems with animated parts. Also no problems with complex airliners like FMC crahes with PDMG/LevelD/Maddog. The only problem are these CTDs on final. And turing off AES solves this Problem.

Stefan

Link to comment
Share on other sites

Only one point: Did you ever seen problems with your Aircraft Model or with AI Aircrafts, that Animated parts (Flaps, wheels and so on) will not work as expected?

No I have never had this problem. The 3GB patch seems to work wonders for me. I have not had a CTD, visual anomalie or OOM error since applying it.

Thank you for looking into this issue Oliver. From a support stand point at least I know you are looking into the problem and trying to find a soloution. That means alot to me as a customer.

I do think that as time wears on more and more users are going to need the 3GB fix. And even more so when AES gets ported over to FSX.

Link to comment
Share on other sites

The problem is, that we can't overrules the limits of the FS BGL opcode here, so even when we see, that the offset are to large, we only can stop operation (to prevent the CTD), but we can't bring AES to work.

I would be happy with that as a short term fix. At least I won't lose seven hours of flying on finals. Landing with no AES active is far better than not landing at all.

Link to comment
Share on other sites

Thank you for looking into this issue Oliver. From a support stand point at least I know you are looking into the problem and trying to find a soloution. That means alot to me as a customer.

I totally agree that the AES support is really outstanding! I have in mind that this problem is related to something which is not easy to solve and such things can happen.

Please allow me a feature request: Is it possible to init AES only when the aircraft is on ground? Based on a config entry or so? Then we can use AES for pushback (main feature for me) and on landing AES does not an init with possible crashing. Not really perferct but much more better then removing AES completly until the problem is solved. (If you are able to solve this).

Stefan

Link to comment
Share on other sites

I totally agree that the AES support is really outstanding! I have in mind that this problem is related to something which is not easy to solve and such things can happen.

Please allow me a feature request: Is it possible to init AES only when the aircraft is on ground? Based on a config entry or so? Then we can use AES for pushback (main feature for me) and on landing AES does not an init with possible crashing. Not really perferct but much more better then removing AES completly until the problem is solved. (If you are able to solve this).

Stefan

So just my .02 and a quick question because I use /3gb /usernv-2560 with dual 8800 GTX cards and I have never seen this error.

BUT and it is a big but...

# 1 I am always flying to/from AES airports to the best of my knowledge...

# 2 I have KEWR set as my default flight with KEWR AES enabled. Hence, AES is ALWAYS loaded when my FS starts.

# 3 I have de-bloated FS... I use FSM and by default have ALL of my add-on airports inactive. Then before each flight as part of my pre-flight routine I only activate the scenery I need for that flight.

I found that having all of my add-ons active caused all sorts of issues with filemon. sometimes FS looked for Asia scenery when in NY LOL, but more importantly on KEWR- LEMD if I had all add-ons active I would pass KEWR (AES active, LGA AES Active and then Boston before even leaving the East Coast. In theory this means 3 major scenery loads + 3 AES loads. By de-activating everything but my departure/arrival airports I save massive amounts of FS Lookups and loads...

and

to SFox, when you are talking 7-800 meg of memory, that is physical. the limits of XP are virtual and Physical... Just because physical usage is at 7-800 megs, total usage can be at 2 gigs. The bigger issue is total usage can be at 1.9 which is fine but then a scenery comes along requesting 300 megs and you broke the bank ;)

Just some more fuel for the fire. Great job with support as always Oliver.

-Paul

Link to comment
Share on other sites

Hello Oliver,

sorry for my late reply...was a little busy the last couple of days.

To answer your questions:

Q1: Yes, I do use the /3GB-patch

Q2: - If I start up with a Cessna at an AES-airport with low memory requirements and then go to my memory intense departure/test-AES-airport -> all good.

- Then choosing a memory intense aircraft works fine as well.

- After following this pattern, the CTD-probability on final approach to another AES-supported airport with heavy memory load is about 30% - 50%.

Besides, I totaly have to agree with the others that the support of Aerosoft and especially also your´s is just terrific!!! Thank you very much for trying to help us out and for still not giving up!

Regards,

-Tetiaroa!

Link to comment
Share on other sites

  • Developer

Ok,

good news: What I expect regarding the Offset relative to the Varbase opcode could not be the reason for the CTD#s, because the memory address written there is absolute, so it is unsigned in the range of 32kb to nearly 4GB.

As long as you don't use a 64bit with more then 4GB Ram, nothing should happen here.

But I extend my allocation protection to check, if the written address is maybe within a not allowed range of -32768 to +32767 (this are local offset for Varbase opcode), which will definitiv gernerate a CTD.

So please try the attached Test Step 8 (replace the BGL inside in the ..\aerosoft\AES\SCENERY directory)

When all went ok, you will see the following (press F1 to continue):

- two times window with number 00

- several window with number starting -1 up to 37 (serveral time 17 between)

For me is interesting, what is the last window before the CTD (@altstiff: I would expect, that it is not 23 now?!?)

Give me a feedback sasp, Thanks.

Link to comment
Share on other sites

Alright, tested the file, but unfortunately still:

T1: Directly after startup situation is loaded before hitting F1 even once -> CTD ("g3d.dll")

T2: same as T1

T3: not tested as T2 didn´t work

Cheers,

Tetiaroa

Link to comment
Share on other sites

  • Developer
Alright, tested the file, but unfortunately still:

T1: Directly after startup situation is loaded before hitting F1 even once -> CTD ("g3d.dll")

T2: same as T1

T3: not tested as T2 didn´t work

Cheers,

Tetiaroa

Ok,

can you test T1 once more with the attached file (keep the others as in Step 8), please?

EDIT: And please uncheck the AESLiteforGAP-EDDF in the scenery library for this scenario, if test fails!

Link to comment
Share on other sites

Getting closer!!

T1 and T2 with "AESLiteforGAP-EDDF" activated and "Test_Step_8a.zip" installed -> CTD

Without "AESLiteforGAP-EDDF" and "Test_Step_8a.zip" installed :

T1 and ALSO :rolleyes: T2 stable - even up to AES loading-numbers higher than 100, no matter how fast I hitted F1!

Verified result by testing default AES v1.95a again - also without "AESLiteforGAP-EDDF" -> CTD as expected

Seems like quite an improvement, doesn´t it?

Link to comment
Share on other sites

  • Developer

Hi,

yes, your problem was diffentent for the others, because you get the CTD direct before AES Windows comes up.

So, forget Test Step 8a, go back to Test Step 8 and then replace the file with the attached from Test Step 9. Step 9 is full working, no window. When you get a CTD, go back to step 8 and try to rebuild the situation.

When step 9 is ok with AESlite off, then enable AESlite, but rename the File EDDF_BAB.BGL to EDDF_BAB.off, which you find in ...\Aerosoft\AESliteforGAP-EDDF\SCENERY

This file also use IS Memory, but is not protected yet. So here you will get the CTD.

Link to comment
Share on other sites

Whoohoo!!!

Okay, also step 9 is working well so far (tested T1 and T2 -> no CTD) :rolleyes::rolleyes:

Unfortunately, with active AESlite I still get the CTD even after renaming EDDF_BAB.BGL to EDDF_BAB.XXX. Maybe there´s another .bgl-file in that "AESliteforGAP-EDDF\scenery" folder that needs to be patched?

Link to comment
Share on other sites

  • Developer
Whoohoo!!!

Okay, also step 9 is working well so far (tested T1 and T2 -> no CTD) :rolleyes::rolleyes:

Unfortunately, with active AESlite I still get the CTD even after renaming EDDF_BAB.BGL to EDDF_BAB.XXX. Maybe there´s another .bgl-file in that "AESliteforGAP-EDDF\scenery" folder that needs to be patched?

Fine,

but I did not think there is another file using the memory allocation, but you can rename also the EDDF_DYN.BGL, the other two are only Librarys, they are not called, when the other two files are not active.

When the DYN file is responsable, try the attached one.

Link to comment
Share on other sites

Actually the "EDDF_DYN.BGL" seems to be responsible for the CTD, renaming it to "EDDF_DYN.XXX" prevents the CTD even with "EDDF_BAB.BGL" being active.

So I tried the "EDDF_DYN.zip", but unluckily it still causes a CTD.

Link to comment
Share on other sites

  • Developer

Ok, forget the DYN BGL for the moment. Let us keep the eye on the AES files. Maybe a special condition on your PC.

Do you have GAP EDDV (Hannover) installed?

Link to comment
Share on other sites

No, I don´t have Hannover...even though I consider getting it ;)

Could it cause problems?

All I have in the area of Germany are EDDF GAP1 (EDDM,EDDS,EDDN...), German footbol stadiums, the freeware version of Hahn airport, Neuburg AB by www.german-virtual-airforce.de, UT-Europe, a Landclass-file and QLRP4UT.

Ok, so what are we gonna do next?

Link to comment
Share on other sites

  • Developer

Ok,

no, it's not a problem that you don't have EDDV, only if so, it could be that the DYN file of EDDV has a conflict with EDDF. But, so no problem.

Yes, fly and check, if you get a CTD again, if not, we can look for the DYN file later.

No, I wait for a response of the other users here.

Link to comment
Share on other sites

Great, I´ll go right ahead testing flights and report back as soon as I got some news!

THANK you so much Oliver, you´re simply fabulous!!!

Link to comment
Share on other sites

OHHHH NOOOO, got bad news again!

Tested NonAES-Airport to AES-Airport and 6 miles from the threshold of the RWY on final, I got the CTD again! :(

Flew EIDW-EDDF, AESlite active (DYN BGL renamed to .XXX) and AES with the latest modifications installed.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy & Terms of Use