Landclass or mesh causing memory leaks?

I seemed to have an issue at one airport, FRF’s NFFN. I added some freeware landclass the and the 70m fresh mesh. It’s looks great. But it leaks memory like a sieve. Before I’m ready to push back, I’m up to 3.3 to 3.4 Gb virtual memory used. I don’t see anything in the airport scenery that would cause that much leakage. So I’m thinking maybe the LC or Mesh? I always end up with a OOM after departing here.

 

I’ve heard that LC is better in the Scenery/Base/scenery folder. Not sure why. But it won’t leak memory if added their instead of to the Addon Scenery folder where mine is. I’ve never heard that before. I think FS9 has a default World LC file in their already. Maybe that’s the problem? Conflicting somehow?

 

Any help appreciated. And an award of $25,000 USD if you help me track down the culprit.

Actually I take all that back. It’s the FRF NFFN airport. More memory loss then Senate inquiry to an unsanctioned CIA operation.

 

Not sure what is causing it. I guess over a beer or 6 I’ll discover it.

 

Edit : the airport scenery also had its own landclass files in it I think. As now Fiji is quite bare. So maybe that is what’s causing the leak. Dunno.

 

Also glad I can publicly express my thoughts rather then keep them to myself. :p :D

 

 

EDIT #2 : I don’t think now it IS the FRF scenery rather then some Lc files for Fiji I dropped Into the airport scenery folder. Interesting. Maybe a bad idea.

Edited May 23, 2021 by JSMR

That idea that it is caused by some land class dropped into the airport folder that already included some other land class files sounds to me the likely cause. They "start arguing with each other" and eat up memory.

I've seen lots of posts about scenery problems, I've had few myself with conflicts even some with reputable companies payware software.

 

I had one a while ago where there was a building across the taxiway, I went on their forum and posted the screenshot but they argued I had some other scenery that had done it and I hadn't, even another poster came on a ridiculed me saying I probably didn't know what i was doing etc, I retaliated but it was getting out of hand so I let it go.

 

Col.

That idea that it is caused by some land class dropped into the airport folder that already included some other land class files sounds to me the likely cause. They "start arguing with each other" and eat up memory.

 

 

Ah..yes, that makes sense. I figured that would be an issue. I get lazy sometimes and drop Lc, mesh, city buildings etc all in the airport scenery folders. I’ll make a new Lc scenery folder and add it separately.

 

So, winner winner chicken dinner!

$25,000 usd is yours. It’s available as travellers checks in Rubles. Head downtown near Moscow Square, and you see a small currency exchange, ask for Anatoly, he’ll fix you up.

In my experience this problem of memory leaks caused by landclass files has been successfully fixed by doing one thing - putting these files into a scenery folder that has NO texture folder alongside it. So you create a new folder in the Addon Scenery folder, and just a scenery subfolder inside that - NO texture subfolder. I put all landclass files that come with airports, etc. into that scenery layer's folder and have had no problems with memory leaks again. You do have to look out for them, because they can indeed be mixed in with the other airport BGL files.

 

Hope this helps,

I’ll make a new Lc scenery folder and add it separately.

 

Tom beat me to it, offering the same solution in fewer words...

 

I've been aware for many years of landclass causing memory problems. Recent (last few years) advice for FS9 has been to keep landclass packages in their own dedicated scenery layers and to have no associated local Texture folders.

 

Your question prompted me to look a little harder for an explanation.

 

This 2006 post by Holger in another forum gave the info I wanted and expands on the 'No Texture folder' generalisation:

 

'Land class files call land use texture bitmaps, which by default reside in Scenery/World/texture. If a landclass file is in an add-on scenery folder *without* a parallel texture folder FS will look for and find those textures in Scenery/World/texture without problems.

 

However, if there is a parellel texture folder, empty or not, then FS will search in that texture folder first. If it finds *all* the bitmaps it needs (classes, variants, and seasons) then things are fine. If even one bmp set is missing then FS will still find the textures in Scenery/World/texture but at a price: for some reason, FS keeps loading the bitmaps missing from the local texture folder over and over again, until your computer runs out of available memory and shuts down.In other words, the memory "leak" is actually a memory overflow.'

 

I guess it's difficult to determine whether a LC package calls only its own custom textures or if it also uses some from the default folder.

 

