Fatal Error at YBBN

[normandean]

With the 1.1 patch there are still fatal errors occuring at YBBN. The faulting bgl appears to be GAApron.bgl, but it would appear that either InternationalApron.bgl or NortherMaint.bgl must also be active, so it could be an incompatibility betweeen them. The runway and taxiway aprons are not affected.

To check it out fly an approach to runway 01 and the error will occur at just below 1000ft, after the landing clearance has been given.

Norman

[John Dow]

In several hundred approaches and circuits of YBBN I've never had a fatal error, except once I had a lockup in the early beta at dusk due it would seem to texture overload with both sets of textures (day and night) being called.

This info might not help you but it might point to your problem being related to your hardware rather than the YBBN coding?

[flyguy737]

doesn't happen to me

[Russ White]

Fatal errors were a cause of the system memory being saturated by the high resolution aprons. The 1.1 patch provides the option to turn off these high memory usage apron textures and use lower resolution native 15cm alternatives which erradicates the fatal crashes and memory issues. This has been fully tested before release and no fatal issues were ever found.

I suggest the conflict you are having is with another third party addon you may have. We have found that UT2 caused some fatal crashes at YBBN with some customers so check this in your circumstance. Please let us know what other flight sim addons you have, especially anything that deals with AI traffic etc.

Russ.

[normandean]

Hi All,

I have been a member of a scenery design team for many years, and also a beta tester for several others, so am well aware of the factors that can or cannot cause problems with scenery. I'll post my specs at the end of this message, but to cover Russ's point, I do use UT2, but have tried with that enabled and disabled.

So I will make the following points:

1. No matter how good your beta testing is there is always the possiblility of a user that finds something that was missed. I know, having spent many hours trying to find and correct a problem. However, when there is a specific, repeatable and demonstable incident at one location then there is something to investigate.

2. If you cannot reproduce the problem yourself it is very difficult to positively overcome it or deny it. I have often been in this situation, and yet by simply re-compiling the file and then getting the user reporting to test it the problem has been solved. You need to bear in mind that just because you cannot replicate a problem that doesn't mean it does not exist. Having suffered two or three fatal errors at YBBN I searched the forum and found three other reports, plus several reports of crashes at YBBN with no cause stated. After several hours of disabling and enabling files I have found that I can now reproduce this problem 7 times out of 10.

3. It may be speed connected. I can demonstatre it with the Epic Victory and the JS41, but not with the default A320, so speed of approach (and thus the speed at which files are called) may be a factor. I have also found that whether you fly a manual or auto approach you must be exactly on the glide slope.

4. I have enough experience to know that other factors may influence a situation. To this end I only have the FTX, OZx and Ant's Aussie airports in the scenery cfg that I have used.

6. Being experienced at beta testing I have run this test again and again before reporting. However, as a beta tester I know that I report what I find, but it is entirely up to the product designer whether thay take any action as a result.

I can simply remove the file GAAprons and there is no problem for me, so it isn't a great deal in my situation. I simply report for your information.

My system specsa are:

System

Mother Board Asus Rampage Extreme 2 X58

CPU Intel i7 920 verclocked to 4GHz

Memory Corsair XMS3 DDR3 PC3-A280C9 6GB (matched chips)

Graphics Cards Gainward nvidea 285 gtx 1000 MB cache

Driver nvidea 257.15 (I also used 197.45)

Case Enermax CS 718

PSU Hiperpower 880 Watt

Monitor HP f2105

HDD

All SATA and NTFS

1x 156GB WD Raptor

1 Partitions

1. OS and all general programs, data storage.

1x37.6GB WD Raptor

1 Partition

1. FS9,

1x500 GB WD Caviar

2 Partitions

1. FSX Program

2. Backed up downloads and UK2000 AFCAD library.

1x1000 GB WD Caviar

2 Partitons

1.FSX Scenery, Horizon Gen X, Addon Scenery from VFR Addons

2. Work shop

3. Spare

Joystick Saitek X52

Track IR5 with PRO clip

Norman

