[Modmod für TAC] CB-Mod - Technik: Wissenslücken, Fragen und vielleicht Antworten

[Commander Bello]

Ich habe die nächste Frage.

Gibt es eine Möglichkeit, der "Kampfklasse" einer Einheit generell bestimmte Werte/Modifikatoren zuzuweisen?

Beispiel:
Der Dragoner (das ist ein Beruf) ist in der "Kampfklasse" UNITCOMBAT_MOUNTED. Ebenso der Kürassier, und die berittenen Indianer.
Man kann eine Beförderung erstellen, die diesen Berufen zugewiesen wird und die diese Modifikatoren enthält.

Ich würde aber gern direkt die "Kampfklasse" anfassen wollen, um zu vermeiden, dass ich
a) eine Beförderung erstellen muss
b) diese vier unterschiedlichen Berufen zuweisen muss

[Akropolis]

Ja, bei den GV geht das ja auch. Also über eine Leadertrait.

[Commander Bello]

Ja, bei den GV geht das ja auch. Also über eine Leadertrait.

Ja, in der TraitInfos.xml definiere ich freie Beförderungen, die ich dann dem UnitCombatType zuordne.

Das ist nicht ganz, was mir vorschwebte.
Ich wollte den UnitCombatType generell mit bestimmten Attributen (z.B. bestimmte Verteidigungswerte, etc.) versehen. Und das auf genereller Ebene, also auch nicht speziell für eine Nation.

Scheint aber nicht so vorgesehen zu sein, wie mir eine flüchtige Durchsuchung der XML-Dateien zeigt.

Nachtrag:
Das wiederum bringt mich gleich zur nächsten Frage:
Kann man das selbst hinbiegen, indem man einfach die UnitScheme.xml verbiegt?
UnitCombatType ist ja schon definiert. Einfaches Einfügen müsste doch eigentlich funktionieren?
Oder muss da die DLL angefasst werden?

[raystuttgart]

Oder muss da die DLL angefasst werden?

Kernfunktionalität muss eigentlich immer über die DLL gemacht werden.
(Ja gut, es gehen auch manchmal unsaubere Sachen über Python.)

Einfach neue Tags im Schema / XML bringen dir gar nichts.
(XML ist keine Logik, sondern lediglich Konfiguration.)

Woher soll die Logik denn wissen, was sie damit machen soll, wenn du sie nicht schreibst ?

[Commander Bello]

Kernfunktionalität muss eigentlich immer über die DLL gemacht werden.

Einfach neue Tags im Schema / XML bringen dir gar nichts.
(XML ist keine Logik, sondern lediglich Konfiguration.)

Woher soll die DLL denn wissen, was sie damit machen soll, wenn du den Code dafür nicht schreibst ?

Nun ja, der Gedanke war, dass die DLL den UnitCombatType ja kennt. Definiert worden ist er ja irgendwo schon.

Und das XML-Schema sorgt ja letztlich nur für die korrekte Zuordnung von Elementtypen und Elementen (die wiederum auch Elementtypen sein können). Wäre diese Zuordnung in der DLL konfiguriert, könnte man sich das Schema sparen - tut man aber nicht.

[raystuttgart]

Und das XML-Schema sorgt ja letztlich nur für die korrekte Zuordnung von Elementtypen und Elementen (die wiederum auch Elementtypen sein können).

Da hast du eine ganz falsche Vorstellung, was das Schema tut.

Das Schema definiert lediglich, wie die Konfigurations-Informationen in den jeweiligen XML strukturiert sein müssen.
(Als Prüfungsmechanismus, ob das XML korrekt ist.)

Das XML stellt dann die Konfigurations-Informationen.

Das Schema definiert keine Zusammenhänge für die Logik.
Das macht auch nicht das XML.

Die DLL entscheidet, was sie von wo liest und was sie damit macht.
(Wie gesagt, manches geht auch über Python.)

Lös dich bitte von dem Gedanken, dass du irgendwas in XML programmieren kannst.
(Da kannst du wirklich nur konfigurieren.)

