Der SDK-Fragen-Thread

[rucivfan]

Ich denke, dass liegt nicht an bestInterceptor und currInterceptionProbability. Bei 20 Einheiten sollten diese Methoden nicht die Ursache sein. Die neue Code-Zeile mit "getGroup()->clearMissionQueue();" in der CvUnit::airStrike sollte die Ursache sein, denke ich. Der Befehl wirkt sich auf die Animationen aus.

[Kathy]

Aber warum nur, wenn ich 20 Sams angreifen - und nicht, wenn ich eine angreife?

[Pie]

Habe da nach einigen Runden einen Fehler an dieser Stelle:

CvFeatureInfo& CvGlobals::getFeatureInfo(FeatureTypes eFeatureNum)
{
FAssert(eFeatureNum > -1);
FAssert(eFeatureNum < GC.getNumFeatureInfos());
return *(m_paFeatureInfo[eFeatureNum]);
}

Er spuckt mir FAssert(eFeatureNum > -1); raus und CtD.
Was ist nun mein nächster Schritt? Wo finde ich heraus bei welchem Plot das passiert? Oder wie kann ich ihm sagen, bei welchem Plot er das Feature findet, das kein Feature ist?

[rucivfan]

Features sind zum Beispiel Wälder. Wenn ein Feature von einem Plot abgefragt wird, der kein Feature enthält, können natürlich auch keine Informationen wiedergegeben werden. Irgendwo fehlt eine Sicherheitsabfrage, ob es überhaupt ein Feature gibt. Mit normalen Debuggen sollte das schnell zu finden sein, außer der Fehler sitzt im Pythoncode. Welcher Plot das ist, sollte eigentlich keine Rolle spielen.

[Pie]

Tatsache. Fehler gefunden. Aber das muss doch schnell! Bin alle getFeatureType() in den cpp-Dateien durchgegangen und dort wo kein getFeatureType() == NO_FEATURE war, wars dann auffällig. Es war bei CvUnitAI bei AI_exploreMove...
Aber so den Fehler finden ist verdammt mühsam! Hätte ich einen Plot, könnte ich dort erfahren, was alles ein kann.

Abgesehen davon, dass es bei einem fortgeschrittenen Szenario zwischen Runde 50-100 passiert und bei einem anderen fix bei Runde 5.

Danke ruci für den Denkanstoß!

[Kathy]

Tatsache. Fehler gefunden. Aber das muss doch schnell! Bin alle getFeatureType() in den cpp-Dateien durchgegangen und dort wo kein getFeatureType() == NO_FEATURE war, wars dann auffällig. Es war bei CvUnitAI bei AI_exploreMove...
Aber so den Fehler finden ist verdammt mühsam! Hätte ich einen Plot, könnte ich dort erfahren, was alles ein kann.

Abgesehen davon, dass es bei einem fortgeschrittenen Szenario zwischen Runde 50-100 passiert und bei einem anderen fix bei Runde 5.

Danke ruci für den Denkanstoß!

Wenn man in Visual C++ das Projekt im "Debuggen"-Modus startet, kann man sich beim Absturz den Aufrufstapel ansehen, da sieht man, welche Funktionen gerade in dem Moment aktiv sind, und teilweise, welche Variablen gerade in dem aufgerufenen Code betroffen sind. Das Problem ist, dass das sehr viel langsamer läuft als im normalen Start mit der Debug.dll, weshalb ich das meistens vermeide.

[Pie]

Nun gut. Jetzt gibts ein anderes Problem. Ein endless turn in der dll.
Nach meinen alten Methoden (via Python Spieler ausfindig machen, im Editor Stück für Stück Einheiten entfernen und als WB Save laden) tritt es auf, wenn die UNIT_HUNTER in einer STADT steht und UNITAI_WORKER hat.

Interessanterweise, wenn ich diese Einheit lösche, geht es normal weiter, die KI baut sich wieder einen Hunter mit UNITAI_WORKER, setzt ihn neben die Stadt und baut das Lager. Wieso gehts bei dem und bei dem im Save nicht?

Also wie kann ich herausfinden, in welcher Funktion und welcher Datei (wahrscheinlich in CvUnitAI) der endless turn verursacht wird?

[rucivfan]

Eine Abweichung zwischen der real möglichen Bewegung und der vom KI-Code für möglich gehaltenen Bewegung von Einheiten ist wahrscheinlich die Ursache. Dies hat schon bei Base zu Endlosschleifen geführt. Der KI-Code findet einen Weg, aber wenn die Bewegung ausgeführt wird, kann diese Bewegung wegen eines nicht eingeplanten Hindernisses nicht ausgeführt werden und der KI-Code entscheidet erneut, kommt aber wieder zum gleichen Ergebnis und läuft endlos. Konkret liegt der Fehler nicht in einer Funktion oder Datei, sondern das Fehlen notwendiger Abfragen, um Unmögliches in der Gesamtstruktur der KI- Abläufe zu verhindern, ist die Ursache. Dies ist auf den schlechten Civ-4-KI-Code und der vermutlichen "Leistungsoptimierung" des KI-Codes zurückzuführen. Wenn die Kürzeste-Wege-Suche aus Performancegründen für KI-Berechnungen vereinfacht ist, aber unmögliche Bewegungen als möglich findet, muss dieser Fall zumindest doch abgefangen werden. Wie man das herausfindet? Nur durch das Setzen von Haltepunkten beim Debuggen mit Hilfe einer Debug-DLL konnte ich dies in der Vergangenheit herausfinden. Das ist sehr mühsam.

