Die Meldung ist exakt diejenige, die man bei einem Speicherleck erhält, wie es z.B ein Landclassfile im FS2004 verursachen kann.
Wobei die Aussage, dass ein Landclassfile nicht in einem Sceneryordner sein darf falsch ist.
Denn immer wird ein Landclassfile in einem Scenery Ordner stehen müssen, denn das ist die Struktur des FS.
Richtig ist:
Immer wenn ein Textureordner parallel zu einem Sceneryordner liegt in dem sich ein Landclassfile befindet, dass hier alle Texturen und Steuerdateien die zum Betrieb dieses Landclassfiles nötig sind vorhanden sein müssen.
Wenn nicht tritt das Speicherleck ein. Umso mehr Texturen fehlen umso schneller wächst das Speicherleck.
Da ist es natürlich logisch, dass ein leerer Texture Ordner der parallel zu einem Scenery Ordner mit Landclassfile existiert absolut tödlich ist.
Da ist es natürlich sinnvoll, dass man so einen Textureordner löscht.
Denn ist keiner vorhanden paasiert auch nichts.
Wie gesagt hat man aber einen Textureordner und es sind die benötigten Texturen vorhanden dann geht das OK, es kommt zu keinem Speicherleck.
Sehr viele Scenerydesigner gehen so vor, denn so lassen sich eigene individuelle Texturen unabhängig von den Default Texturen des FS verwenden.
Gefährlich wird es, wenn Designer aus Unwissenheit ein Landclassfile BGL z.B in einer Airportscenery unterbringen. Denn die wird immer einen Textureordner für Gebäude usw. haben.
Der Texture Ordner ist also da, es fehlen aber ev. die Landclasstexturen.
Also Peng Speicherleck.
So wird es hier wohl sein.
Es ist extrem wahrscheinlich, dass es sich bei oben erwähnten File um ein Landclassfile handelt.
Prüfen kann man das übrigens mit dem SDK Tool TMF Viewer.
Sollte es so sein und es handelt sich um eine Scenery die einen Textureordner hat (die Landclasstexturen selbst fehlen aber), dann muss das Landclassfile raus aus dieser Addonscenery.
Man kann es notfalls als eigene neue Scenery anmelden. (ohne parallelen Texture Ordner)
Übrigens ich beschreibe in meiner Doku auf
www.jobia.de ein Scanverfahren, wie man den kompletten FS nach diversen Scenerycodes abscannen kann.
Man muss also nicht nach Namen von potentiellen Dateien fahnden bzw. mit dem TMF Viewer im Vorfeld ev. auch unwahrscheinliche Dateien prüfen ob es nicht doch ein Landclassfile ist.
Mittels dieses Verfahren scannt man den FS automatisch nach gewünschten Code ab.
Das geht bei Einzelscenerien extrem schnell.
Beim ganzen FS kann man ev. auch schon mal ein Bierchen trinken.
Aber immer noch schneller als mit anderen Verfahren nach Landclassfiles zu suchen.
Eine andere Methode wäre über dass Tool Filemon.
Hier könnte man fehlerhafte TexturDateizugriffe während des Betriebs überwachen.
Das Landclassspeicherleck entsteht nämlich durch erfolglose Texturdateizugriffsversuche des FS im zugehörigen Textureordner.
Da er dort nichts findet lädt er alternativ Defaulttexturen.
Leider versucht er dieses ständig erneut.
Das Speicherleck schreitet voran, siehe auch meine Dok.