[Commander Bello]

Da hast du eine ganz falsche Vorstellung, was das Schema tut.

Das Schema definiert lediglich, wie die Konfigurations-Informationen in den jeweiligen XML strukturiert sein müssen.
(Als Prüfungsmechanismus, ob das XML korrekt ist.)

Das XML stellt dann die Konfigurations-Informationen.

Das Schema definiert keine Zusammenhänge für die Logik.
Das macht auch nicht das XML.

Die DLL entscheidet, was sie von wo liest und was sie damit macht.
(Wie gesagt, manches geht auch über Python.)

Lös dich bitte von dem Gedanken, dass du irgendwas in XML programmieren kannst.
(Da kannst du wirklich nur konfigurieren.)

Es geht ja nicht ums Programmieren.

Ich dachte halt, dass diese Zeile
LoadGlobalClassInfo(GC.getUnitInfo(), "CIV4UnitInfos", "Units", "Civ4UnitInfos/UnitInfos/UnitInfo", &CvDLLUtilityIFaceBase::createUnitInfoCacheObject);
aus der CvXMLLoadUtilitySet.cpp letztlich die in der Civ4UnitInfos.xml hinterlegten Parameter ausliest.

Es war mir schon klar, dass ich nicht einfach ein neues XML-Element schnitzen kann. Aber das wäre es ja auch nicht gewesen.

[Commander Bello]

Zitat von Commander Bello
Der Konvertit darf keinen Militärberuf ergreifen. Wo ist das festgelegt?

Späher kann er werden. Aber prinzipiell zu deiner Frage: Das wüsste ich auch gerne! Ich habe das schon mehrfach eine gefühlte Ewigkeit gesucht und nicht gefunden.

Beim Modden an "Werewolves" habe ich eine Vielzahl von Einheiten neu eingeführt, die genau wie der Hessische Söldner gar keinen Beruf ergreifen können. Dabei habe ich aber, bequem wie ich bin, den HS als Vorlage kopiert und dann nur noch editiert.

Den umgekehrten Weg habe ich nun herausgefunden.
Ich kann dem Hessen nun Berufe zuweisen.

Achtung Spoiler:

Wenn man ihm statt
<DefaultProfession>NONE</DefaultProfession>
dies zuweist: <DefaultProfession>PROFESSION_MUSKETMAN</DefaultProfession>
dann kann er plötzlich Berufe ergreifen.

Allerdings nur Missionar oder Miliz.

Nachtrag 3:
Das wiederum liegt an der DefaultProfession. Gibt man ihm nämlich <DefaultProfession>PROFESSION_COLONIST</DefaultProfession>, dann kann er auch zum Pionier werden

Nachtrag 1:
So, und die Angelegenheit mit dem Konvertiten habe ich nun auch endlich verstanden :
Wenn man aus
<bOnlyDefensive>1</bOnlyDefensive>
vielleicht mal
<bOnlyDefensive>0</bOnlyDefensive>
machen würde, dann könnte er auch Militärberufe ergreifen.

Nachtrag 2:
Und jetzt möchte ich anfangen, ein ganz klein wenig zu schreien
Die Fähigkeit, Missionar zu werden, hängt auch daran:
<bOnlyDefensive>1</bOnlyDefensive>
verhindert sowohl die militärischen Berufe wie auch den Missionar.

[raystuttgart]

LoadGlobalClassInfo(GC.getUnitInfo(), "CIV4UnitInfos", "Units", "Civ4UnitInfos/UnitInfos/UnitInfo", &CvDLLUtilityIFaceBase::createUnitInfoCacheObject);
aus der CvXMLLoadUtilitySet.cpp letztlich die in der Civ4UnitInfos.xml hinterlegten Parameter ausliest.

Nein, sie stellt die Informationen aus dem XML zum Auslesen bereit.
Wenn du wirklich Informationen Auslesen und Schreiben willst, dann musst du in CvInfos.cpp die Methoden erstellen.
Und dann brauchst du noch immer die Logik, die weiß, was sie damit tut.

