Der SDK-Fragen-Thread

[Flunky]

Eine Funktion, die ein Objekt der Klasse/Struktur initialisiert und die den selben Namen wie die Klasse/Struktur trägt, ist ein Konstruktor. Nix abgefahrenes.

CBM_CombatDetails soll also für jeden Kampf eigens erstellt werden -> nicht static.

Zu welchem übergeordneten Objekt soll denn das CBM_CombatDetails-Objekt gehören? Zu einer der beteiligten Einheiten, zum Spiel, zur Welt?

[Commander Bello]

Einfach mal ein Beispiel was ich meine:

struct Data {

int x;
int y;

Data() 
{
    // Standardkonstruktor
    x = 0;
    y = 0;
}

Data(int a, int b)
{
    // Konstruktor mit Parametern
    x = a;
    y = b;
}

};

Mögliche Anwendung:

Data d1;   // Standardkonstruktor wird aufgerufen
Data d2(1, 2)  // Der Konstruktor mit entsprechenden Parametern wird aufgerufen

Hmmm...
Der Nebel scheint etwas lichter zu werden...

Eine Funktion, die ein Objekt der Klasse/Struktur initialisiert und die den selben Namen wie die Klasse/Struktur trägt, ist ein Konstruktor. Nix abgefahrenes.

CBM_CombatDetails soll also für jeden Kampf eigens erstellt werden -> nicht static.

Zu welchem übergeordneten Objekt soll denn das CBM_CombatDetails-Objekt gehören? Zu einer der beteiligten Einheiten, zum Spiel, zur Welt?

So wie ich das bisher vorhabe, gehört CBM_CombatDetails zu den Einheiten.
Aber ich habe noch mal kurz durch die Aufrufe geguckt und bin auf Schlechtigkeiten wie isBetterDefenderThan(...) gestoßen. Darin wird naturgemäß gleich wieder eine Stärkeberechnung durchgeführt, was aber meine bislang angedachte Vorgehensweise in Frage stellt.
Ich wollte nämlich die resultierende Stärke von pAttacker und pDefender in der Struktur quasi "zwischenspeichern". Das haut jetzt natürlich nicht mehr hin.
Ich muss die Stärke also vorher zurückgeben. Da ich die Stärken aber für pAttacker und pDefender zugleich ermittle, reicht ein Rückgabewert nicht aus.

Ich muss wohl im Funktionsaufruf von CBM_CombatStr(...) mit Pointern auf die Variablen in den Aufrufen arbeiten.
Oje.

Jedenfalls danke ich schon einmal für die Unterstützung bis hierher.

[Commander Bello]

Eigentlich kommt bei mir gleich die nächste Frage hoch:

Ich erweitere meine Funktion CvUnit::CBM_CombatStr(const CvUnit* pAttacker, const CvUnit* pDefender, const CvPlot* pPlot, CBM_CombatDetails* pCombatDetails, float& fAttackerStr, float& fDefenderStr)
Innerhalb werden nun zusätzlich noch fAttackerStr und fDefenderStr berechnet (mit den Werten, die auch in die CBM_CombatDetails geschrieben wurden, es handelt sich also um eine reine Zuweisung, die noch hinzukommt)

Danach rufe ich sie aus einer anderen Funktion XYZ auf:

XYZ()
{
...
float fAttStr; 
float fDefStr;
CBM_CombatStr(pAttacker, pDefender, pPlot, pCombatDetails, fAttStr, fDefStr)
...
}

Dann werden doch fAttStr und fDefStr innerhalb von CBM_CombatStr(...) ermittelt, aber direkt in die Variablen von XYZ geschrieben, oder nicht?

[Commander Bello]

Nächste Frage

Ich fülle eine Struktur struct CombatDetails mit den einzelnen Kampfwerten. Diese Struktur wird in der CyStructInterface1.cpp irgendwie für Python aufbereitet:

    python::class_<CombatDetails>("CombatDetails")
        .def_readwrite("iExtraCombatPercent", &CombatDetails::iExtraCombatPercent)
        .def_readwrite("iNativeCombatModifierTB", &CombatDetails::iNativeCombatModifierTB)
        .def_readwrite("iNativeCombatModifierAB", &CombatDetails::iNativeCombatModifierAB)
...

In der CvUtil.py werden diese Werte verwendet.

def combatDetailMessageBuilder(cdUnit, ePlayer, iChange):
    if (cdUnit.iExtraCombatPercent != 0):
        msg=localText.getText("TXT_KEY_COMBAT_MESSAGE_EXTRA_COMBAT_PERCENT",(cdUnit.iExtraCombatPercent * iChange,))
        CyInterface().addCombatMessage(ePlayer,msg)
...
def combatMessageBuilder(cdAttacker, cdDefender, iCombatOdds):

    if (cdAttacker.eVisualOwner != PlayerTypes.UNKNOWN_PLAYER):
        combatMessage = "%s's %s (%.2f)" %(gc.getPlayer(cdAttacker.eVisualOwner).getName(),cdAttacker.sUnitName,cdAttacker.iCurrCombatStr/100.0,)
