Wenn ich das richtig verstehe, müssten demnach die betroffenen Assets kopiert und in ihren Pfadangaben dahingehend manipuliert werden, so dass sie sich in ihrer veränderten Ordnerstruktur der beheimateten Strecke zurecht fänden.
Das wäre Aufgabe des Streckenbauers.
Dieser hätte auch für eine ordnungsgemäße Aktualisierung zu sorgen, wenn Assets ein Update erführen.
Was mich angeht, so habe ich damit kein problem, sowas zu machen.
Ich könnte mir aber vorstellen, dass viele leute, die sich dem Streckenbau verschrien haben, damit überfordert wären.
Eventuell wäre es schon hilfreich, wenn man dies nur für ein paar Assets machen würde, von deren Provider man nur das eine sprichwörtliche "Blümchen" benötigt, aber dessen Original-Assetordner weit mehr beherbergt, um zu vermeiden, dass diese ganze Palette an Objekten in den Speicher geladen werden muss.
Diese Strategie wäre nun von den Objektbauern abhängig.
Doch befürchte ich, sperren sich viele Freeware-Objektbauer dagegen, was ich auch irgendwie verstehen kann. Bei Vielen würde es vielleicht reichen, wenn man ihnen gebührend Anerkennung in Form von Credits im beiliegenden Readme/PDF gäbe.
Ein sich anbahnendes Fiasko dieser Art findet man auch beim Rollmaterial, z.B. bei "RSItalia/Addon".
Zumindest erklärt dies auch die Funktion unter dem TS2012 und die fehlfunktion unter dem TS2013.
Ich glaube, es ist unstrittig, wenn ich sage, dass der TS2012 etwas sparsamer war, wo hingegen der TS2013 sich jetzt gerne ein paar Extra-MB genehmigt. vermutlich wurde bei z.B. HH-HB und jetzt auch beim EWD hier eine Grenze überschritten, die beim TS2012 noch nicht ganz erreicht war.
Das ist alles nicht sehr zufriedenstellend, aber zumindest klingt es für mich plausibel und es wäre mit einem gewissen Aufwand und der Mitwirkung der Objektbauer sogar heilbar.
Alternativ wäre eine 64-Bit-Version des TS die Lösung, wenn man jetzt nur den Speicheraspekt berücksichtigt.