[Modmod] CB-mod 0.7.x für RaR

[Kermit87]

1. Ich habe das Unit-Price-Normalizing erst einmal über die Reduzierung des m_aiEuropeUnitsPurchased Zählers umgesetzt.

Mein Problem mit der von dir genannten Vorgehensweise liegt einfach daran, dass die Anzahl der gekauften Einheiten nur indirekt (spätestens nach der ersten Reduzierung) noch etwas mit dem Einheitspreis zu tun hat. Ich bin zwar auf der einen Seite ein Freund kurzen, schnellen Codes, gleichzeitig aber auch von klarem Code.

Man nimmt sich aus der XML den Basispreis. Verwurstet diesen mit Schwierigkeitsgrad, und ggf. noch Kartengröße und so. Das Ergebnis ist der Standartpreis. Dieser lässt sich also nicht ohne weiteres einfach nur aus der XML auslesen. Bisher wird bei dieser Verwurstung jedoch auch die Inflation erzeugt. Diese beruht auf dem besagten Zähler. Wird dieser nirgends anderweitig verwendet (was der Fall ist! Manipulationen von m_aiEuropeUnitsPurchased tangieren keine anderen Berechnungen) lässt sich über den Abbau des gezählten direkt einfach und effektiv die Inflation senken. Ähnlich wie bei den Yield's.
Oder habe ich da irgendwas übersehen?

Meine nächsten angedachten Features und Überlegungen:

2. Wie wäre es wenn die Einheiten eines Stapels einen Kampfwert-Malus in höher ihrer Anzahl erleiden. Je mehr Einheiten sich auf einem Feld befinden je Enger und überfüllter desto verletzlicher und ineffektiver sind sie. Der KI könne man das über die eh schon vorhandene Limitierung der Einheiten Anzahl im einem Stapel verklickern.

3. Könnte man die Bombardierung, also das senken des Verteidigungswertes einer Stadt, nicht als Abnutzung in den normalen Kampf integrieren. Oder als langsames reduzieren bei einschließender Belagerung, Hungersnot oder … wirken lassen? Ich empfinde dieses Handlung des Bombardierens immer so etwas Außenstehend!

Ich komme im Moment nicht so richtig zum intensiven weiterarbeiten aber habe mir so meine Gedanken gemacht.

[Commander Bello]

1. Ich habe das Unit-Price-Normalizing erst einmal über die Reduzierung des m_aiEuropeUnitsPurchased Zählers umgesetzt.

Man nimmt sich aus der XML den Basispreis. Verwurstet diesen mit Schwierigkeitsgrad, und ggf. noch Kartengröße und so. Das Ergebnis ist der Standartpreis. Dieser lässt sich also nicht ohne weiteres einfach nur aus der XML auslesen. Bisher wird bei dieser Verwurstung jedoch auch die Inflation erzeugt. Diese beruht auf dem besagten Zähler. Wird dieser nirgends anderweitig verwendet lässt sich über den Abbau des gezählten direkt einfach und effektiv die Inflation senken. Ähnlich wie bei den Yield's. Oder habe ich da irgendwas übersehen?

Meiner Meinung nach ja.

Du hast 3 Einheiten vom Typ X gekauft. Der Standardpreis (S0) sei 800. Die Preissteigerung (Inflation) sei 200
m_aiEuropeUnitsPurchased == 3

Im Standardspiel kostet die nächste Einheit vom Typ X nun 1400.

Jetzt senkst du m_aiEuropeUnitsPurchased um 5% (multiplizierst mit 0.95). Allerdings hat m_aiEuropeUnitsPurchased jetzt nicht den Wert 2.85, sondern bestenfalls 2 - weil es ein Integerwert ist.
Du musst also alle Funktionen, die auf m_aiEuropeUnitsPurchased zurückgreifen, vom Wert int auf float umstellen.

Dann stellt sich die Frage, wie die Reduktion eigentlich wirklich wirken soll: Dein ursprünglicher Gedanke war, pro Runde mit 0.95 zu multiplizieren.
Für eine Einheit bedeutet das tatsächlich eine Reduktion um 5% (bezogen auf die Preissteigerung), aber bei 2 Einheiten reduzierst du faktisch um 10%, usw.
Und du reduzierst halt die Kostensteigerung (Inflation); nicht den Standardpreis.

