Der SDK-Fragen-Thread

[Commander Bello]

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

Hmm.. das habe ich wohl nicht getan...

Die Zugriffsverletzung (zumindest die, an der ich bislang gescheitert bin - ich habe schon eine neue ) lag übrigens an etwas anderem. Man sollte Strukturen auch so verwenden, wie es vorgesehen ist, wie ich auf die harte Tour gelernt habe.

[alpha civ]

Dann sollte auch noch der Kompilermeckern bei der entsprechenden Interface-Datei von Unit, weil es die entsprechende Methode nicht mehr gibt. Das müsste in etwa so eine Zeile sein:

.def("currCombatStr", CyUnit::currCombatStr)

Hier wird sich der Kompiler melden, weil dann currCombatStr nicht mehr da ist. Derzeit scheint es so zu sein, dass die Methode noch da ist, aber weil es keine Implementierung der Methode gibt (weil du sie auskommentiert hast), kommt es dann beim Aufruf zu deiner Fehlermeldung.

(Aber eigentlich müsste sich doch der Linker melden, weil der die Definition nicht finden kann. )

[Commander Bello]

Dann sollte auch noch der Kompilermeckern bei der entsprechenden Interface-Datei von Unit, weil es die entsprechende Methode nicht mehr gibt. Das müsste in etwa so eine Zeile sein:

.def("currCombatStr", CyUnit::currCombatStr)

Hier wird sich der Kompiler melden, weil dann currCombatStr nicht mehr da ist. Derzeit scheint es so zu sein, dass die Methode noch da ist, aber weil es keine Implementierung der Methode gibt (weil du sie auskommentiert hast), kommt es dann beim Aufruf zu deiner Fehlermeldung.

(Aber eigentlich müsste sich doch der Linker melden, weil der die Definition nicht finden kann. )

Na, in der CyUnitInterface1.cpp hatte ich die fraglichen Funktionen auch brav abgemeldet.

Ich habe sie übrigens in der Zwischenzeit umgeschrieben, so dass sie nun zu meinen Änderungen (halbwegs) passen. Genaueres weiß ich allerdings noch nicht, weil ich im Moment eine Zugriffsverletzung bei CvUnit::getProfession() bekomme - warum auch immer.

ProfessionTypes CvUnit::getProfession() const
{
    return m_eProfession;
}

Es ist ja nun nicht so, als sei diese Funktion als übermäßig fehlerträchtig anzusehen...
Es ist zwar richtig, dass die entsprechende Unit keine Profession hat, aber das ist ja gang und gäbe. Vor allem ist das in einem bestehenden Spielstand, der hätte also eigentlich auch früher schon in die Knie gehen sollen...

[rucivfan]

Es gibt da nur einen Grund für eine Zugriffsverletzung und der ist, dass m_eProfession einfach keine Speicherzuweisung hat. Du musst m_eProfession mindestens beim erstellen der Einheiten mit einen Standardwert belegen für "Nichts". Meistens ist das -1 bzw wird dies über Enumeration häufig -1 gesetzt.

edit: siehe einfach CvUnit::reset an. Dort werden die Standardwerte für alle anderen Werte gesetzt.

[Commander Bello]

Es gibt da nur einen Grund für eine Zugriffsverletzung und der ist, dass m_eProfession einfach keine Speicherzuweisung hat. Du musst m_eProfession mindestens beim erstellen der Einheiten mit einen Standardwert belegen für "Nichts". Meistens ist das -1 bzw wird dies über Enumeration häufig im Code -1 gesetzt.

Ja, -1 als Wert hat die Profession ganz sicher nicht, eher irgendwas um die -8000234234 (so aus dem Kopf heraus). Der Witz ist, dass ich mit Professions absolut gar nichts gemacht habe, das ist noch der Zustand von vor meinen Änderungen. Trotzdem fliegt es mir jetzt gerade um die Ohren.
Kann es sein, dass eine Debug-DLL in der Hinsicht empfindlicher reagiert? Die Zugriffsverletzung als solche wird der Civilization.exe zugeordnet, aber es wurden in der Abbruchsmeldung Speicherstellen sowohl in der DLL wie in der .exe angegeben.

[rucivfan]

Ja, -1 als Wert hat die Profession ganz sicher nicht, eher irgendwas um die -8000234234 (so aus dem Kopf heraus).

Dann trifft mit 100% meine Aussage oben zu. Wenn eine Adresse im Speicher nicht gesetzt wird, kann sonst was für einen Wert drinn stehen.

Der Witz ist, dass ich mit Professions absolut gar nichts gemacht habe, das ist noch der Zustand von vor meinen Änderungen. Trotzdem fliegt es mir jetzt gerade um die Ohren.

Ausrede!!!

Kann es sein, dass eine Debug-DLL in der Hinsicht empfindlicher reagiert?

In wie weit empfindlicher? Wenn die release abstürzt, dann die debug erst Recht, aber man kann schauen wo es passiert. Ich kann nur sicher sagen, dass Win 7 empfindlicher als Win XP ist. Das war mal im BASE-Mod ein Problem als ich noch XP hatte.