Ok, ich glaub du hast verstanden um was es geht.
(Du kannst im XML gar nix erreichen, wenn die Logik damit nix anzufangen weiß.)

[Writing Bull]

Ohne in den Dateien bereits nachgeschaut zu haben: Ist es nicht so, dass bOnlyDefensive lediglich definiert, ob eine Einheit andere Einheiten angreifen kann oder ob sie sich aufs Verteidigen beschränken muss?

[Commander Bello]

Ohne in den Dateien bereits nachgeschaut zu haben: Ist es nicht so, dass bOnlyDefensive lediglich definiert, ob eine Einheit andere Einheiten angreifen kann oder ob sie sich aufs Verteidigen beschränken muss?

Sollte man annehmen, nicht wahr?

Offensichtlich ist aber neben den militärischen Berufen auch der Missionar daran gekoppelt (zumindest für den Konvertit, ich habe das noch nicht für andere Einheitenarten geprüft).

Das ist etwas, was mich bei Firaxis ohnehin tierisch annervt: die machen immer alles im Dunkeln von hinten durch die Brust ins Auge.
Gerade so offensichtliche Verknüpfungen wie Einheit und Beruf über Zweit- und Drittzuordnungen zu lösen, ist schon.... aber lassen wir das.

[Writing Bull]

Kann denn UNIT_CONVERTED_NATIVE im Beruf Späher trotz <bOnlyDefensive>1</bOnlyDefensive> andere Einheiten angreifen? Ich komme gerade leider nicht dazu, das zu überprüfen, aber vielleicht du?

[raystuttgart]

@Commander Bello:

Kleine Warnung / kleiner Hinweis:

Du experimentierst ja gerade mit <DefaultProfession>.

Das wird nicht nur Auswirkungen auf den menschlichen Spieler, sondern auch auf AI haben und kann auch zu Bugs führen !

1. Die AI wird dann eventuell Dinge tun, die ein menschlicher Spieler nie tun würde, weil es eigentlich bescheuert ist.
(Einheiten an Berufe verschwenden, für die sie eigentlich gar nicht geeignet sind und besser in anderen Berufen aufgehoben wären.)

2. Es kann durchaus sein, dass das zu Bugs führt, weil andere Einstellungen im XML der Unit nicht zu der neu eingestellten <DefaultProfession> passen.
(Ich würde da vorallem wegen <DefaultUnitAI> sehr vorsichtig sein.)

Du bist also gewarnt.

[Commander Bello]

@Commander Bello:

Kleine Warnung / kleiner Hinweis:

1. Die AI wird dann eventuell Dinge tun, die ein menschlicher Spieler nie tun würde, weil es eigentlich bescheuert ist.
(Einheiten an Berufe verschwenden, für die sie eigentlich gar nicht geeignet sind und besser in anderen Berufen aufgehoben wären.)

Du meinst, Offiziere zu Missionaren machen und solche Dinge?

Achtung Spoiler:

(Sorry, den konnte ich mir einfach nicht verkneifen. )

[raystuttgart]

Du meinst, Offiziere zu Missionaren machen und solche Dinge?

Ja, nur hast du dann vielleicht auf einmal auch Hessische Söldner als Missionare.

Bloß viel schlimmer ist das Risiko das du heftige Bugs hast, weil es wegen Combination "DefaultProfession" und "UnitAI" kracht !
(Und oder andere XML-Werte zu Problemen führen.)

Außerdem generieren diverse Features die Einheiten auch mit ihrer "DefaultProfession".

Sprich bei "Revolutionary Support" bekommst du vielleicht auf einmal "Hessische Söldner" im Beruf Kolonist, wenn du das so einstellst.
Du versaust also eventuell auch existierende Features.

Wie gesagt, ich hab dich gewarnt.
(Ich persönlich würde so ein Risiko nicht eingehen, ohne in der DLL nachzusehen ...)