int CvPlayer::getEuropeUnitBuyPrice(UnitTypes eUnit, bool bIncrease) const
// TAC - AI purchases military units - koma13 - END
{
    CvUnitInfo& kUnit = GC.getUnitInfo(eUnit);

    int iCost = kUnit.getEuropeCost();

    bool bNegative = (iCost < 0);
    iCost = std::abs(iCost);

    // TAC - AI purchases military units - koma13 - START
    //iCost += GET_TEAM(getTeam()).getEuropeUnitsPurchased((UnitClassTypes) kUnit.getUnitClassType()) * kUnit.getEuropeCostIncrease();
    if (bIncrease)
    {
        iCost += GET_TEAM(getTeam()).getEuropeUnitsPurchased((UnitClassTypes) kUnit.getUnitClassType()) * kUnit.getEuropeCostIncrease();
    }
    // TAC - AI purchases military units - koma13 - END

    iCost *= GC.getGameSpeedInfo(GC.getGameINLINE().getGameSpeedType()).getTrainPercent();
    iCost /= 100;

    iCost *= GC.getEraInfo(GC.getGameINLINE().getStartEra()).getTrainPercent();
    iCost /= 100;
....
}

Du tust dich viel leichter, wenn du m_iEuropeCost (das ist der ursprünglich aus den XML ausgelesenen Wert, der sich dann natürlich ändern wird) in jeder Runde änderst.

2. Wie wäre es wenn die Einheiten eines Stapels einen Kampfwert-Malus in höher ihrer Anzahl erleiden. Je mehr Einheiten sich auf einem Feld befinden je Enger und überfüllter desto verletzlicher und ineffektiver sind sie. Der KI könne man das über die eh schon vorhandene Limitierung der Einheiten Anzahl im einem Stapel verklickern.

Ich denke gerade in die gegenseitige Richtung.
Grund:
a) Auch Einheiten im Stapel kämpfen prinzipiell immer allein (Jetzt-Zustand).
b) Wenn Einheiten im Stapel (nach noch festzulegenden Regeln) stärker werden, dann symbolisiert das in gewissem Maße die gegenseitige Unterstützung, die sich benachbarte Einheiten geben.
c) Die KI verwendet ohnehin Einheitenstapel. Mit deinem Vorschlag müsste man ihr beibringen, genau das im Augenblick des Kampfes nach Möglichkeit zu vermeiden, den Stapel also aufzuteilen. Das dürfte etwas aufwendig zu programmieren sein.

3. Könnte man die Bombardierung, also das senken des Verteidigungswertes einer Stadt, nicht als Abnutzung in den normalen Kampf integrieren. Oder als langsames reduzieren bei einschließender Belagerung, Hungersnot oder … wirken lassen? Ich empfinde dieses Handlung des Bombardierens immer so etwas Außenstehend!

Ich überlege in der Tat, bei Angriffen von Nicht-Artillerie-Einheiten den Verteidigungswert der Befestigung geringfügig zu senken. Das ist m.E. nicht weiter schwierig, nur eine Menge manuellen Tippens.
Auch über die Aufhebung der Bombardierung als eigenständigen Befehl habe ich schon nachgedacht. Hier wird es ein wenig problematischer, weil man der KI dann das Bombardieren erst "aberziehen" muss, um es dann als Nebenfolge des Stadtangriffs wieder automatisiert einzufügen (letzteres ist nicht weiter schwierig, nur wieder manuelles Code-Tippen).
Das Problem taucht bei den ersten Angriffen auf: Wenn die Stadt einen Verteidigungswert von 100% hat, und keine vorherige Reduktion durch Bombardierung erfolgte, kann man davon ausgehen, dass die ersten Angreifer schlicht draufgehen. Das ist bei der prinzipiell beschränkten Anzahl an Einheiten nicht gut, und außerdem ahistorisch - es war ja gang und gäbe, dass Stadtmauern erst einmal in klitzekleine Kieselsteine zerschossen wurden.
Der KI diesbezüglich eine auch nur halbwegs gescheite Vorgehensweise zu programmieren, dürfte nicht ganz trivial sein.

