Der Grund dazu ist einfach: Du ersetzt mit deinem Code die Kosten und direkt im Anschluss die Bauzeit. Nun folgt aber im Ubi-Code direkt darunter wiederum die Konfiguration der Bauzeit. Diese überschreibt dir deine geänderte Bauzeit also sofort wieder auf den Standardwert von 3 Minuten.
Auch auf die Gefahr hin, wieder virtuell eins auf die Rübe zu bekommen, ein paar Worte dazu - den einen oder anderen wird es interessieren. Das Endergebnis ist richtig beschrieben, allerdings liegen die Gründe etwas anders.
Anno verwendet, wie viele andere Spiele auch, das
XML DOM, DOM ==
Document
Object
Modell. Vorteile sind u.a. eine schnellere Lesbarkeit der XML-Daten durch diese Struktur und die Möglichkeit, Definitionen dynamisch zu ändern. Letzteres machen sich auch die Mods zu Nutzen oder auch die Originaldateien selbst, wenn z.b. bei einem Update neue Items hinzukommen, die andere Dinge steigern sollen.
XML DOM verwendet die sog Tree-Struktur, also eine Baumstruktur mit großen Ästen, von denen wiederum kleinere Äste abgehen bis hin zum Blatt, das ganz aussen sitzt. Jeder Ast ist dabei ein Child (Kind) des Baumes, jeder Abzweig wird ein sog. Node, also ein Knotenpunkt.
Bei den Schiffen ist der Asset-Bereich also der Baum, die Values wäre das erste Child. Values selbst hat nun diverse Childs, z.b. Walking, Cost, ItemContainer oder Craftable. Um dem Script nun zu sagen, welches Child man ansprechen möchte, braucht es den richtigen Pfad, das wäre eine existierende GUID + Path, im Codebeispiel oben dieser Teil hier
<ModOp Type="replace" GUID="100438" Path="/Values/Cost">
Die GUID und der Path "Values/Cost" stellen dabei den Node dar. Dieser Node hat ein weiteres Child "Costs", das dann im Anschluß mit seinen eigenen Childs und dessen Werten, den sog TextNodes dargestellt wird.
Ingredient wäre das Child, der Wert zwischen den spitzen Klammern der TextNode
Bis hierhin war im Code oben alles richtig bis auf das fehlende Leerzeichen oben, das zur Folge hat, das der Path in dieser Anweisung fehlt, weil er der GUID zugeordnet wird, der Code liest: GUID =
Da es keinen Pfad "
100438Path=/Values/Cost" gibt, wird der komplette Abschnitt bis zum schließenden </ModOp> ignoriert.
<Craftable> ist nun kein Child von Values/Cost, sondern ein Child von Values. Hätte das Leerzeichnen nicht gefehlt, würde die modloader-log eine Warnung ausgeben, die in etwa lautet[warning] No matching node for Path //Asset[Values/Standard/GUID='100438']/
Values/Cost in
Da der Craftable-Abschnitt ignoriert wird, greift dann wieder die Original-Definition. Bei Anno werden zuerst die Spieldateien geladen und dann die Mods. Durch die XML DOM-Struktur sucht das Spiel die entsprechenden Objekte einer Mod im Speicher und verändert diese dann entsprechend den Anweisungen.
Zum Replace / Merge / Add noch
ein REPLACE bedeutet: ersetzen, MERGE bedeutet: vereinen, Add wäre das Hinzufügen neuer Childs
ein Replace kann nur ersetzen, was schon vorhanden ist, als Beispiel, die 20 originalen Bretter eines Schoners mit 120 Bretter aus der Mod ersetzen, analog die Segel
Dabei ersetzt REPLACE aber den kompletten Node. Würde ich z.b. im obigem Code die Segel weglassen, würde ein REPLACE diese aus den nötigen Baustoffen streichen, weil REPLACE den Originalcode mit dem der Mod ersetzt, ein MERGE würde aber nur die Anzahl ändern und würde im obigen Code funktionieren, wäre der Rest korrekt gewesen. Im Allgemeinen erfordert MERGE aber eine größere Sorgfalt, es muß immer verglichen werden, was im Original steht, weil ein falscher Node zum Abbruch führt und je größer der ModOp-Abschnitt ist, je größer auch die Gefahr, etwas zu übersehen.
Ein REPLACE oder MERGE kann nicht die oben erwähnte Zahnpasta als neuen notwendigen Baustoff dazu schreiben, also ein Material, das im Original noch nicht genannt wurde, dazu benötigt man ADD
All das zusammen ist eigentlich der Grund, warum man in einer Mod, in der man viele kleine Anpassungen vornehmen möchte, nicht den kompletten asset-Block übernehmen sollte, sondern eher kurze Abschnitte, die gezielt auf einen bestimmten Node und der nötigen Methode ansprechen.