....

Wo genau geschieht die "Übersetzung" von &CombatDetails::iExtraCombatPercent in cdUnit.iExtraCombatPercent?
Und wo geschieht die Aufteilung zwischen cdUnit, cdAttacker und cdDefender?

Ich suche mir hier einen Wolf und sehe es nicht.

Nachtrag:
Ich sehe, dass es in der CvDLLPython.cpp eine Funktion DllExport void DLLPublishToPython() gibt:

DllExport void DLLPublishToPython()
{
...
    CyStructsPythonInterface1();
...

Bedeutet das, dass alles, was in der oben gezeigten python::class_<CombatDetails>("CombatDetails") definiert wurde, automatisch von CvUtil.py übernommen wird?
Dann bliebe nur noch die Frage, wo Python den Unterschied zwischen cdUnit, cdAttacker und cdDefender ableitet?

[alpha civ]

Willst du wirklich eine ausführliche Erklärung, wie man C++ -Code an Python anbinden kann? Bzw. wie der Python-Interpreter in C++ eingebettet werden kann?

Dann würde ich dir diese Seite empfehlen: https://docs.python.org/3/extending/index.html

[Commander Bello]

Willst du wirklich eine ausführliche Erklärung, wie man C++ -Code an Python anbinden kann? Bzw. wie der Python-Interpreter in C++ eingebettet werden kann?

Dann würde ich dir diese Seite empfehlen: https://docs.python.org/3/extending/index.html

Mir würde eigentlich ausreichen, wenn jemand mir aufzeigen könnte, wie die Zuordnung im vorliegenden Fall geschieht.

[alpha civ]

Wo genau geschieht die "Übersetzung" von &CombatDetails::iExtraCombatPercent in cdUnit.iExtraCombatPercent?

Die Kurzfassung ist, dass dies bei deinem ersten Code-Teil passiert. Mehr brauchst du auch nicht wissen, um es anwenden zu können.

Und wo geschieht die Aufteilung zwischen cdUnit, cdAttacker und cdDefender?

Hier verstehe ich die Frage nicht so ganz? Das sind einfach nur Parameter Funktion.

Nachtrag:
Ich sehe, dass es in der CvDLLPython.cpp eine Funktion DllExport void DLLPublishToPython() gibt:

DllExport void DLLPublishToPython()
{
...
    CyStructsPythonInterface1();
...

Bedeutet das, dass alles, was in der oben gezeigten python::class_<CombatDetails>("CombatDetails") definiert wurde, automatisch von CvUtil.py übernommen wird?

Nicht nur von CvUtil.py. Es ist generell in Civ4-Python verfügbar.

Dann bliebe nur noch die Frage, wo Python den Unterschied zwischen cdUnit, cdAttacker und cdDefender ableitet?

Es sind verschiedene Parameter. Was soll es da für einen Unterschied geben?

[Commander Bello]

Zitat von Commander Bello
Wo genau geschieht die "Übersetzung" von &CombatDetails::iExtraCombatPercent in cdUnit.iExtraCombatPercent?

Die Kurzfassung ist, dass dies bei deinem ersten Code-Teil passiert. Mehr brauchst du auch nicht wissen, um es anwenden zu können.

Der Witz ist, dass die Struktur halt CombatDetails heißt. Nirgendwo wird ein Pointer cdUnit gesetzt oder eine Variable cdUnit angelegt.

Daher meine Fragen unten:

Und wo geschieht die Aufteilung zwischen cdUnit, cdAttacker und cdDefender?

Hier verstehe ich die Frage nicht so ganz? Das sind einfach nur Parameter Funktion.

Dann bliebe nur noch die Frage, wo Python den Unterschied zwischen cdUnit, cdAttacker und cdDefender ableitet?

Es sind verschiedene Parameter. Was soll es da für einen Unterschied geben?

cdAttacker und cdDefender sind tatsächlich im Code als Variablen vom Datentyp der Struktur CombatDetails definiert worden. Daher überrascht mich der Zugriff auf diese Elemente (cdAttacker.XYZ) auch nicht weiter.
Hingegen der auf cdUnit.iExtraCombatPercent schon, weil es dafür halt keine Variable gibt.

Ich habe aber darüber hinausgehend gleich noch eine Frage:
Aus einer Funktion CvUnit::isBetterDefenderThan(const CvUnit *pDefender, const CvUnit *pAttacker...) heraus will ich auf die Funktion getCombatOdds(CvUnit* pAttacker, CvUnit* pDefender) zugreifen:
int iOurOdds = getCombatOdds(pAttacker, this);

Nur meckert der Compiler dann: 1>CvUnit.cpp(2323): error C2664: 'getCombatOdds' : cannot convert parameter 1 from 'const CvUnit *' to 'CvUnit *'

Es ist richtig, dass die getCombatOdds(...) nicht mit "const CvUnit*" definiert wurde. Das könnte ich ändern, klar.
Allerdings wird diese Funktion von einer Reihe anderer Funktionen aufgerufen, bei denen der Parameter pAttacker innerhalb des Funktionsrumpfes per "CvUnit* pAttacker;" definiert wurde.
Wenn ich aber nicht von "const CvUnit*" nach "CvUnit*" übersetzen kann, dann kann ich doch vermutlich auch nicht von "CvUnit*" nach "const CvUnit*" übersetzen?

Wie also kann ich meinen Parameter pAttacker so ummodeln, dass ich ihn an die getCombatOdds() durchschieben kann?

[rucivfan]

Du kannst "nicht const" const übergeben, aber nicht const "nicht const" übergeben.

[Commander Bello]

Du kannst "nicht const" const übergeben, aber nicht const "nicht const" übergeben.

Da musste ich erst zweimal lesen ...

Das würde bedeuten, ich definiere die getCombatOdds() um, und bin zumindest in der Hinsicht schon mal einen Schritt weiter?

[rucivfan]

Sollte gehen. Ich kenne aber die Methode/ Funktion nicht, kann mir aber auch nciht denken, warum sie was am Klassenstatus ändern sollte. Man gibt sich ja nur einen Wert.

[Commander Bello]

Sollte gehen. Ich kenne aber die Methode/ Funktion nicht, kann mir aber auch nciht denken, warum sie was am Klassenstatus ändern sollte. Man gibt sich ja nur einen Wert.

[alpha civ]

Der Witz ist, dass die Struktur halt CombatDetails heißt. Nirgendwo wird ein Pointer cdUnit gesetzt oder eine Variable cdUnit angelegt.

Daher meine Fragen unten:

cdAttacker und cdDefender sind tatsächlich im Code als Variablen vom Datentyp der Struktur CombatDetails definiert worden. Daher überrascht mich der Zugriff auf diese Elemente (cdAttacker.XYZ) auch nicht weiter.
Hingegen der auf cdUnit.iExtraCombatPercent schon, weil es dafür halt keine Variable gibt.

Aber das sind doch Parameter der Funktion. Die können sonst wie heißen.

>>> def foo(x, y, z):
	print(x, y, z)

	
>>> foo(1,2,3)
1 2 3
>>> z = 1
>>> y = 3
>>> x = 2
>>> foo(z,x,y)
1 2 3

[Commander Bello]

Aber das sind doch Parameter der Funktion. Die können sonst wie heißen.

Ja, das war mir schon klar. Mir ging es darum, zu wissen, wo sie definiert werden - weil ich hoffte, an dieser Stelle den Informationstransport zwischen DLL und Python zu erkennen (was, wie ich mittlerweile erkannt habe, eine irrige Annahme war).

Wo die beiden Paramter cdAttacker und cdDefender definiert werden, habe ich mittlerweile gefunden: in der CvEventManager.py:

    def onCombatLogCalc(self, argsList):
        'Combat Result'
        genericArgs = argsList[0][0]
        cdAttacker = genericArgs[0]
        cdDefender = genericArgs[1]
        iCombatOdds = genericArgs[2]
        CvUtil.combatMessageBuilder(cdAttacker, cdDefender, iCombatOdds)

Leider bringt mich das noch nicht wirklich weiter.
Ich habe nämlich in der CyUnit.cpp einige Funktionen auskommentiert, die auf nicht mehr verfügbare Funktionen zurückgreifen.

/* CBM  0.8.047 not used 
int CyUnit::currCombatStr(CyPlot* pPlot, CyUnit* pAttacker) // TODO CBM no calls for this function?
{
    return m_pUnit ? m_pUnit->currCombatStr(pPlot->getPlot(), pAttacker->getUnit()) : -1;
} CBM  0.8.047 not used */

Da Col aber nun mit der neuen DLL immer brav mit einer Zugriffsverletzung bei xyz abbricht, muss ich leider davon ausgehen, dass das Auskommentieren nicht die allerbeste Idee gewesen sein mag.
Nun suche ich, wo die Übergabe zwischen DLL und Python definiert ist. Wenn ich das als Vorlage sehe, sollte ich in der Lage sein, mir neue Funktionen zur Übergabe der auf die neue Weise ermittelten Parameter zu erstellen.
Aber an dieser Stelle hänge ich halt gerade mit meiner Ahnungslosigkeit.

Wo und wie Python z.B. den Wert der oben blau markierten currCombatStr(pPlot, pAttacker) abgreift, ist mir halt nicht ersichtlich.

[alpha civ]

Ich habe nämlich in der CyUnit.cpp einige Funktionen auskommentiert, die auf nicht mehr verfügbare Funktionen zurückgreifen.

/* CBM  0.8.047 not used 
int CyUnit::currCombatStr(CyPlot* pPlot, CyUnit* pAttacker) // TODO CBM no calls for this function?
{
    return m_pUnit ? m_pUnit->currCombatStr(pPlot->getPlot(), pAttacker->getUnit()) : -1;
} CBM  0.8.047 not used */

Hast du die entsprechenden Funktions-Deklarationen in CyUnit.h auch auskommentiert?