[Mod] PromotionInfos.xml durcheinander

[Commander Bello]

€: Hinweis:
Civ:Col hat dem Anschein nach Probleme mit Kommentaren in XML-Dateien. Siehe auch Posting #51.



Hallo alle!

Ich habe versucht, die Kampfwerte der Einheiten realistischer zu gestalten.

Aufgesetzt habe ich dabei auf TAC2.02_inoff.

Verändert wurden folgende Dateien:
Civ4UnitInfos.xml
Civ4ProfessionInfos.xml
Civ4PromotioniInfos.xml

Leider scheint dabei die PromotionInfos.xml "zerwürfelt" worden zu sein, wie hier am Beispiel eines bislang unbeförderten Scouts zu sehen ist.



Man beachte das Fehlen von "Veteran IV" in der Liste, sowie den möglichen Zugriff auf "Wundarzt III".
Alle hier aufgelisteten Beförderungen wurden nicht vom mir verändert.

Sehr wohl habe ich einige neue Beförderungen am Ende der Datei angefügt, die m.E. aber technisch korrekt sind.
Beim Start von Colonization erhalte ich keine Fehlermeldungen; und ja, Col wird ohne Caching gestartet.
Der Fehler bleibt auch bestehen, nachdem Col und/oder der Rechner neugestartet wurde.

Im XML-Log erhalte ich folgende Mitteilung:


Ähnlich sieht es für die Civ4ProfessionInfos.xml aus.

Aber auch die Civ4GoodyInfo.xml (von mir nicht angefasst) weist solche Fehler auf, und etliche andere Dateien auch.

Ich habe die Dateien (also UnitInfos; ProfessionInfos und PromotionInfos) auf korrekte Syntax überprüft.
Alle Tags sind korrekt geöffnet und geschlossen worden, Falschbenennungen kann ich nicht erkennen.

Das Spiel ist nach Änderung der Dateien neu gestartet und ein neues Spiel angelegt worden.

Kurz: ich bin einigermaßen verwirrt, und weiß nicht, wo ich den Fehler noch suchen soll.

Hat irgendjemand ähnliches erlebt/eine Ahnung, an was es liegen könnte?
Für jeden Hinweis wäre ich dankbar.

Ich hänge noch mal die drei geänderten Dateien an, die natürlich alle drei im Pfad "..[modname]/assets/xml/units" eingehängt werden müssten.

[raystuttgart]

Es ist oft gar keine gute Idee, wenn man neue Types am Ende einer XML hinzufügt.

Leider gibt es oft Abhängigkeiten (meist in Python aber durchaus auch in der DLL), wodurch das dann zu Fehlern führt !
(Manchmal bemerkt man die aber erst unglaublich spät.)

Ganz katastrophal kann das beispielsweise bei den Buildings sein.

Achtung Spoiler:

Ich habe damit schon selbst sehr schmerzliche Erfahrungen gemacht und 2 Wochen den Fehler gesucht, bis ich dann endlich rausbekommen habe, wie es richtig eingefügt werden muss.

Ebenfalls aufpassen (bezüglich Reihenfolge) muss man bei:
Specialbuildings, Missions, Yields, Gründerväter, Professions, Builds, ...

Bei anderen wiederum ist die Reihenfolge praktisch egal:
Units, Bonus, Improvements, ...

Da hilft wirklich nichts anderes, als sich durchzuwühlen und rauszufinden, wo die Fallstricke sind.
(Den Python Code durchsehen, hat mir persönlich bisher immer sehr wenig geholfen.
Wenn es Abhängigkeiten in der DLL gibt, ist das meist sehr offensichtlich, weil es dann dafür ein explizites enum / geordnete Auflistung mit einer vollständigen Liste gibt.)

Mit den Promotions hab ich selbst leider noch nichts gemacht.
(Bei Buildings, Professions, Missions, ... könnte ich dir sagen, worauf du in der Reihenfolge achten musst.)

Was ich dir in der Schnelle sagen kann:

In der DLL sehe ich bei den Promotions keine Abhängigkeiten.

Sprich es bleibt eigentlich nur eine Reihenfolgeabhängigkeit in Python.
ODER
Du hast wirklich im XML deiner neuen Types selbst was falsch gemacht.

