Der Pythonthread

[Ramkhamhaeng]

(Ohne Civ zur Hand): Wenn es richtig crasht ist oft ein Fehler bei der Generierung von Overlay-Texten schuld. Könnte es daran liegen, dass unerwarteterweise .getDefaultUnitIndex() -1 zurück gibt?

[Kathy]

Bei den Asserts tauchte tatsächlich so etwas ähnliches auf, ich meine "eUnit != -1" oder "eUnitInfo." In welchen Fällen kann das passieren? Ich würde vermuten, dass ein einer UnitClass unter "DefaultUnit" ein ungültiger Eintrag steht? Oder kann das noch andere Ursachen haben?

Edit: Da gerade noch mein Debugging läuft, kann ich es nicht reproduzieren und den genaue Asserts anzeigen.
Ich weiß nicht, warum das immer zwei Stunden braucht, bis endlich einmal was passiert.

[Kathy]

Das Debugging verweist auf diesen Codeteil:

	###Barbarian Uprising Beginn
			if ( gc.getTechInfo(i).getFirstBarbarianUnitClass() != UnitClassTypes.NO_UNITCLASS ):
				szBarbarianUnitUnitButton = "BarbarianUnit" + str(i)
				szBarbarianUnitX = "BarbarianUnitX" + str(i)
				screen.addDDSGFCAt( szBarbarianUnitUnitButton, szTechRecord, gc.getUnitInfo(gc.getUnitClassInfo(gc.getTechInfo(i).getFirstBarbarianUnitClass()).getDefaultUnitIndex()).getButton(), iX + fX, iY + Y_ROW, TEXTURE_SIZE, TEXTURE_SIZE, WidgetTypes.WIDGET_HELP_BARBARIAN_UPRISING, gc.getUnitClassInfo(gc.getTechInfo(i).getFirstBarbarianUnitClass()).getDefaultUnitIndex(), i, False )
				screen.addDDSGFCAt( szBarbarianUnitX, szTechRecord, ArtFileMgr.getInterfaceArtInfo("INTERFACE_BUTTONS_BARBARY_X").getPath(), iX + fX, iY + Y_ROW, TEXTURE_SIZE, TEXTURE_SIZE, WidgetTypes.WIDGET_HELP_BARBARIAN_UPRISING, i, -1, False )
				fX += X_INCREMENT
			j = 0
			k = 0
	###Barbarian Uprising End

Bzw. genaugenommen will er "WIDGET_HELP_BARBARIAN_UPRISING" erstellen.
m_iData1 ist 27,
m_iData2 ist -1,

eTech ist komischerweise auch -1, eBarbarianUnit (taucht im SDK auf) dito.
Beziehungsweise unter "CvUnitClassInfo& CvGlobals::getUnitClassInfo(UnitClassTypes eUnitClassNum)" ist "eUnitClassNum" auf einmal 7929953. So viele Einheiten habe ich beim besten Willen nicht.

Mir fehlt nur irgendwie ein Ansatz, diese Informationen jetzt in die Ursache des Problems zu übersetzen.

Da die orangen Codeteile neu sind, ist es naheliegend, dass ich in einem von den beiden einen Fehler drin habe - die anderen Codeteile haben bislang keinen solchen Ärger verursacht. Ich habe diese Codeteile von den veraltenden Bonusgütern kopiert und angepasst.

Edit: Am Ende der Zeile steht ", WidgetTypes.WIDGET_HELP_BARBARIAN_UPRISING, i, -1, False ", in der Zeile darüber nur "WidgetTypes.WIDGET_HELP_BARBARIAN_UPRISING, gc.getUnitClassInfo(gc.getTechInfo(i).getFirstBarbarianUnitClass()).getDefaultUnitIndex(), i, False )"
Könnte das die Ursache sein?

[Pie]

Ja, fix. Das ist kein BTS Standard. WIDGET_HELP_BARBARIAN_UPRISING gibt es nicht. Das musst du im SDK anlegen.
Und gc.getTechInfo(i).getFirstBarbarianUnitClass() gibts ebenfalls nicht. Nur gc.getTechInfo(i).getFirstFreeUnitClass () .

Es sei denn, du hast diese extra-Dinge im SDK schon eingebaut.

[Kathy]

Tatsächlich habe ich das schon eingebaut, sonst würde das Overlay in der Anzeige nicht funktioniert haben.

Es ging lediglich um die Endungen der Zeile, die unterschiedlich waren.
Die obere Zeile war die alte, die immer schon funktioniert hat. Die untere war die neue, kopiert von den Bonusgütern, die aber am Ende die Unterschiede habe.
, i, -1, False
statt
gc.getUnitClassInfo(gc.getTechInfo(i).getFirstBarbarianUnitClass()).getDefaultUnitIndex(), i, False )

Diese Werte (ich habe das jetzt geändert) wurden eben falsch ans SDK übergeben. i statt dem Unitindex und -1 statt i. Diese falschen Daten sorgten für einen Absturz.
Nach der Änderung funktioniert es nun wieder glatt.

