Das hast Du jetzt aber zum Schluss ganz falsch verstanden gehabt. Es geht hier nicht darum das ich irgendeinen Vergleich zweier Dateien anzweifele.
Logisch wenn der Bytecode einer Textur identisch ist, die Datei den selben Namen trägt, dass sie dann auch später wenn sie zugewiesen wird absolut identisch aussehen wird.
Das ist doch nicht das Thema.
Was ich sagen will, ist das selbst dann wenn man sichergestellt hat das Texturdateien in zwei verschiedenen Pfaden 100%tig identisch sind, nicht einfach eine der beiden Texturen löschen darf.
Genau darum ging es in dem Thread. Das löschen doppelter Texturen.
Es ist sehr gefährlich Texturen identischen Namens zu löschen wenn sie vom Bytecode nicht identisch sind. (sie tragen den selben Namen, sehen aber anders aus).
Weiterhin ist es genau so gefährlich Texturen identischen Namens zu löschen selbst wenn sie 100% tig identisch sind also optisch gleich aussehen.
Kommt halt auf die zuweisende Scenerytechnik an ob Gefahr in jedem Fall besteht.
Ich vermute Du hast mein Landclassbeispiel oben nicht verstanden und bist darüber gestolpert.
Daher ein Beispiel. Die Default LC Texturen sind bei mir in folgendem Pfad zu finden:
E:\FS2004\Scenery\World\texture
Auf diese globalen Texturen greift das Default Landclassfile des FS2004 zu.
Installiert man jetzt LC Addons als eigenständige Scenery """"ohne eigenen lokalen Texturordner""""" dann greifen diese LC Addons auf die Landclasstexturen in oben erwähnten globalen Texturordner zurück.
Erzeugt man zum Landclassaddon einen eigenen """"leeren"""" lokalen Texturordner dann kommt es zum Speicherleck.
Der FS2004 interpretiert hier irgendetwas falsch. Er sieht aha es ist ein eigener lokaler Texturordner da, dann nehme ich doch mal die Landclasstexturen aus diesem lokalen Ordner. Die müssen technisch bedingt die selben Namen haben wie die in oben erwähnten globalen Pfad, sonst funktioniert es nicht.
Aber ich erwähnte, dass der geschaffene Texturordner leer ist. Der FS merkt, oh da sind ja keine Texturen also muss ich doch in den globalen LC Texturordner schauen, also lädt er sie von dort.
Bei einer LC Scenery ist es aber so das während des Fluges ständig neue LC Informationen nachgeladen werden.
Der FS2004 schaut jetzt zunächst mal nach wurde denn schon aus meinem lokalen Texturordner etwas geladen.
Nein, denn der war ja leer. Das dumme ist, er ignoriert jetzt die ev. bereits geladene Textur des globalen Texturordners. Er lädt die benötigte Textur erneut.
So geht das Spielchen immer weiter bis die Auslagerungsdatei überläuft und der FS crasht. Das ganze kann man sehr schön mit Landclasstestscenerien simulieren.
Das zunächst zum Crash Problem wie es entsteht.
Jetzt soll sich der Kreis zu den doppelten Texturen schliessen.
Natürlich sollte mittlerweile jeder wissen, das man keinen leeren Texturordner haben sollte.
Aber es macht natürlich hin und wieder Sinn, dass man einen eigenen Texturordner bei Landclasscenerien hat.
Da wäre z.B die ATP das Beispiel.
Dort möchte man anders aussehende lokale Landclasstexturen nutzen.
Also legt man einen eigenen lokalen Texturordner an.
Die Speicherleckgefahr ist gegeben sobald eine in dem Landclassfile zugewiesen Textur fehlt. Das vermeidet man natürlich indem man darauf pingelig achtet, dass die zugewiesenen Texturen auch vorhanden sind.
Hier kommen jetzt also die lokalen LC Texturen rein.
Diese anders aussehenden lokalen Texturen müssen aber identischen Namen haben wie die im globalen Ordner.
Mit einer reinen Suche nach doppelten Namen wird man also Texturen im lokalen und globalen Texturpfad finden die von Namen identisch sind.
Von der Optik weichen sie ab.
Löscht man jetzt einfach Texturen kommt es zum Crash des FS.
OK wir sind schlau, wir suchen nicht nur stur nach Namen wir vergleichen auch den Dateninhalt also z.B den Bytecode der doppelt gefundenen Texturen. Wir stellen fest, ok sie haben identische Namen aber wohl verschiedenen Dateninhalt.
Wir sind jetzt also so schlau, dass wir wissen, wir dürfen hier nicht löschen, weil erstens die Optik des Addons nicht passen würde und weil wir ein Speicherleck produzieren.
Wenn das Tool dieses alles berücksichtigen würde, dann hätten wir bis hierhin fast ausgesorgt. Aber nur fast.
Denn wenn ein Addonproduzent der Optik wegen eigene Texturen einsetzen möchte, dann gibt es Fälle wo er nur ein paar wenige Texturen austauschen möchte, der Rest soll Defaultoptik behalten.
Da aber sobald ein eigener lokaler LC Texturordner existiert """alle"""" im LC File zugewiesenen Texturen (auch die die keine andere Optik haben sollen) hier auch vorhanden sein müssen, wird man Texturen finden die im Namen mit dem globalen Pfad identisch sind im Bytecode abweichen, aber auch welche die von Namen und vom Bytecode identisch sind. Also 100% tige Doubletten.
Selbst wenn dieses Tool nur die 100% identischen Texturen als löschbar ausweist, darf man sie in diesem Fall nicht löschen sonst hat man das Speicherleck.
Möchte man eine LC Scenery wie oben realisieren, kann man zwar konstruktionsbedingt diese Problematik beheben nur das macht nicht jeder Designer.
Ich selbst habe obige Konstellation schon bei Addons (nicht bei der ATP) gesehen.
|