Vermutlich werde ich es beim Bombardierungsbefehl belassen und dafür das "begleitende" Bombardieren zusätzlich einfügen. Das erfordert keine Änderungen für die KI und beschleunigt den Vorgang ein wenig.

Ansonsten wate ich derzeit tief in den Niederungen des Kampfsystems. Dafür muss ich so ungefähr 25 Funktionen anpassen, die dummerweise auch immer wieder andere Parameterkonstellationen haben, und im Moment suche ich verzweifelt nach der Stelle, wo die ganzen resultierenden Werte für Python (das ganze muss ja auch entsprechend und korrekt auf dem Bildschirm ausgegeben werden) aufbereitet werden.
Irgendwo schlüpft mir noch der Link zwischen der CyStructsInterface1.cpp (quasi der Eingangswert) und der CvUtil.py (Ausgabe) durch die Finger. Ich find's einfach im Moment nicht.

[Commander Bello]

Ich schreibe das komplette Kampfsystem um.

Kleine Nebenprodukte bisher (allerdings noch nicht getestet - der Gesamtverhau ist noch nicht fehlerfrei kompilierbar):
a) bislang konnten nur angreifende Schiffe den Verteidiger kapern - nun kann auch der Verteidiger den Angreifer kapern
b) Schiffsflucht wurde bisher am Ende des Kampfes ermittelt - das geschieht nun vor dem ersten Schuss

Weiterhin neu:
Als "Siegwahrscheinlichkeit" wird nun die Wahrscheinlichkeit, nicht getötet zu werden, zurückgegeben. Das sollte die KI dazu bringen, wesentlich häufiger selbst anzugreifen (hoffe ich). Insbesondere wird das hoffentlich den Ureinwohnern helfen, heranmarschierende Kolonialkräfte schon im Anmarsch zu stellen und ihre Städte zu verteidigen, indem sie Gegenangriffe durchführen.

[Commander Bello]

Fertig. Es kompiliert, und stürzt nun bei den Berufen ab - die wiederum habe ich nun gar nicht angefasst.

[Commander Bello]

Es wird immer unangenehmer. Mit der neuen DLL kann ich kein neues Spiel starten (Unbehandelter Ausnahmefehler ...), allerdings ein altes fortsetzen.
Nur zeigt sich dort, dass mein "genialer" Gedanke mit der Struktur für die Kampfwerte vielleicht noch nicht ganz zum Nobelpreis reicht - auch dort passiert dann eine unbehandelte Ausnahme.
Das Merkwürdige daran ist, dass ich den entsprechenden Code kopiert habe - in der Vorlage funktioniert es, in meiner Version nicht.

Schade eigentlich. In der Theorie war das ein guter Gedanke.

Schau an... Das ist ja interessant.
Kaum benutzt man Strukturen so, wie es vorgesehen ist, funktioniert es auch... So was...

Und er stürzt wieder bei getProfession ab.
Ich habe so ziemlich alles angefasst, aber die Berufe sicherlich nicht.

[Kermit87]

O-o, solche Probleme machen mir Angst! Und nun?

Thema: Unit-Price-Normalizing

Meiner Meinung nach ja.

Du hast 3 Einheiten vom Typ X gekauft. Der Standardpreis (S0) sei 800. Die Preissteigerung (Inflation) sei 200
m_aiEuropeUnitsPurchased == 3

Im Standardspiel kostet die nächste Einheit vom Typ X nun 1400.

Jetzt senkst du m_aiEuropeUnitsPurchased um 5% (multiplizierst mit 0.95). Allerdings hat m_aiEuropeUnitsPurchased jetzt nicht den Wert 2.85, sondern bestenfalls 2 - weil es ein Integerwert ist.
Du musst also alle Funktionen, die auf m_aiEuropeUnitsPurchased zurückgreifen, vom Wert int auf float umstellen.