[Writing Bull]

Ich tippe darauf, dass du bei den Voraussetzungen der Beförderungen Fehler gemacht hast. Mein Rat wäre, in der Colopädie die Beförderungen einzeln durchzugehen und zu prüfen, welche anderen Beförderungen jeweils als Voraussetzungen genannt werden und ob das logisch stimmig ist.

[raystuttgart]

Oder du hast dich einfach vertippt beispielsweise bei einer Referenz in UnitCombatType

<UnitCombatType>UNITCOMBAT_SIEGE</UnitCombatType>

[Commander Bello]

Ich tippe darauf, dass du bei den Voraussetzungen der Beförderungen Fehler gemacht hast. Mein Rat wäre, in der Colopädie die Beförderungen einzeln durchzugehen und zu prüfen, welche anderen Beförderungen jeweils als Voraussetzungen genannt werden und ob das logisch stimmig ist.

Ich bin mir sicher, dort keine Fehler gemacht zu haben.
Die von mir neu angelegten Beförderungen werden als "freie Beförderungen" vergeben und haben keine Voraussetzungen.
Weiterhin würde das m.E. nicht erklären, warum die "Standardbeförderungen" auch nicht mehr stimmig sind; diese habe ich schließlich nicht angefasst.

Oder du hast dich einfach vertippt beispielsweise bei einer Referenz in UnitCombatType

<UnitCombatType>UNITCOMBAT_SIEGE</UnitCombatType>

Auch hier bin ich mir sicher, dass der Fehler nicht hier liegt.
Ich habe die Benennungen mehrfach überprüft und habe auch den typischen Groß-/Kleinschreibe-Fehler vermieden.

Dennoch danke für eure Hinweise , ich werde jetzt mal Rays Hinweis auf Python aufgreifen und versuchen, dort irgendwas zu finden.

[raystuttgart]

Antworten:

<bGraphicalOnly>

Hast du hier alles richtig ?

Das sollte bei deinen neuen Promotions auf 0 stehen.
(Wenn du sie in der Auswahlliste haben willst ...)

[Commander Bello]

Antworten:

<bGraphicalOnly>

Hast du hier alles richtig ?

Das sollte bei deinen neuen Promotions auf 0 stehen.
(Wenn du sie in der Auswahlliste haben willst ...)

Das steht alles auf "1", weil es sich um Beförderungen handelt, die den Einheiten grundsätzlich zugeordnet werden.
Damit versuche ich, unterschiedliche Stärken/Schwächen zu realisieren.

Die neuen Beförderungen sollen gerade nicht auswählbar sein.

Ungeachtet dessen bleibt das Hauptproblem ja, dass dem Scout (s.o.) eine wilde Melange von Beförderungen (teilweise aufeinander aufbauend) angeboten wird.

[raystuttgart]

Hast du mal versucht deinen kompletten Block an Promotions vor diese Promotion zu stellen ? :

<Type>PROMOTION_BROADSIDE</Type>

Oder ziemlich weit vorne in der XML ?

Ist nur ein Versuch, aber mal sehen, was dann passiert ...

[raystuttgart]

So ok, ich hab mir mal deine XML angesehen.

Ich habe deinen Fehler gefunden !


<UnitCombats>
<UnitCombat>
<UnitCombatType>UNITCLASS_INDENTURED_SERVANT</UnitCombatType>
<bUnitCombat>1</bUnitCombat>
</UnitCombat>
</UnitCombats>


Das geht nicht !

Du kannst nicht in UnitCombatType eine UNITCLASS reinschreiben !
In UnitCombat dürfen nur UnitCombats und keine UNITCLASS stehen.

Ich habe jetzt nicht explizit alles durchgesehen, vielleicht gibt es da noch mehr.
Wenn du weiter Probleme hast, sag Bescheid.

[Commander Bello]

So ok, ich hab mir mal deine XML angesehen.

Ich habe deinen Fehler gefunden !


<UnitCombats>
<UnitCombat>
<UnitCombatType>UNITCLASS_INDENTURED_SERVANT</UnitCombatType>
<bUnitCombat>1</bUnitCombat>
</UnitCombat>
</UnitCombats>