Warum das bei einer neuen Einheit mit gleicher Aufgabe nicht passiert? KI-Code enthält Zufallsabfragen, aber auch die ID der Einheit hat in manchen Fällen Auswirkungen und kann einfach was anderes entscheiden. Diese Zufallsabfragen haben für dieselbe Einheit unterschiedliche Ergebnisse, wenn der KI-Code fehlschlägt, haben aber meist nur geringen Einfluss auf das Ergebnis.

[Pie]

Ich habs befürchtet.
Schrecklich.... Modden soll doch Spaß machen....

Also mach ich das jetzt mit einzelnen return-Zeilen in der Funktion, um herauszufinden bei welcher Funktion der endless turn ist. Wie in python nur mit dem Unterschied, dass ich den Schmarrn complieren muss und das Spiel neu starten muss.... das extrem viel Zeit mehr beansprucht als Fehler in python zu finden.... habe d'Ehre....

[Pie]

Hab den endless turn gefunden und ausgemerzt. Dabei frag ich mich: Hab ich eine veraltete Version der cpp-Dateien?!!?
Ohne dll kann ich Einheiten Sachen zum Bauen geben, ohne dass sie Straßen bauen müssen dürfen.
Mit der dll gings nicht und ich hatte das Problem jetzt beim Jäger gesehen. Grund in der Funktion AI_improveBonus():

                if ((pBestPlot->getWorkingCity() == NULL) || !pBestPlot->getWorkingCity()->isConnectedToCapital())
                {
                    eBestMission = MISSION_ROUTE_TO;
                }
                else
                {
                    int iDistance = stepDistance(getX_INLINE(), getY_INLINE(), pBestPlot->getX_INLINE(), pBestPlot->getY_INLINE());
                    int iPathTurns;
                    if (generatePath(pBestPlot, 0, false, &iPathTurns))
                    {
                        if (iPathTurns >= iDistance)
                        {
                            eBestMission = MISSION_ROUTE_TO;
                        }
                    }
                } 

Was ich nun so geändert habe und jetzt gibts keinen endless turn (logisch, weil der Hunter ja keine Straßen bauen soll, sondern lediglich Camps):

            // PAE
            if (bCanRoute) {
                if ((pBestPlot->getWorkingCity() == NULL) || !pBestPlot->getWorkingCity()->isConnectedToCapital())
                {
                    eBestMission = MISSION_ROUTE_TO;
                }
                else
                {
                    int iDistance = stepDistance(getX_INLINE(), getY_INLINE(), pBestPlot->getX_INLINE(), pBestPlot->getY_INLINE());
                    int iPathTurns;
                    if (generatePath(pBestPlot, 0, false, &iPathTurns))
                    {
                        if (iPathTurns >= iDistance)
                        {
                            eBestMission = MISSION_ROUTE_TO;
                        }
                    }
                }
            } 

Ich frag mich echt, wie macht das BTS? Warum hatte ich das Problem bei der reinen 52er dll nie..... Hab ich da andere cpp-Dateien? Von Warlords oder von Vanilla? Wie erkenn ich das?

Und das nächste was ich in dieser Funktion nicht verstehe: gleich darunter steht:

            eBestBuild = AI_betterPlotBuild(pBestPlot, eBestBuild);
            getGroup()->pushMission(eBestMission, pBestPlot->getX_INLINE(), pBestPlot->getY_INLINE(), 0, false, false, MISSIONAI_BUILD, pBestPlot);
            getGroup()->pushMission(MISSION_BUILD, eBestBuild, -1, 0, (getGroup()->getLengthMissionQueue() > 0), false, MISSIONAI_BUILD, pBestPlot); 

Da hebt sich doch das erste pushMission auf ?!
Oder bedeutet pushMission an die Liste der bisherigen Bauaufträge dranhängen?

[rucivfan]

Da hebt sich doch das erste pushMission auf ?!
Oder bedeutet pushMission an die Liste der bisherigen Bauaufträge dranhängen?

Da man Einheiten befehlen kann, Missionsketten auszuführen, funktioniert dies auch im Ki-Code. Also ja, das ist eine Missionsliste und Push füttert sie.

[Pie]

ja, mir ist grad eingefallen, ich hätte ja selber nachsehn können

Aber ruci? Habt ihr in BASE keine Einheiten, die etwas bauen können, nur keine Straßen?

[rucivfan]

Aber ruci? Habt ihr in BASE keine Einheiten, die etwas bauen können, nur keine Straßen?

Das Problem tritt nur auf, wenn eine Einheit etwas bauen soll, aber keine Straßen bauen kann? Sowas gibt es nicht in BASE.

[Pie]

Genau. Ok. Jetzt wisst ihr es, falls ihr das jemals braucht, ein if (bCanRoute) {} bei AI_improveBonus() einzubauen....

[rucivfan]

Die Zeile unter den pushMission-Aufrufe

else if (bBestBuildIsRoute)

sollte mit

else if (bBestBuildIsRoute && bCanRoute)

ergänzt werden. AI_connectPlot folgend schiebt dann auch Straßenbauten an, prüft aber nicht mehr, ob die Einheit dies tun kann. In einem theoretischen Fall kann es zu einer Endlosschleife kommen.

Ich glaube, weitere Anpassungen sind in oder mit den Methoden AI_connectPlot, AI_connectBonus, AI_routeCity und AI_routeTerritory notwendig. Alle vier Methoden werden hier und dort mal aufgerufen. Sie pushen den Straßenbau, aber prüfen nicht, ob die Einheit das kann. edit: Gut, in vielen anderen Fällen wird vor dem Aufruf geprüft, ob die Einheit Straßen bauen kann. Ich habe wohl die einzigste Stelle gefunden, wo das nicht vorher geprüft wurde.