Der SDK-Fragen-Thread

[rucivfan]

Meinst du es bringt etwas CyCityInterface1 auf zwei Dateien zu splitten?

Das habe ich schon mehrfach gemacht und ja, das bringt es.

[Ramkhamhaeng]

Danke. Nach dem Teilen auf zwei Dateien rumpelt der Kompiler weiter.

Neben VS 2010 ist auch noch 2017 installiert. Da bekam ich das Projekt, glaube ich, aber nie zum kompilieren und außerdem fiel ihm nach dem Starten ein dass die 30 Tage Testversion abgelaufen sind

[Ramkhamhaeng]

Einen hartnäckigen Fehler habe ich noch
Die vorletzte Zeile des Python-Codes schmeißt eine "undefined C++-Exception". Alle späteren Aufrufe von ähnlicher Struktur funktionieren und auch der Aufruf ohne Variablenübergabe darüber klappt.

        self.UPDATES_FAIL = u"<font=4>" + localText.getText("TXT_KEY_UPDATER_FAIL", ()).upper() + "</font>"

        nU = len(self.updater.PendingUpdates)
        print("Num of available updates: %d" % (nU,))
        self.UPDATES_AVAIL = u"<font=4>" + localText.getText("TXT_KEY_UPDATER_AVAIL", (0,)).upper() + "</font>"
        self.UPDATES_AVAIL = u"<font=4>" + localText.getText("TXT_KEY_UPDATER_AVAIL", (nU,)).upper() + "</font>"

Die Fehlermeldung, bei der man schlecht Debuggen kann:

  File "CvModUpdaterScreen", line 121, in setCommonWidgets

RuntimeError: unidentifiable C++ exception
ERR: Python function onEvent failed, module CvEventInterface

[Ramkhamhaeng]

Das vielleicht Wichtigste hatte ich vergessen: XML-Token sieht so aus:

	<TEXT>
		<Tag>TXT_KEY_UPDATER_AVAIL</Tag>
		<English>%d1 [NUM1:Update:Updates] available!</English>
		<French></French>
		<German>%d1 [NUM1:Update:Updates] verfügbar!</German>
		<Italian></Italian>
		<Spanish></Spanish>
	</TEXT>

CyTranslator().getText() liegt leider nicht in der DLL sondern der Exe.

Edit: Ok, ich kann das Problem jetzt umgehen. Ursache scheint ein zu früher Aufruf, noch bevor das Hauptmenü angezeigt wird, der Übersetzungfunktion zu sein.

[Ramkhamhaeng]

Gibt es schon irgendeine „Heartbeat“-Funktion bevor man ein Spiel geladen hat, d.h. sich noch im Hauptmenü befindet?

Hintergrund der Frage ist der Aufruf des Events OnWindowActivation beim Programmstart. An dieser Stelle kann man schon Zeichenfunktionen aufrufen. Dummerweise zeichnet sich das Hauptmenü dann aber darüber so dass man seine Elemente danach noch einmal nach vorne holen müsste. Ich finde nur keinen Weg/Trick um das zweite Zeichen anzustoßen.

Edit: Einen Timer kann man im Pythoncode nicht initialisieren, da dessen Instanz zerstört wird sobald man die von der DLL aufgerufene Funktion wieder verlässt.

[Ramkhamhaeng]

Habe das Problem jetzt über einen warteten Thread in der DLL gelöst. Damit habe ich jetzt drei aus Programmierer-Sicht interessante Features implementiert. Vielleicht ist auch was für BASE dabei
Ein Diff mit allen Änderungen kann ich bei Interesse posten.

1. Das Modverzeichnis kann sich an unterschiedlichen Orten befinden und es ist nicht ganz trivial per Python diesen Ort zu bestimmen,
da man in Civ4 nicht einfach das Python-Modul nach seinem Pfad fragen kann. Das liefert dann immer den Ordner in dem die Spiele-Exe ausgeführt wird (oder es war [Beyond the Swords]\Assets\Python . Jedenfalls nicht den Mod-Ordner)
Daher habe ich in die DLL eine Funktion eingebaut die den Pfad der geladenen CvGameCoreDLL.dll ermittelt. -> Daraus kann
dann der absolute Pfad der Mod berechnet werden

