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.

[Kathy]

Ich frage mich, ob man den Technologieberater irgendwie anpassen kann, dass er nach unten mehr anzeigt. In meinem Mod ist er schon ziemlich unübersichtlich geworden, man erkennt die Verbindungswege gar nicht mehr. Hier mal ein Beispiel aus einem Zeitalter:


Es ist kaum möglich, das ganze Zeitalter auf einem Blick zu sehen, und das ist noch ein übersichtliches ZA. Im ersten und zweiten Weltkriegs sieht es noch viel schlimmer aus.
Bislang habe ich versucht, eine Ausbreitung nach unten zu vermeiden, weil man dann eben auch nach unten scrollen muss. Für mein Vorhaben, den ganzen Baum noch etwas anders neu zu ordnen, in der Hoffnung, so etwas wie eine sinnvolle Anordnung zu erzeugen, müsste ich den Baum eigentlich nach unten noch doppelt so breit machen. Dann würde ich aber vier Screens untereinander brauchen, um alles, was zeitlich zusammengehört, abzubilden. Gefällt mir auch nicht.
Meine Frage ist nun, ab man das Fenster so verändern könnte, dass er oben höher anfängt, unten tiefer aufhört und damit insgesamt vielleicht 4 Zeilen gewonnen werden können. Das rettet nicht alles, aber es wäre schon einmal etwas mehr.
Damit hängt allerdings die Frage zusammen: Wenn ich das so mache, und es auf meinem Bildschirm gut ist - wird es Probleme bei kleineren Bildschirmen machen? Oder kann man die Höhe an die Auflösung anpassen?

[xist10]

Also von dem Ashes of Erebus Mod habe ich (indirekt) gelernt, dass die Größe der Beraterfenster ganz blöd zu modden ist.

Ich könnte mir vorstellen, es würde schon helfen, wenn du deutlich weniger mit den ODER Vorraussetzungen arbeitest.
Eventuell könntest du sogar die ODER Vorraussetzungen ganz streichen ? (es sollte möglich sein, die UND Vorraussetzungen in 2 Reihen anzuzeigen).
Wenn die ganzen Pfeile wegfallen, sollte es etwas übersichtlicher werden.

[Kathy]

Oder-Verknüpfungen haben schon ihren Sinn, die mache ich nicht einfach für mehr Übersicht weg. Da gilt dann Inhalt wichtiger als Übersicht.
Vielleicht kann man einzelne aussortieren, aber das ändert nichts daran, dass die Technologien so, wie sie derzeit bei mir liegen, wir ein großer Haufen wirken. Das hat auch weniger mit den Pfeilen zu tun, als vielmehr, dass sie einfach irgendwie da hintereinander liegen und die ganze Ordnung.... eben keine Ordnung ist.
Ich habe das bemerkt, als ich in meiner aktuellen Version den 1. Weltkrieg sortiert habe - und hinterher war es genauso chaotisch wie vorher, nur etwas schmaler nach unten und etwas länger in die Breite.

Die Aussage, dass die Fenster ganz blöd zu modden sind, sehe ich jetzt mal als ein Signal, dass ich die Größe lassen sollte.

[Rob Anybody]

Ich glaube, das wäre eine geeignete Aufgabe für eine KI. Ohne nähere Beschreibung warum, würde ich ihr einfach sagen, das sie die Daten (Technologien) mit ihren Abhängigkeiten so sortieren soll, das es bei einer zweidimensionalen Abbildung möglichst wenig Überschneidungen bei den Abhängigkeiten gibt. Optional kann man dann noch den Raum einschränken (maximale Anzahl der Technologien untereinander, aber beliebig viele Lücken möglich und unbegrenzt Platz nach hinten) oder aber die Abhängigkeiten auf unnötige Verbindungen analysieren lassen

[Pie]

Wieso willst du überhaupt alles in einer Spalte nach unten haben? Du hast doch bestimmt keine Runden, die 100 Jahre brauchen? Dann mach doch ein Zeitalter breiter anstatt höher!
Und verknüpfe wirklich so, dass keine Linien unter einer Tech durchgehen müssen. Das ist möglich! Ist doch sch...egal, obs bei manchen Technologien nicht ganz so passt, das ist dann so. Aber dann wirkt es übersichtlicher. Und seitlich scrollen ist doch gewohnter auch noch nach unten scrollen zu müssen. (only my 5 cents)