So if a LC package comes with any custom textures, it may be best to put those all into Scenery/World/Texture and to create a LC scenery layer with no Texture folder. That should avoid the multiple-load overflow caused by FS9 searching two locations for textures.

 

(How do I prevent the forum from upscaling small images?)

 

 

Edited May 23, 2021 by defaid

So what you are saying if I read it right, I put some scenery in the scenery folder that has a sub folder, and as you say if one texture isn't there then are all the textures in that folder overwritten and not used and then the default ones are put in instead?

 

Col.

Not quite.

 

If you have a landclass BGL in a scenery layer, FS9 will look for the relevant terrain texture files in the local ../Texture/ folder.

 

If it doesn't find them all then it will look in ../Scenery/World/Texture/ where all the default terrain texture files are kept.

 

It will then take what it needs from there.

 

FS9 won't be working from disk. In essence it puts a working copy of the relevant terrain textures into RAM to avoid the necessity of re-reading your HDD or SSD.

 

There must be a bug in FS9, an oversight in the coding. It means if FS9 has to redirect its search from the local ../Texture/ folder to the stock folder in order to find any bits that are missing, it will continue to create multiple working copies of those default files in your RAM, until there's no space left.

 

OOM crash.

 

It's a specific situation: it only happens if there's a local ../Texture/ folder for FS9 to examine first, and if it has also to check the default folder.

 

If there is no local ../Texture/ folder then FS9 goes straight to the default and the shitty loop won't happen.

 

If there is a local ../Texture/ folder and if everything it needs is in there, the shitty loop won't happen.

 

If it has to check two folders for textures... it will happen and your RAM will fill up.

 

That means you either have to be absolutely sure that all the required terrain textures are in the local folder so that FS9 doesn't have to look elsewhere, or that there's no local ../Texture/ folder to prompt the loop the loop the loop the loop the loop situation.

 

It's simplest to put your landclass BGLs in their own layer which has no ../Texture/ folder, as in my oversized picture and as Tom suggested.

 

D

 

I have to stop editing now. I need a break...

Edited May 23, 2021 by defaid

Ah, forgive my ignorance I'm not that well up on scenery stuff, but your explanation was great and hopefully it will help many more in understanding this problem.

 

Again thanks.

 

Col.

Good tips. Thanks everyone. I should’ve realised after dropping Lc bgl’s in to airport scenery folders. I learnt my lesson.

I’ve probably done it in many other areas which is the problem. Maybe I’ll find out the hard way again.

Thank you both. I hope it made sense -- I had to stop editing as I just kept adding bits. I could have got the important info across in about 1/5th of the words...

 

It is worth noting (here we go again) that the loop only happens with LC.

Great stuff, thank everyone!

Thank you both. I hope it made sense -- I had to stop editing as I just kept adding bits. I could have got the important info across in about 1/5th of the words...

 

It is worth noting (here we go again) that the loop only happens with LC.

 

 

Yeah it’s made sense. I mean, that’s been the deal for quite some time. I thought I could skirt around it by dropping some LC, mesh, buildings, etc etc for the local area around an airport into the airport scenery folder thinking it would work. Which kinda does, but mostly can lead to these issues. Serves me right for being lazy and not creating a seperate landclass scenery folder. But it’s always a nice reminder.

 

The interesting thing is, the sim would crash, and I’d get all kinds of errors, not all oom messages. TERRAIN.DLL, G3D.DLL, INS, gua, SIM1.DLL errors.

I guess the sim gets stuck at some point, runs out of memory and just links something to the log files maybe. Not sure.

Every time before though I’d check Process Explorer and see the VAS peaking. Once I removed the offending files, it went from over 3-3.5 GB just at the airport to only 1 for the entire flight.

 

 

 

[ATTACH=CONFIG]226310[/ATTACH]

 

 

Here’s the real question. What IS that thing?!!!!!!!!

:p :D ;)

Here’s the real question. What IS that thing?!!!!!!!!

:p :D ;)

 

Umm... early version Win 10 dark theme for photographers in the evening? The standard bright white background is really bad for colour & contrast perception when photo editing.

 

Unless I'm missing something. (Other than Windows XP, which allowed persistent customisation of individual folder windows).

 

Why's it so big?

Well, you learn something every day. Never knew it existed. To be honest it was the font. Gotta a cool retro feel about it. And I’ve never heard anyone complain about their attachment being ‘too big’. :p