[Kathy]

Es ist tatsächlich ein mir bekanntes Problem, wenn ich hier poste, dass ich immer wieder auch Dinge im SDK schon definiert habe, die funktionieren und die ich nicht separat kennzeichne - manchmal erinnere ich mich nicht daran, dass es von mir ist. Ich bitte daher um Entschuldigung, dass das immer wieder Verwirrung stiftet, wenn ich hier etwas vorstelle.
Meine Frage nach Problemen bezieht sich dann auf die Struktur dessen, was ich geschrieben habe - aber auch das ist natürlich schwer nachzuvollziehen, wenn jemand die Struktur einer von mir definierten Funktion nicht kennt.

[xist10]

Ich denke, hier ist durchaus der beste Ort.

Ich will bezüglich Balancing in einer MP Karte bei der Generation jedem Spieler eine "Region" zuweisen.

Aktuell mache ich das, indem ich nach erstellen der Karte und Startpositionen durch die Karte iteriere und für jedes Feld den nächsten Startplatz (nach Laufweg) suche - und das Feld dann diesem Startplatz zuordne.

teamTiles =[[]]
activeTeams = []

# This function orders all tiles to the next team in walking distance
def setTeamTiles():
	global teamTiles, activeTeams,
	gc = CyGlobalContext()
	map = CyMap()

	# find all teams and increases the teamTiles array.
	for i in range(gc.getMAX_CIV_PLAYERS()):
		pPlayer = gc.getPlayer(i)
		if pPlayer.isEverAlive():
			iTeam = pPlayer.getTeam()
			if iTeam not in activeTeams:
				activeTeams.append(iTeam)
				teamTiles.append([])
	
	# iterates thorugh the 
	for plotIndex in range(map.numPlots()):
		pPlot = map.plotByIndex(plotIndex)
		shortestDistance = (999, 99999)
		for i in range(gc.getMAX_CIV_PLAYERS()):
			pPlayer = gc.getPlayer(i)
			if not pPlayer.isEverAlive(): continue
			pStart = pPlayer.getStartingPlot()
			distance = 99999
			if(pPlot.isWater()):
				distance = plotDistance(pPlot.getX(), pPlot.getY(), pStart.getX(), pStart.getY())
			else:
				distance = map.calculatePathDistance(pPlot, pStart)
			if (distance < shortestDistance[1] and distance >=0):
				shortestDistance = (pPlayer.getTeam(), distance)
		try:
			teamIndex = activeTeams.index(shortestDistance[0])
		except:
			continue
		else:
			teamTiles[teamIndex].append(pPlot)

Das Problem ist, das map.calculatePathDistance() scheinbar nicht richtig funktioniert, da ich so komisch geformte Regionen erhalte. - Da wird hin und wieder ein isoliertes Feld einer Region zugewiesen.
Verwende ich calculatePathDistance() korrekt oder habe ich etwas anderes übersehen ?

Wenn ich immer plotDistance() verwende, scheint alles zu funktionieren, aber diese Methode hat Probleme, wenn das ändere Meeresufer räumlich relativ nahe ist.

Inseln sollten mit distance >=0 abgefangen werden.

[Kathy]

Was sind das für einzelne Teile, die isoliert sind? Inseln oder Teile der Landmasse? Bei Inseln hat er vermutlich die Schwierigkeit, dass eine Einheit dahin nicht ohne Unterbrechung laufen kann, ergo der Pfad unendlich lang wird.
Wenn es auf der selben Landmasse ist, scheint mir das komisch zu sein.

[xist10]

Hier zum Beispiel.
Ich habe später eine Funktion, die die Gebiete über Features markiert (Gelände wäre wohl besser, wenn ich das so sehen).
3 Spieler auf der Karte, Eis, Dschungel und Oase.

Und noch 2 bessere Beispiele mit Terrain change. - Das überschreibt auch Wasserfelder.



Diesmal auf flache Karte, damit ich so ein besseres Bild machen kann.



Wenn ich in allen Fällen plotDistance verwendet, sieht das so aus - wie ich es gerne hätte.
Das Problem mit plotDistance ist aber halt dieses:



Wenn es hier so eine Blockade gibt, interessiert dies plotDistance nicht.

[Kathy]

Tja... Features und besonder Gebirge beeinflussen zwar auch die Pfadlänge, aber das erklärt nicht, wieso diese Ausreißer da sind.
Man könnte zum Spaß auf jeden Start Plot einen Krieger setzen und mal schauen, welche Pfadlänge das Spiel angibt, wenn man von dort zu so einem fragwürdigen Plot gehen will. Also von jedem Startplot aus. Und dann vergleichen, ob der mit der kürzesten Entfernung auch wirklich derjenige ist, dem der Code dieses Ziel zuweist.
Ganz falsch scheint der Code ja nicht zu sein, einige Gegenden werden zusammenhängend zugewiesen.