Die Zugriffsverletzung als solche wird der Civilization.exe zugeordnet, aber es wurden in der Abbruchsmeldung Speicherstellen sowohl in der DLL wie in der .exe angegeben.

Das ist richtig so. Die Exe ruft ja schließlich Code aus der DLL auf!

edit: siehe einfach CvUnit::reset an. Dort werden die Standardwerte für alle anderen Werte gesetzt.

siehe da

[Commander Bello]

In wie weit empfindlicher? Wenn die release abstürzt, dann die debug erst Recht, aber man kann schauen wo es passiert. Ich kann nur sicher sagen, dass Win 7 empfindlicher als Win XP ist. Das war mal im BASE-Mod ein Problem als ich noch XP hatte.

Naja, ich verwende halt einen alten Spielstand, den ich mit der Release-DLL (= alte DLL-Version) auch problemlos spielen konnte. Da war ich dann schon 20 Züge weiter.
Mit der neu kompilierten Debug-DLL ... peng.

Aus der CvUnit::reset:
m_eProfession = NO_PROFESSION;

Und NO_PROFESSION ist mit -1 enumeriert.

Hmm.. komisch.

[rucivfan]

Es kann auch indirekt sein. Nehmen wir mal an, es gibt die Einheit garnicht. Dann wurde der Wert auch nie mit reset gesetzt. Und trotzdem wird versucht, auf die nicht existierende Einheit zu zugreifen.

Du musst mal im Stack eine Etage tiefer schauen. Besser: Poste den relevanten Teil des Stackes. Relevant: Liegt im SDK.

[Commander Bello]

Doch, die Einheit gibt es, mit meiner neuen, feinen Struktur konnte ich mir nämlich ihren Namen ansehen...

Stack poste ich später, ich muss jetzt erst mal weg.

[rucivfan]

Feine Struktur sagt schon alles. Du hast keine Savegameskombatiblität, wenn du keinen Anpasscode geschrieben hast. Genaueres kann ich ohne Vollständigen Code des davor und danach nicht sagen. Aber poste erstmal den Stack.

[Commander Bello]

Feine Struktur sagt schon alles. Du hast keine Savegameskombatiblität, wenn du keinen Anpasscode geschrieben hast.

Die brauche ich in diesem Falle auch nicht. Meine Struktur wird mit allen kampfrelevanten Daten der Einheiten gefüllt, damit sich die aufrufenden Funktionen dann daraus bedienen können. Das geschieht zur Laufzeit, und schon die vorherige Runde, resp. die vorherige Kampfwertberechnung ist für diesen Vorgang egal - und muss es auch sein.

Genaueres kann ich ohne Vollständigen Code des davor und danach nicht sagen. Aber poste erstmal den Stack.

Yep. Ich muss mich jetzt erst noch durch die ganzen Haltepunkte klicken

[Commander Bello]

Die Stackliste und darunter in den Spoilern die entsprechenden Code-Ausschnitte.

>    CvGameCoreDLL.dll!CvUnit::getProfession()  
     CvGameCoreDLL.dll!CvUnit::noDefensiveBonus()  
     CvGameCoreDLL.dll!CvUnit::CBM_CombatStr(const CvUnit * pAttacker, const CvUnit * pDefender, const CvPlot * pPlot, CBM_CombatDetails * pCBM_CombatDetails)  
     CvGameCoreDLL.dll!getCombatOdds(const CvUnit * pAttacker, const CvUnit * pDefender)
     CvGameCoreDLL.dll!CvUnit::isBetterDefenderThan(const CvUnit * pDefender, const CvUnit * pAttacker, bool bBreakTies)
     CvGameCoreDLL.dll!CvPlot::getBestDefender(PlayerTypes eOwner, PlayerTypes eAttackingPlayer, const CvUnit * pAttacker, bool bTestAtWar, bool bTestPotentialEnemy, bool bTestCanMove)
     CvGameCoreDLL.dll!CvPlot::updateCenterUnit()
     CvGameCoreDLL.dll!CvMap::updateCenterUnit()

getProfession hatte ich ja schon gepostet.
Das ist der Wert für eProfession: eProfession -858993460
Enumeration der ProfessionTypes:

Achtung Spoiler:

enum DllExport ProfessionTypes
{
    INVALID_PROFESSION = -2,
    NO_PROFESSION = -1,
};

noDefensiveBonus()

Achtung Spoiler:

bool CvUnit::noDefensiveBonus() const // TODO CBM shouldn't the profession check be encapsulated in the unit check? 
{
    ProfessionTypes eProfession = getProfession();
    if (eProfession != NO_PROFESSION && GC.getProfessionInfo(eProfession).isNoDefensiveBonus())
    {
        return true;
    }

    if (m_pUnitInfo->isNoDefensiveBonus())
    {
        return true;
    }

    return false;
}

CBM_CombatStr(...) - Ausschnitt