Das geht nicht !

Du kannst nicht in UnitCombatType eine UNITCLASS reinschreiben !
In UnitCombat dürfen nur UnitCombats und keine UNITCLASS stehen.

Ich habe jetzt nicht explizit alles durchgesehen, vielleicht gibt es da noch mehr.
Wenn du weiter Probleme hast, sag Bescheid.

Ich bin mir nicht sicher, ob du da recht hast.. meine, ich hätte das sogar von einer anderen Beförderung kopiert.

Ist aber egal, die "PROMOTION_INDENTURED" ist ohnehin nicht in Gebrauch. Ich habe sie jetzt komplett auskommentiert, aber das Problem der fehlerhaften Beförderungen bleibt auch in einem neuen Spiel bestehen.

[raystuttgart]

Ich bin mir nicht sicher, ob du da recht hast.. meine, ich hätte das sogar von einer anderen Beförderung kopiert.

Ich bin mir da absolut sicher.

Du kannst definitiv nicht 2 unterschiedliche Types mischen !

Ein UnitCombatType und ein UnitClassType sind 2 komplett unterschiedliche Sachen !
(Kannst du mir ruhig glauben.)

Du kannst schon Referenzen auf eine UnitClass verwenden, aber NICHT an einer Stelle, wo eine UnitCombatType-Referenz verwendet wird !

[Commander Bello]

Ich bin mir da absolut sicher.

Du kannst definitiv nicht 2 unterschiedliche Types mischen !

Ein UnitCombatType und ein UnitClassType sind 2 komplett unterschiedliche Sachen !
(Kannst du mir ruhig glauben.)

Du kannst schon Referenzen auf eine UnitClass verwenden, aber NICHT an einer Stelle, wo eine UnitCombatType-Referenz verwendet wird !

Der Witz ist, dass es funktioniert hat.

Ich konnte dem Indentured Servant geringere Kampfwerte mit dieser Beförderung zuweisen. Sie wurde nur obsolet, weil sie dann durch die mitgegebenen Beförderungen bei der Umbildung zur Miliz überschrieben wurde.
Daher habe ich die Mali im UnitType eintragen müssen.

[raystuttgart]

Der Witz ist, dass es funktioniert hat.

Kann ich nicht nachvollziehen.

Ich sage ja auch nicht, dass es insgesamt nicht funktioniert, wenn du einer Einheit explizit diese Promotion über <FreePromotions> zuordnest.
Die Werte, die du dabei dieser Promotion gibst, sollten trotzdem funktionieren.

Ich sage ja nur, dass diese eine Referenz falsch ist und du dadurch Fehlermeldungen im Log bekommst und eventuell auch Fehler im Spiel.

Bekommst du immer noch die Fehlermeldung im Log ?

Du hast erwähnt, dass du so eine Mischung von 2 Types schonmal gesehen hast.
Kannst du mir sagen wo ?
(Das wäre nämlich ein Fehler, den man korrigieren sollte.)

[Commander Bello]

Ich hatte es analog zu diesem Eintrag (aus der Beförderung "Dragoon") gemacht:

<UnitClassAttackMods>
    <UnitClassAttackMod>
            <UnitClassType>UNITCLASS_CANNON</UnitClassType>
            <iUnitClassMod>50</iUnitClassMod>
    </UnitClassAttackMod>
</UnitClassAttackMods> 

[raystuttgart]

Ich hatte es analog zu diesem Eintrag (aus der Beförderung "Dragoon") gemacht:

<UnitClassAttackMods>
    <UnitClassAttackMod>
            <UnitClassType>UNITCLASS_CANNON</UnitClassType>
            <iUnitClassMod>50</iUnitClassMod>
    </UnitClassAttackMod>
</UnitClassAttackMods> 

Nein, hast du NICHT !!!!!


<UnitClassType>UNITCLASS_CANNON</UnitClassType>


UnitClassType ---> UnitClass ist vollkommen ok.
UnitCombatType ---> UnitClass is falsch.

<UnitCombatType>UNITCLASS_INDENTURED_SERVANT</UnitCombatType>

Ich bin nicht sauer.
(nur vezweifelt... irgendwie spreche ich heute wohl eine andere Sprache )