Dann stellt sich die Frage, wie die Reduktion eigentlich wirklich wirken soll: Dein ursprünglicher Gedanke war, pro Runde mit 0.95 zu multiplizieren.
Für eine Einheit bedeutet das tatsächlich eine Reduktion um 5% (bezogen auf die Preissteigerung), aber bei 2 Einheiten reduzierst du faktisch um 10%, usw.
Und du reduzierst halt die Kostensteigerung (Inflation); nicht den Standardpreis.

So sollte das ja auch sein! Intern wird mit float gerechnent. Damit habe ich das unschöne multiplizieren und später wieder dividieren durch 10.000 gespart und der Multiplikator kann schön floatig wirken. Dadurch das zur Ausgabe aus dem float ein int gemacht wird fallen die Beträge Phasenweise und bleiben schön ansehnlich ohne zerfranst zu werden. Vielleicht solltest du dir das einfach angucken und wenn du willst kannst du es ja umschreiben. Ich finde das so jedenfalls ganz smart gelöst!

Thema: Stapel - Bonus oder Malus

Ich denke gerade in die gegenseitige Richtung.

Synergieeffekte bis zu einer bestimmten Einheitenanzahl auf einem Feld: ok. Aber was ist wenns überhand nimmt? So ab 30 wirds eng und könnte Kampfwerteinbussen geben?

Thema: Bombardieren:
Wenn ich meine Artillerie in Stellung bringe um die Wehranlagen zu beschießen muss ich unweigerlich damit rechnen das ich selbst beschossen werde (zumindest von der verteidigenden Artillerie)! Statt wie bisher vor der Stadt zu Campen und ein paar Runden unbehelligt den Bombardieren Knopf zu drücken und den Verteidigungsbonus wegzupusten. Und, ja das überwinden einer gut ausgebauten Wehranlage würde wohl einige Opfer mehr kosten Kosten aber mit (*) ziehen sich die Einheiten auch wieder zurück.

Thema: wechselwirkende Waffengattungen:
Es wäre schön wenn sich Kriegsschiffe mit Artilleriegarnisonen in Städten oder an der See gelegenen Festungen Scharmützeln könnten! Oder das sogar jene Artilleriegarnisonen blockierende Schiffe unter Feuer nehmen könnten!

Thema: #47:
Ich habe unter Berücksichtigung ein Konzept erdacht.

Thema: Klima/Ernte – Events
Ich plane über Events den Plot-Ertrag auf globaler ebene zu manipulieren um Dürren, Plagen, Rekord Saisons oder andere Ereignisse über die Neue Welt hereinbrechen zu lassen!

* Thema: Kampfrunden Limitierung:
Ich rechne generell damit das die Kampfrunden doch wieder auf sieben Limitiert werden? Oder wie hast du das geplant?

Jetzt zerdrücke ich mir mal die Daumen für dich das du die blöden Fehler ausgemertzt bekommst!!! Ich bin ängstlich gespannt!
Aber ich glaub an dich, deswegen male ich jetzt nicht den Teufel an die Wand! Duch was du dich da schon alles durchgewühlt hast <hui>

Aber es gibt auch eine erfreuliche Nachricht: in Sachen Multiplayer mit Kumpels kommt langsam Wind auf! Vorher war ja eher Flaute weil Kumpel #1 doch im Moment zu viel zu tun hat. Habe aber gestern mit Kumpel #2 eine erfolgreiche Lernstart über Direktverbindung mit TAC und CB-Mod geschafft!

[Commander Bello]

O-o, solche Probleme machen mir Angst! Und nun?

Ich habe keine Ahnung.

* Thema: Kampfrunden Limitierung:
Ich rechne generell damit das die Kampfrunden doch wieder auf sieben Limitiert werden? Oder wie hast du das geplant?

Im ersten Schritt ja, danach werde ich das über die GlobalDefinesAlt.xml einstellbar machen.

Aber es gibt auch eine erfreuliche Nachricht: in Sachen Multiplayer mit Kumpels kommt langsam Wind auf! Vorher war ja eher Flaute weil Kumpel #1 doch im Moment zu viel zu tun hat. Habe aber gestern mit Kumpel #2 eine erfolgreiche Lernstart über Direktverbindung mit TAC und CB-Mod geschafft!