2. Die Python-Version von Civ4 ist ohne zlib-Support kompiliert worden so dass man keine komprimierten Zip-Archive entpacken kann.
Habe eine Funktion gebastelt, welche die Windows-Routinen zum Entpacken (innerhalb des Modverzeichnisses) nutzt.

3. Nun noch das Problem zum Zeichen innerhalb des Hauptmenüs. Dafür wurde die DLL um die Möglichkeit erweitert nach X Millisekunden eine Pythonfunktion zu triggern. Die kann ich im ersten OnWindowActivation-Event aufrufen, das Zeichnen des Hauptmenüs abwarten und dann aktiv werden.


P.S. Zusammen ergibt das einen Civ4-Internen Mod-Updater Zulan war zwar skeptisch ob der Sinnhaftigkeit, aber es war eine schöne Herausforderung

[rucivfan]

Schön das du eine Lösung gefunden hast. Ende es Jahres komme ich darauf zurück.

[Cybah]

Ein Modupdater klingt schon ziemlich sexy.

[Ramkhamhaeng]

Wenn man die „GOTO“-Funktion oder die „Baue Straße nach“-Funktion im Interface aufruft erscheint zwischen dem Einheitenfeld und dem Mauszeiger ja die Route über die Felder, welche die Einheiten nehmen wird.
Diese Route wird allerdings schon berechnet bevor die entsprechende MISSION_XXX angestoßen wird.

Hat jemand eine Idee, wie ich diese Route beeinflussen kann? Ich würde gerne ein paar Felder ausschließen, so dass die Route über andere Felder läuft.

[Kathy]

Ich habe ein ungewöhnliches Problem. Ich habe canMoveInfo modifiziert, so dass es für Seeeinheiten wie folgt aussieht:

	case DOMAIN_SEA:
		if (!pPlot->isWater() && !canMoveAllTerrain())
		{
			if (!pPlot->isFriendlyCity(*this, true) || !pPlot->isCoastalLand()) 
			{
				//Kathy beginn: Schiffe mit Amphibish-Beförderung können Flussufer benutzen
				if ( !this->isAmphib() || !pPlot->isRiver() )
				{
				//Kathy end: Schiffe mit Amphibish-Beförderung können Flussufer benutzen
					return false;
				}
			}
		}
		break;

Sinn des ganzen ist, dass ich damit "Flussschiffe" erstellen will, die sich entlang von Flüssen bewegen können. Das klappt soweit ganz gut, auch wenn es blöd aussieht, weil die Einheiten immer weit weg vom Fluss schwimmen. Aber ich fürchte, dafür gibt es keine Lösung.
Mein Problem jetzt ist aber ein anderes: Für Küstenfelder mit Fluss wird der Cursor immer rot angezeigt, und die Schiffe können nicht dahin bewegt werden. Sie können zwar darüber hinweg in den Fluss einfahren, aber das Feld selbst nicht betreten. Vermutlich blockiert da der Code für das entladen von Schiffen. Das schränkt aber die Möglichkeit meines Vorhabens etwas ein, schließlich sollen diese Schiffe natürlich auch Flussmündungen betreten können. Hat jemand eine Idee, wo ich das korrigieren könnte?

[Ramkhamhaeng]

Ich nehme an, wenn du eine Einheit auf dem Schiff hast würde der Cursor anzeigen, dass man das Feld betreten kann?
Da musst du wahrscheinlich die Stelle anschauen an welcher die Logik für die Anlandung von Truppen enthalten ist. (gleiche Funktion oder evtl. cannotMoveInto)

Zum Verschieben von Einheiten auf einem Feld habe ich schon mal was gesehen

[Kathy]

Ja, wenn ich das Schiff belade, wird der Cursor zum Anlanden angezeigt.

