Find all Duplicate Version 2.0
 

Hallo,
ist Euch dieses Programm bekannt ? Ich habe es bei Faitmain.com gefunden und es dient dazu doppelte Texturen usw. zu suchen und zu eliminieren (bei mir wurden ca. 400 Duplikate gefunden)
Eigentlich ein Must-Have
Grüsse
Rainer

Hallo Leute,

benutze auch ganz gerne dieses Programm, welches die Anzahl der angemeldeten Texturen z.T. drastisch verringert.

Hat jemand Erfahrung, ob es damit auch zu einer besseren Performance kommt?

Happy Landings!
Fritz

Gibt es einen direktlink???
Ich komme nur auf die Francesim seite .... und dann kommts zum Sprachkonflikt ;)

hier...
 

bitte der link zu avsim:

http://library.avsim.net/download.php?DLID=41229

Ohhhh...danke!

Da haett´ ich auch drauf kommen können.
Sorry:tux: und vielen Dank!

Wieso must-have? Doppelte Texturen tun doch nicht weh, außer dass sie ein paar Byte Festplattenplatz brauchen. Im Gegenteil, es ist eher ein don't-use, weil danach plötzlich Texturen an Stellen fehlen können, wo sie gebraucht werden.

Ganz doofe Frage:

Aber woher weiß ich welche Textur überflüssig ist und welche gebraucht wird?

Gruß Dirk

Einfach mal...
 

... die sehr ausführliche Readme-Datei, die bei dem Tool dabei ist lesen und alles wird etwas klarer ;)

Hallo Leute,

erst einmal vielen Dank für das große Interesse an diesem Thema!

Verstehe ich den Beipackzettel also richtig, daß mit dem Programm der Arbeitsspeicher entlastet werden müßte?

Happy Landings!
Fritz

Zunächst mal wird man nie zwei identisch benannte Texturen in einem Texturordner finden können.

Dann gilt das was Hans schon sagt, es ist äußerst gefährlich doppelte Texturen zu entfernen. Man gefährdet die Funktion des FS auf das

!!!!!!!!!!!!!!!!!Äußertste!!!!!!!!!!!!!!!!!!!!!!!! !!!

Diese Texturen werden wegen meinem ersten Satz oben zwangsweise in verschiedenen Ordnern zu finden sein.



Nehmen wir nur mal das Beispiel GAP (die FS2002 Versionen, die bei einigen aber auch im FS2004 verwendet werden).

Da werden Texturen z.B für die Rasenflächen genutzt die auf Landclasstexturen beruhen. Man wird diese Texturen im Landclasstexturordner finden und mit identischen Namen im Haupttextureordner des FS. Denn da kopiert sie der GAP Installer hin.

Löscht jetzt jemand die als doppelt gefundenen Texturen im Haupttextureordner des FS, dann schafft er sich das GAP Problem mit den weissen Oberflächen, da Texturen fehlen.

Löscht er im Gegensatz die Landclasstexturen mit identischen Namen, hat er wenn er in der Gegend umherfliegt wo diese Texturen über eine LC Nummer adressiert werden einen Crash to Desktop.


Nächstes Beispiel Austria Prof. Diese bringen bekannterweise eigene Landclasstexturen mit. Genau genommen handelt es sich bis auf einen Texturset um farblich geänderte Defaulttexturen. Der Bildinhalt ist der selbe nur die Farben halt nicht.

Diese eigenen Texturen müssen damit es funktioniert die selben Namen tragen wie Defaulttexturen. Löscht jetzt hier jemand diese vom Namen doppelten Texturen kommt es zwar nicht zum CTD allerdings werden anstatt der fehlenden farblich veränderten Texturen jetz die normalen Defaulttexturen verwendet. Passt dann farblich nicht mehr.

Aber das ist leider nicht alles. Das Fehlen der Texturen bei vorhandensein eines eigenen Texturordners bewirkt jetzt das Speicherleck im FS2004. Die Auslagerungsdatei füllt sich stetig bis zum FS Absturz.

Ich möchte nicht verschweigen das es ganz...... ganz wenige Situationen gibt wo man Texturen löschen könnte.

Das ist aber so gering, dass es nicht der Rede Wert ist. Man könnte z.B alle GAP Scenerien in einen Pott werfen, so das sie z.B auf einen gemeinsamen Texturordner zugreifen, dann wären die anderen Texturordner überflüssig.

Diesen Vorgang kann man aber erst dann gefahrlos durchführen, wenn man alle identischen Texturen gecheckt hat ob sie wirklich den gleichen Dateninhalt und identisches Format haben.

Auch muss man vorher testen ob sich jetzt die zusammengewürfelten BGLs einwandfrei vertragen.

Mal ehrlich der Aufwand ist recht groß. Wer von euch hat schon Lust das alles zu prüfen.

Wie gesagt fast nirgends kann man gefahrlos identische Texturen löschen.

Hallo Jobia,

vielen Dank für diese fundierte Erklärung!!!