Oh, das freut mich.
Zum ersten natürlich für euch, aber auch, weil es mit meiner Mod klappt

(Den Rest kommentiere ich später, ich bin gerade auf Fehlerhatz)

[Commander Bello]

Tja.
Er bricht einfach beim Abfragen von getProfession() sang- und klanglos in die Knie. Ob ich wohl milde irritiert bin?

===
Dank rucivfans Hilfe bin ich nun nicht mehr irritiert. Ich hatte einfach ohne Sinn und Verstand eine Wahrscheinlichkeitsberechnung eingefügt, der es an der Stelle aber an der Angabe des notwendigen Angreifers mangelte.

Nachdem ich diese Wahrscheinlichkeitsberechnung auskommentiert habe (und zwar nur diese!), und die DLL also an der Stelle nicht mehr abbrechen kann, hat sie sich dazu entschlossen, erst gar nicht mehr bis dahin zu gelangen, sondern schon beim Start abzubrechen.
Es ist ein hartes Brot....

[Commander Bello]

Gar gruselig war's...

Die Ursprungsfunktion von Firaxis wurde kommentiert mit der Bemerkung, es könne nur vier Parameterkombinationen geben, in denen sie aufgerufen würde.
Darauf habe ich unter anderem meine Überarbeitung aufgebaut.

Tatsächlich gibt es mindestens fünf Fälle ()
Das herauszufinden wurde nicht einfacher dadurch, dass die Aufrufer dieser Funktion für sich selbst von jenseits der DLL (entweder aus Python oder direkt aus der .exe - ich weiß es einfach [noch] nicht) aufgerufen werden. Das war einer der Gründe für die vielen Abstürze. Ich hatte diese Aufruferfunktionen auskommentiert, weil ich in der DLL alles umgeschrieben hatte und keine Aufrufe mehr feststellen konnte...

Nun aber zum erfreulichen Teil:



Wie man sieht, sind die Werte noch alle schief und schräg. Die Unterdrückung von Nullwerten tut es auch noch nicht. Aber das sind noch kleine Misslichkeiten, die ich ausräumen muss.

Wichtig ist, dass die Boni nun prinzipiell tatsächlich auf der jeweiligen Seite zugeordnet werden.
Damit kann man dann herangehen, und die Boni tatsächlich mal sinnvoll überarbeiten.

Außerdem sind die Ureinwohner in der Tat angriffslustiger geworden, wie ich anhand einiger Angriffe, die mit der alten DLL nicht passierten, feststellen konnte.

Fazit: die wichtigste Hürde ist genommen, jetzt beginnt die Mühsal des "Aufräumens" und spielbar Machens.
Das wird vermutlich noch einige Tage dauern. Meine DLL sieht aufgrund der vielen Umschreibungen und dazugehörigen Kommentare aus wie Kraut und Rüben, danach muss ich dann ein neues Excel aufsetzen, um die Boni grundlegend zu überarbeiten.

===
So sieht das schon besser aus

[Kermit87]

...
Fazit: die wichtigste Hürde ist genommen!

Habe gerade "Don’t Worry, Be Happy" in der Dauerschleife laufen!
Gute Arbeit und auch noch so ne schwere Kost komplett neu erarbeitet! Super Disziplin das du dich nicht hast entmutigen lassen! Alles in so kurzer Zeit!

?:

Wir habe wieder gespielt und mein lernender Mitspieler hat mit einer anderen Auflösung (1024 x 768) als ich (voll HD) rechts unten auf dem Kai so ein kleines Problemchen! Er kommt durch die sich überschneidenden Grafiken nicht an das Kaufmenü ran. Ich glaube das tritt nach meinen teste nur in Verbindung mit CB-Mod auf. Ich habe mal in die CvEuropeScreen.py geschaut aber die wird von dir gar nicht ausgetauscht. Liegt da vielleicht irgendwo anders das der Hund begraben? Oder wo kann man das ändern?