Achtung Spoiler:

        if (pDefender != NULL)
        {
            // CBM step 016: iPlotDefenseModifier
            if  (!noDefensiveBonus()) // CBM this will give you the defense modifiers of that PLOT! Unit defense modifiers are allocated below
            {

getCombatOdds(...) - Ausschnitt

Achtung Spoiler:

    CBM_CombatDetails cdCombatOdds;
    pAttacker->CBM_CombatStr(pAttacker, pDefender, pPlot, &cdCombatOdds);

    FAssert((cdCombatOdds.fCurrCombatStrAtt + cdCombatOdds.fCurrCombatStrDef) > 0);
...

isBetterDefenderThan(...) - Auschnitt

Achtung Spoiler:

    int iOurOdds = getCombatOdds(pAttacker, this);
    int iTheirOdds = getCombatOdds(pAttacker, pDefender);

getBestDefender(...) - Ausschnitt

Achtung Spoiler:

                            if (!bTestCanMove || pLoopUnit->canMove())
                            {
                                if (pLoopUnit->isBetterDefenderThan(pBestUnit, pAttacker, true))
                                {
                                    pBestUnit = pLoopUnit;
                                }
                            }

Und der Vollständigkeit halber noch die Fehlermeldung:
Unbehandelte Ausnahme bei 0x05660f71 (CvGameCoreDLL.dll) in Colonization.exe: 0xC0000005: Zugriffsverletzung beim Lesen an Position 0x000000f0.

[rucivfan]

mmh, CvMap::updateCenterUnit() bzw CvPlot::updateCenterUnit() wählt die Einheit, die als erstes grafisch auf den Feld angezeigt werden soll. Ehrlich gesagt, würde ich hier weiter plädieren, dass eine Einheit als Übergabewert ein NULL-Pointer ist.

Und zwar denke ich, dass pAttacker als Übergabewert gleich NULL (0) ist.

edit: Dann müsste der Fehler in getCombatOdds(...) liegen. Dort wird schließlich auf pAttacker zugegriffen.

[Commander Bello]

mmh, CvMap::updateCenterUnit() bzw CvPlot::updateCenterUnit() wählt die Einheit, die als erstes grafisch auf den Feld angezeigt werden soll. Ehrlich gesagt, würde ich hier weiter plädieren, dass eine Einheit als Übergabewert ein NULL-Pointer ist.

Und zwar denke ich, dass pAttacker als Übergabewert gleich NULL (0) ist.

edit: Dann müsste der Fehler in getCombatOdds(...) liegen. Dort wird schließlich auf pAttacker zugegriffen.

Respekt!
pAttacker ist tatsächlich NULL in getCombatOdds(...).

Und den Fehler habe offensichtlich ich gemacht , denn ich habe in der isBetterDefenderThan(...) noch den Vergleich der Wahrscheinlichkeiten eingebaut.

Dass du das so auf einen Blick gesehen hast... Donnerwetter!

Ok, da muss ich mir mal Gedanken machen. Jetzt werde ich den Teil einfach auskommentieren und noch mal laufen lassen....

[Commander Bello]

Die unendliche Geschichte geht weiter...

Nachdem die updateCenterUnit()-Funktionen in den Cv::Map/CvPlot durchlaufen wurden, bricht das Spiel ab, weil eine Prozedur nicht gefunden wurde.
Nun zermartere ich mir das Schwachhirn, was ich wohl auskommentiert/geändert haben könnte, und nun gesucht wird.

Mein Problem ist, dass ich für die void CvMap::updateCenterUnit() keinen Aufruf finde, und daher nicht weiß, um welche Prozedur es sich handeln könnte, noch, an welcher Stelle es in der DLL dann weiter gehen könnte.

Gibt es in VC2010 eine Möglichkeit, alle zurückliegenden Änderungen an der Projektmappe anzuzeigen (also auch die von vorherigen Sessions)?

Achtung Spoiler:

Unbehandelte Ausnahme bei 0x7652c42d (KernelBase.dll) in Colonization.exe: 0xC06D007F: Procedure not found.

Aufrufstapel:

>    KernelBase.dll!RaiseException()  + 0x58 Bytes    

     [Unten angegebene Rahmen sind möglicherweise nicht korrekt und/oder fehlen, keine Symbole geladen für KernelBase.dll]    

     Colonization.exe!004cefa0()     

     kernel32.dll!HeapFree()  + 0x14 Bytes    

     msvcr71.dll!free()  + 0x39 Bytes    

     msvcp71.dll!std::basic_string<unsigned short,std::char_traits<unsigned short>,std::allocator<unsigned short> >::_Tidy()  + 0x31 Bytes

Das sind die letzten Zeilen nachdem das Debugging abgebrochen wurde:

...
(Anzeige der geladenen xml-Dateien)
...
LoadCivXml (xml\GameInfo/CIV4DiplomacyInfos.xml)
Eine Ausnahme (erste Chance) bei 0x7652c42d (KernelBase.dll) in Colonization.exe: 0xC06D007F: Procedure not found.
Unbehandelte Ausnahme bei 0x7652c42d (KernelBase.dll) in Colonization.exe: 0xC06D007F: Procedure not found.
Das Programm "[6176] Colonization.exe: Systemeigen" wurde mit Code 0 (0x0) beendet.