[Russ White]

Thanks for the info Norman, since you are a beta tester and designer yourself there's no need for me to continue the "layman's" approach.

As you will no doubt know, the bgl's you reference above are essentially GP's that contain polygon, vert and Tvert information condusive with displaying mapped textures on surfaces to combat the negative effects of MIP lag inherent with ground image BGL's. Therefore these apron BGL's have very little influence on the operation of the sim it'self, but do have a large texture call requirement. Lower spec machines may suffer from system memory saturation and subsequent crashing or freezing of FS with these apron BGL's in use. The v1.1 patch for YBBN enables you to disable all of these GP's thereby negating their large texture load requirement on the sim and the system, alowing the user to rely on the 15cm ground BGL apron images only.

Hopefully by using the new control panel options available in v1.1 you are able to turn off these GP's and free yourself from this fatal error. If the problem still persists after utalising this new feature then (as you will know) we will have to start using a process of elimination routine to identify the culprit, which, i suspect will be a conflict on your system somewhere. From your above post the first place i would start looking would be Oxz, we already know there is a potential scenery conflict as Ozx also provide a freeware upgrade to the Brisbane port area. Installation of Orbx YBBN should remove the Ozx Brisbane scenery but there is a chance this has either not worked in your case.....or you installed Ozx AFTER you installed YBBN.

I would therefore ask that you run the "Remove_OZx_YBBN.bat" file located in your ORBX\Scripts folder and report your findings back here.

Russ.

[normandean]

Ah, thanks for that explanation Russ. I really don't think is is a hardware issue, but I didn't realise that there was an OZx file that could be in conflict. I will therefore take a look and see if this is the case, and report back.

Interesting that you have addressed the problem associated with polys with a surface texture, but as you say it may clear up the "flashing" and mip lag that can occur but at the expense of heavier texture loads.

Norman

[Martin Henare]

What might help is a screenshot with the lat long of where the ctd occurs.

Also can you clarify what is meant by an error. Is it a crash to desktop, a freeze with a error message or some thing else?

The GAApron is one of the smaller ground polys but is no different from any of the others in terms of compile or settings.

[normandean]

Hi Martin,

By Fatal Error I mean the infamous warning that you get with FSX after a screen freeze. The screen freezes, then after about 30 seconds the sim closes with a warning message A Fatal Error has Occurred. It generally means a conflict with a bgl, either because the sim cannot find it or there is something in the structure that causes a crash. This is not the only cause, but it is due to a graphic problem and is usually the bgl problem. In the case of YBBN it can occur no matter what heading you have TOWARD the airfield and has happened to me on three or four occasions at 29 miles DME. However, the one I have been able to reproduce almost at will occurs when you fly an auto or manual approach to 01 and comes when you are at about 800ft or a minute or so from touchdown. It is generally just after ATC gives landing clearance. By elimination I have found that it is the three bgls I have listed above, but GAApron.bgl has to be active for it to happen, the other two will not cause the error if that file is inactive. However, I don't think it is down to graphic load, at least that is not the major factor, because the error occurs if all the other apron files are made inactive and only the GAApron bgl is live.

It doesn't happen every flight, and I have flown circuits at YBBN with no problem at all, but I had two or three flights when it occurred at 29DME and I can make it happen if I fly an approach to 01 from about 30 miles out in 7 out of 10 times.

Russ suggested running the bat file again, but that made no difference. It is not a big deal, as I can simply make GAApron inactive, but it just bugs me.

I also think it could be the root cause of the some of the other posts about program crashes at YBBN.

Norman

[John Dow]

Just a thought and a bit of a long shot...

I noticed in your other post you say you have FSGenesis mesh installed.  I don't suppose there is any chance that you have he FSGenesis mesh active for the YBBN area as well as the Holgermesh, and whatever mesh corrections were made in the YBBN package?  Just a thought that probably won't lead to anything meaningful )

[normandean]

Hi John,

MSFS generally uses the mesh with the highest LOD, but its worth a try.

Many thanks for the thought.

Norman