Thema: Kollateralschaden:
Wo du schonmal dabei bist: ich habe ja früher zu beginn meiner DLL-Aktivitäten den Kollateralschaden in Colonization reimplementiert. Vielleicht würde sich das ja in deinem umgebauten Kampfsystem gut integrieren?
ZB. je mehr Eeinheiten sich auf einem Feld befinden umso wahrscheinlicher ist Kollateralschaden. Oder wie sich das Feature auch immer nutzen ließe?

[Commander Bello]

Wir habe wieder gespielt und mein lernender Mitspieler hat mit einer anderen Auflösung (1024 x 768) als ich (voll HD) rechts unten auf dem Kai so ein kleines Problemchen! Er kommt durch die sich überschneidenden Grafiken nicht an das Kaufmenü ran. Ich glaube das tritt nach meinen teste nur in Verbindung mit CB-Mod auf. Ich habe mal in die CvEuropeScreen.py geschaut aber die wird von dir gar nicht ausgetauscht. Liegt da vielleicht irgendwo anders das der Hund begraben? Oder wo kann man das ändern?

Dieses Problem hatte ich mal hervorgerufen, ja. Damals hatte ich aber die Menge der auf dem Kai verfügbaren Europäer geändert, was ich angesichts der berichteten Probleme in den letzten Versionen unterlassen hatte. Er müsste dann mehr als 3 Einheiten auf dem Kai haben?
Wie man es bei 1024*768 ändern kann, ist hier beschrieben.

Thema: Kollateralschaden:
Wo du schonmal dabei bist: ich habe ja früher zu beginn meiner DLL-Aktivitäten den Kollateralschaden in Colonization reimplementiert. Vielleicht würde sich das ja in deinem umgebauten Kampfsystem gut integrieren?
ZB. je mehr Eeinheiten sich auf einem Feld befinden umso wahrscheinlicher ist Kollateralschaden. Oder wie sich das Feature auch immer nutzen ließe?

Darüber muss ich mir noch Gedanken machen.
Grundsätzlich ist ein Kollateralschadensystem nicht schlecht, weil es natürlich dem "Bumms" der Stacks entgegenwirkt, nur fand ich die Umsetzung bei Civ4 nicht gar so prickelnd.

Ich möchte aber zunächst einmal mein neues Kampfsystem "sauber machen", d.h. alle kleinen Fehlerchen ausmerzen (im Moment habe ich nämlich noch das Kampflog erledigt... Python muss noch angepasst werden).
Dann werde ich eine neue Version veröffentlichen, einfach auch, damit mehr Leute es testen können.
Darauf aufbauend komme ich dann gerne auf dein Angebot zurück.

Ansonsten habe ich vermutlich einen Weg gefunden, die Ureinwohner ein wenig gefährlicher zu machen... Das testweise zu implementieren, wird aber auch erst nachher geschehen..

[Kermit87]

Jo danke, die Immigranten stehen sich zu viert nun nicht mehr gegenseitig auf den Füßen!

Kanst du zum:

Thema: wechselwirkende Waffengattungen:
Es wäre schön wenn sich Kriegsschiffe mit Artilleriegarnisonen in Städten oder an der See gelegenen Festungen Scharmützeln könnten! Oder das sogar jene Artilleriegarnisonen blockierende Schiffe unter Feuer nehmen könnten!

Schon was sagen?

Thema: verfallende Improvements:
Ich hatte da noch so eine Idee zu den Improvements! Ich dachte daran diese nach einiger Zeit ohne Bewirtschaftung verfallen zu lassen. So das der Spieler dazu angehalten wird eher nach Zeitnahem bedarf das Land auszubauen und teils wieder in stand setzen muss. Ich glaube allerdings das die KI dann echt gut beschäftigt wäre!

[Commander Bello]

Jo danke, die Immigranten stehen sich zu viert nun nicht mehr gegenseitig auf den Füßen!

Kanst du zum:

Zitat von mir in #96
Thema: wechselwirkende Waffengattungen:
Es wäre schön wenn sich Kriegsschiffe mit Artilleriegarnisonen in Städten oder an der See gelegenen Festungen Scharmützeln könnten! Oder das sogar jene Artilleriegarnisonen blockierende Schiffe unter Feuer nehmen könnten!

Schon was sagen?