In "Canmoveinto" habe ich nichts gesehen, und "cannotMoveInto" ist Python, da sind so wichtige Dinge nicht drin, weil es standardmäßig deaktiviert ist. Ich schlafe einmal drüber und denke morgen nach.

[Kathy]

Ich muss mir vermutlich das hier einmal näher ansehen:

bool CvSelectionGroup::isAmphibPlot(const CvPlot* pPlot) const
{
	bool bFriendly = true;
	CvUnit* pUnit = getHeadUnit();
	if (NULL != pUnit)
	{
		bFriendly = pPlot->isFriendlyCity(*pUnit, true);
	}

	//return ((getDomainType() == DOMAIN_SEA) && pPlot->isCoastalLand() && !bFriendly && !canMoveAllTerrain());

	if (getDomainType() == DOMAIN_SEA)
	{
		if (pPlot->isCity() && !bFriendly && (pPlot->isCoastalLand() || pPlot->isWater() || canMoveAllTerrain()))
		{
			return true;
		}
		return (pPlot->isCoastalLand() && !bFriendly && !canMoveAllTerrain());
	}
	return false;
}
/************************************************************************************************/
/* BETTER_BTS_AI_MOD                       END                                                  */
/************************************************************************************************/

// Returns true if attempted an amphib landing...
bool CvSelectionGroup::groupAmphibMove(CvPlot* pPlot, int iFlags)
{
	CLLNode<IDInfo>* pUnitNode1;
	CvUnit* pLoopUnit1;
	bool bLanding = false;

	FAssert(getOwnerINLINE() != NO_PLAYER);

	if (groupDeclareWar(pPlot))
	{
		return true;
	}

	if (isAmphibPlot(pPlot))
	{
		if (stepDistance(getX(), getY(), pPlot->getX_INLINE(), pPlot->getY_INLINE()) == 1)
		{
			pUnitNode1 = headUnitNode();

			// BBAI TODO: Bombard with warships if invading

			while (pUnitNode1 != NULL)
			{
				pLoopUnit1 = ::getUnit(pUnitNode1->m_data);
				pUnitNode1 = nextUnitNode(pUnitNode1);

				if ((pLoopUnit1->getCargo() > 0) && (pLoopUnit1->domainCargo() == DOMAIN_LAND))
				{
					std::vector<CvUnit*> aCargoUnits;
					pLoopUnit1->getCargoUnits(aCargoUnits);
					std::vector<CvSelectionGroup*> aCargoGroups;
					for (uint i = 0; i < aCargoUnits.size(); ++i)
					{
						CvSelectionGroup* pGroup = aCargoUnits[i]->getGroup();
						if (std::find(aCargoGroups.begin(), aCargoGroups.end(), pGroup) == aCargoGroups.end())
						{
							aCargoGroups.push_back(aCargoUnits[i]->getGroup());
						}
					}

					for (uint i = 0; i < aCargoGroups.size(); ++i)
					{
						CvSelectionGroup* pGroup = aCargoGroups[i];
						if (pGroup->canAllMove())
						{
							FAssert(!pGroup->at(pPlot->getX_INLINE(), pPlot->getY_INLINE()));
							pGroup->pushMission(MISSION_MOVE_TO, pPlot->getX_INLINE(), pPlot->getY_INLINE(), (MOVE_IGNORE_DANGER | iFlags));
							bLanding = true;
						}
					}
				}
			}
		}
	}

	return bLanding;
}

[Ramkhamhaeng]

Interessant könnte CvGameCoreUtils::pathDestValid sein. Die hängt, glaube ich, nämlich eng mit der Generierung der angezeigten Route für Einheiten zusammen.
Änderungen an dieser Stelle beheben aber höchstens das Problem mit dem roten Cursor.

[rucivfan]

Vor zwei Jahren hätte ich sicher die Ursache nennen können, aber ich bin zur Zeit mit anderem stark beschäftigt. Ich kann nur sagen, dass mein aktuellster (Beta?) Base-Code anders erkennt, dass eine Anlandung erfolgt. Die Funktion fand ich so unpraktisch.