Happy Landings
wünscht weiterhin
Fritz

Nabend,

hab das Proggi zwar heute morgen geladen, aber noch nicht genutzt. Gott sei Dank wohl :)

Danke für die Erklärungen zur "Problematik" - Hab mir wohl einige Probleme erspart mit dem Zögern der Installation! :)

LG

Putzig ! Ich hatte die Frage im Jahr 2003 mal gestellt nach dem zur Speichentlastung dieses Programm in französischen Foren heiss empfohlen wurde. Habe es damals auch laufen lassen , es wurden viele "doppelte" Texturen entfernt ohne das es im FS2002 zu spüren war . Im FS9 habe ich es nicht versucht und gebe Hans und Jobia völlig recht .
Man sollte den FS9 so lassen wie er ist !:)

Auch meine Meinung und danke für die Erklärung von JOBIA.

Rainer das Problem ist im FS2002 im Prinzip das selbe. Nur damals wurden z.B bei Landclasscenerien selten eigene Texturen eingesetzt. Auch existierte dort das Speicherleck nicht. Von daher hätte man hier kein Absturz bei LCs erlebt, allenfalls wenn man eine LC Scenery mit eigenen Texturen gehabt hätte eine andere Optik.

Da es ja um doppelte Texturen geht, kann man zu 90% davon ausgehen, dass man die Textur einmal im Addon Texturordner findet und einmal im Haupttexturordner des FS. Löscht man die Textur im Addon, dann funktioniert das Addon in der Regel trotzdem, da es dann auf den Haupttexturordner zugreift.

Das funktioniert aber nicht immer.


Das Problem an der Geschichte ist aber, das die Textur im Addon und im Haupttexturordner eine verschiedene Optik haben können.

Das Addon funktioniert ev. ist aber hinsichtlich Optik verändert.

Z.B kann man den FS Runwaycode in der Scenery nutzen, die zugehörige Defaulttextur findet der FS im Haupttexturordner. Manchen Addon Designern gefällt das nicht, sie bauen eine eigene Textur mit identischen Namen in Ihren Texturordner ein. Dann greift der Runwaycode jetzt nicht mehr auf die Textur im Haupttexturordner zu, sondern auf die bessere des Addons im eigenen Texturordner.

Löscht Du jetzt diese Textur dann funktioniert diese Runway wieder mit der Defaulttextur. Das bedeutet es bleibt eine funktionsfähige Scenery aber mit schlechterer Optik.

Wie gesagt das ist eines der Beispiele neben denen die ich zuvor geschildert habe.

Da ich davon ausgehe, das Ihr nicht ständig alle Addons überwachen wollt würde ich sagen lasst lieber die Finger davon.

Ev. habt Ihr Glück und keine Abstürze, aber es ist nicht gewährleistet, dass euer Addon so aussieht, wie es der Produzent programmiert hat.

Wenn zur Ermittlung ob Dateien `identisch` sind, folgende Kriterien herangezogen werden:

1. Vergleiche Namen
2. Vergleiche Grösse
3. Vergleiche Inhalt (binary check = Prüfsumme)

sollte das eigentlich nicht vorkommen.

Michael

Zu
Natürlich ist das eine Methode um festzustellen ob Dateien identisch sind oder nicht.

Nur schau mal in Texturordner von Addons rein. Da kommen doch schon mal tausend und mehr Texturen zusammen.

Man müsste die Suchergebnisse zusätzlich mit dieser Methode untersuchen. Viel zu aufwendig.

Nur selbst das ist noch nicht sicher genug um mal beim Beispiel Landclass zu bleiben.

Sobald ein Texturordner angelegt wurde kommt es beim löschen einer eindeutig als Kopie einer Defaulttextur identifizierten Textur zum Speicherleck.

Wenn das Tool so intellegent wäre, dass es nicht nur nach doppelten Namen, sondern auch zusätzlich kontrolliert ob es sich dabei um doppelten Bytecode handelt, wäre hier der Crash vorproduziert.

Siehe 3.

Die Chance, dass es trotz einer identischen Prüfsumme 2 unterschiedliche Inhalte sind. ist bei einem Image file vermutlich > 1: 100.000.000. Wahrscheinlich würde man eher im Lotto gewinnen, als dass dieser Fall eintritt.

Michael

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.

Von daher kann man nicht mit einem Tool nach doppelten Dateien suchen und diese einfach löschen selbst wenn sie wirklich 100% tig identisch sind.

Es ist einfach zu gefährlich.

Auch greift nicht jede Scenerytechnik auf einen globalen Texturpfad zurück, wenn in eimem lokalen Pfad eine 100%tige Kopie gelöscht wird.

Auch hier besteht dann eine Gefahr.

Das sollten meine Aussagen rüberbringen, man kann nie gefahrlos Texturen mit identischen Namen löschen egal ob der Bytecode nun abweicht oder nicht.

Klar es gibt Konstellation wo man das machen kann. Nur das weis kein Tool welches die Belange speziel des FS2004 nicht kennt.