Thema: verfallende Improvements:
Ich hatte da noch so eine Idee zu den Improvements! Ich dachte daran diese nach einiger Zeit ohne Bewirtschaftung verfallen zu lassen. So das der Spieler dazu angehalten wird eher nach Zeitnahem bedarf das Land auszubauen und teils wieder in stand setzen muss. Ich glaube allerdings das die KI dann echt gut beschäftigt wäre!

Waffengattungen:
Da ist das Problem, dass
a) die KI damit umgehen können muss
b) dass das Gefecht zumindest im Fall des in den Kontrollbereich einfahrenden Schiffes von diesem aus begonnen werden muss.... ansonsten könnte es ja einfach hindurchsegeln

Von der Festung aus einen Schuss auf ein "stillstehendes" Schiff abfeuern zu lassen, ist nicht das Thema..... ein richtiges Gefecht zu simulieren, wird schon spannender.

Improvements:
An so etwas hatte ich auch schon gedacht, aber die KI ist im Moment eh nicht in der Lage, halbwegs gescheite Bau- oder Verbesserungsentscheidungen zu treffen. Dann auch noch verfallende Feldverbesserungen instandzusetzen, dürfte noch eine Zeitlang jenseits des Horizontes liegen.

[Commander Bello]

Es geht Schrittchen für Schrittchen voran.

Nun wird die Wahrscheinlichkeit, den Kampf zu überleben, angezeigt und die für den Angreifer positiven Modifikatoren in Grün, die für ihn negativen Modifikatoren in Rot.
Die unteren "stack compare"-Werte werden aufgrund des derzeit aktivierten Cheatmodus angezeigt, aber nun auch farblich abgesetzt:

Vorher:

Achtung Spoiler:

Gegenwärtiger Zustand (andere Kampfsituation, um die unterschiedlichen Parameter besser darstellen zu können):



===
An "Plot Strength (Enemy)" sieht man übrigens noch derzeitige Schwächen des (Vanilla)-Kampfsystems: der Offensivwert der Verteidiger ist alles andere als 66 (kumuliert).

[Commander Bello]

Update:

Noch bestehende Fehler sind:
1) Im Moment ist das Kampflog noch kaputt. Ich vermute den Fehler (richtiger: die fehlende Anpassung an meine neuen Funktionalitäten) irgendwo in Python, habe die genaue Ursache aber noch nicht lokalisieren können.
2) Vanilla: Es ist unglaublich, was im Code vor sich geht.
Selbst Einheiten wie ein Schatz werden in alle möglichen Kampfberechnungen (und zwar nicht nur als potentielle Verteidiger, sondern ebenso auch als Angreifer) einbezogen. Dabei kommt es auch immer wieder zu Überprüfungen, ob die Einheit (handelsfähige) Yields (= Waren) laden kann. Das ist bei Einheiten wie einem Conquistador mal ganz besonders sinnvoll, weil ja auch nur 52 Yields geprüft werden ...
3) Vanilla: Es werden entweder aus Python, oder im schlimmsten Fall aus der .exe heraus bestimmte (Vanilla)-Kampfberechnungsroutinen aufgerufen, die letztlich nichts anderes tun, als es der von mir ersetzte Code auch schon tat. Warum das so ist, entzieht sich momentan noch meiner Kenntnis, ebenso wie ich noch nicht weiß, ob ich das ändern kann.

Kurz gesagt: der Code rechnet sich zu Tode, ohne dass es was bringt.
Auffallen tut mir das im Moment durch teils eigene, teils originale Asserts.
Ich habe z.Zt. vor, das fürs Erste zähneknirschend zu akzeptieren (es stellt keine Verschlechterung gegenüber dem Originalcode dar) und erst im Nachgang zu beheben.

Wichtig ist die Lösung von (1), denn ansonsten scheinen alle meine Änderungen bislang fehlerfrei zu laufen (habe allerdings bislang nur von einigen alten Spielständen ausgehend ein paar kleine Runden weitergeklickt).

===
neuer Bug... meine Galeone segelt nicht mehr aus Europa zurück. Manchmal ist's aber auch zum Verzweifeln.