Ja das siehst du leider falsch. Das funktioniert im TS2013 ganz anders. Die Strecke lädt so oder so nur die Assets die sie auch benötigt. Wenn 122 Provider eingetragen sind dann lädt sie auch 122 und nich mehr oder weniger. Was sonst noch in den anderen Ordnern liegt spielt überhaupt keine Geige. Der Punkt der wichtig ist is der nächste ...->
Ja, das wäre durchaus ein Lösungsansatz. Aber hey, wer will das bitte durchprüfen. Das sollte der Streckenbauer tun, bevor er die Strecke in die Manege geleitet. Willst du jetzt bei allen 120 Assets rausfinden welche Teile davon verbaut wurden und welche nicht. Na viel Spaß! Und außerdem, wenn man durch diese Methodik kaum was löschen kann, weil fast alles verwendet wird, dann hat man auch nichts gewonnen. Also wenn von all dem Kram nur 25% wirklich verbaut wurde, dann sehe ich da eine Chance einer Verbesserung. Sonst eher nicht. Ich bin mir sicher dass der TS2013 1-10 PAKs besser handlen kann als 122, egal wie viel da drin steht. Das grundlegende Prinzip dieser XML "Kacke" ist eher das Problem dabei. Je mehr komplexe Daten da reinwandern um so mehr bricht alles zusammen. Eine XML Datei hat nur einen Hauptzweig, 122 haben 122 Hauptzweige und da ist dann auch egal wie viel darunter eingetragen ist. Also ob nur 2 Bäume oder 300 Häuser, es bleiben 122 Hauptzweige und da vermute ich das wirkliche Dilemma. Er muss also nicht ein Entity verwalten und als Object speichern, sondern eben 122 Objecte (im Sinne von Klasse>Object>Instanz). Unterm Strich also: wenn man all diese Dinge aus den 122 Asstes in ein Asset shrinkt, dann geht das besser, obwohl es genauso viele Objekte (im Sinne von Modelle/Blueprints) sind.
Gut, dann haben wir das auch geklärt.
Danke 
