Kleine Fragen zum Colonization-Modden

[Writing Bull]

Viele Grüße und ein großes Danke an die Macher beider Mods, haben mich die letzten 2 Wochen wie kaum was anderes an den Bildschirm gefesselt

Hört man gerne.

Ich wollte mal fragen ob jemand schonmal die Siegvariente "industrielle Revolution" aus TAC bzw. RaR gewonnen hat?
Was zählt da alles so zu bei dieser Wertung?

Wenn ich mich richtig erinnere, so ziemlich jeder Yield.
(Auch Freiheitsglocken, Kreuze, usw.)

Ja, das ist richtig. Kann ich bestätigen.

[Kermit87]

Hallo,
ich grüße Euch! Bin mal wieder zurück von meiner langen Colonization Abstinenz. Habe gleich mein altes Projekt mit dem variierenden Plot-Yield aufgegabelt. Die GameCoreDLL ist entsprechend der damals Vorschläge von Ramkhamhaeng editiert. Plot enthält nun ein Array in dem Inkre- oder Dekrementierungen für die Yield-Erträge abgelegt werden können die am Ende der Funktion: calculateNatureYield addiert werden.

Nun habe ich testweise an das bestehendes Event der ersten Stadtgründung einen Pyton-Callback angehangen. Der wird auch ausgeführt, aber bleibt in Python oder beim ansteuern der GameCoreDLL hängen.

CvRandomEventInterface.py – Neues Event:

def Test(argsList):
	# zugriff auf Map vorbereiten
	map = CyMap()
	# alle Plots duchgehen
	for iX in range(map.getGridWidth()):
		for iY in range(map.getGridHeight()):
			# alle Yield-Typen durchgehen
			for eYield in range(YieldTypes.NUM_YIELD_TYPES):
				# zugriff auf Plot vorbereiten
				pPlot = gc.getMap().plot(iX, iY)
				# nur ändern wenn Plot dieses Yield bereits besitzt
				if pPlot.getYield(eYield) > 0:
					# zufällige Änderung um: -1, 0, +1
					pPlot.setYieldChange(eYield, getSorenRandNum(3, "was auch immer angegeben wird?")-1)

Neue Funktion in der GameCoreDLL: setYieldChange
sehen geübte Augen hier vielleicht schon einen Fehler?

[Ramkhamhaeng]

Hallo Kermit,

ich sehe keinen Fehler. Wenn du die Python-Fehlermeldungen aktiviert hast, aber keine Meldung erschenit, müsste der Fehler im DLL-Teil liegen.
Falls du die DLL in der Debug-Version komplierst und innerhalb von Visual Studio das Debugging startest, kannst du in 'setYieldChange' einen Breakpoint setzen. Dann kannst du (Taste F10) Zeile für Zeile den Ablauf beobachten und so vllt. dem Fehler auf die Schliche kommen.

[raystuttgart]

@Kermit:

Solche riesigen Loops solltest du besser direkt in die DLL packen.
(Das könntest du doch da genauso problemlos als eigene Methode kapseln, die nach der grundlegenden Kartengenerierung ausgelöst oder aus dem Mapskript aufgerufen wird.)

Du durchläufst da die gesamte Karte und bei jedem Plot nochmal die gesamte Liste der Yields.

[Ramkhamhaeng]

@Ray: Ich glaube das wird nur einmalig bei der Generierung der Karte durchlaufen. Das ist nicht zeitkritisch.

[raystuttgart]

@Ray: Ich glaube das wird nur einmalig bei der Generierung der Karte durchlaufen. Das ist nicht zeitkritisch.

Wirklich zeitkritisch ist es wahrscheinlich nicht.
Ob die Kartengenerierung einige Sekunden länger dauert oder nicht, ist den meisten wahrscheinlich egal.

Kommt halt auch auf die Kartengröße und die Anzahl der Yields an.
(In RaR würde sowas aufgrund der viel größeren Karten und viel größeren Anzahl von Yields midestens 10mal eher sogar 20mal länger dauern, als in TAC.)

Liese sich aber trotzdem schön als eigene Methode in der DLL kapseln.
(Und wäre da garantiert viel schneller.)

[Ramkhamhaeng]

Meiner Meinung nach sind deine Kritik komplett übertrieben und letztlich einfach nur demotivierend :-( Zumal es hier nur um eine Testroutine geht, um die neue Funktionalität zu testen.

Zum Thema:
Kermit, vielleicht liegt der Fehler darin, dass du für alle Yields den Ertrag änderst. Wirkt die Ertragsänderung dann nur bei den Waren, die auf dem Feld ursprünglich vor kamen?! Ich könnte mir vorstellen, dass es Probleme gibt, wenn ein Feld bei zu vielen Feldern Ertrag abwirft. Negative Erträge sollten auch vermieden werden (wird wahrscheinlich eh schon abgefangen).

Am besten ersetzt zu zum Testen die innerste Schleife durch ein Variieren der Nahrung.

[raystuttgart]

Meiner Meinung nach sind deine Kritik komplett übertrieben und letztlich einfach nur demotivierend :-(

Ich hab hier keine Kritik geübt, sondern einen Vorschlag zur Umsetzung gemacht.
Was da jetzt komplett übertrieben oder demotivierend war, versteh ich nicht.

Edit:
Im Python Code konnte ich übrigens auch keinen Fehler entdecken.

[Ramkhamhaeng]

Das ist jetzt alles meine sehr persönliche Sicht der Dinge, aber nehmen wir mal den Satz

Ob die Kartengenerierung einige Sekunden länger dauert oder nicht, ist den meisten wahrscheinlich egal.

Gerade das ist jedem Modder nicht egal!
Der obige Code verschwendet aber überhaupt keine Sekunden. Aber allein die Andeutung, dass es so wäre, kratzt an der virtuellen Programmierer-Ehre

Dazu kommt dann jedes mal als erstes der Hinweis, es direkt in die DLL zu packen. Aber das ist sehr aufwendig, wenn man den Code des SDK kaum kennt! Man braucht Stunden um sich grob einzulesen und Tage, um die Details zu verinnerlichen. Ja klar, danach ist es einfacher in der DLL zu modden, aber für den "normalen" Modder liest es sich doch so: „Tja mein Lieber, ich kriege es in 5 Minuten hin, aber du brauchst für diese simple Aufgabe Stunden“. Außerdem bringt das den Fragesteller bei seinem aktuellen Problem kaum weiter.
(Mein Hinweis zur Benutzung des Debuggers ging in eine ähnliche Richtung )

tl;dr
Ich interpretiere in deine Beiträge vllt. zu viel rein und sie sind daher ein rotes Tuch. Wäre ich der Fragesteller, würden sie mich eher abschrecken mich weiter mit dem Thema zu beschäftigen.

[raystuttgart]

„Tja mein Lieber, ich kriege es in 5 Minuten hin, aber du brauchst für diese simple Aufgabe Stunden“.

...

Ich interpretiere in deine Beiträge vllt. zu viel rein und sie sind daher ein rotes Tuch.

Scheint tatsächlich so zu sein, dass du meine Beiträge etwas seltsam auffasst.

Aber du hast hiermit definitiv recht:
Diese Diskussion bringt Kermit bei der Lösung seines Problems garantiert nicht weiter.

[Kermit87]

Solche riesigen Loops solltest du besser direkt in die DLL packen.
(Das könntest du doch da genauso problemlos als eigene Methode kapseln, die nach der grundlegenden Kartengenerierung ausgelöst oder aus dem Mapskript aufgerufen wird.)

Du durchläufst da die gesamte Karte und bei jedem Plot nochmal die gesamte Liste der Yields.
...
Liese sich aber trotzdem schön als eigene Methode in der DLL kapseln.
(Und wäre da garantiert viel schneller.)

Ja schon, aber es sollte jedoch so sein das in der GameCoreDLL lediglich eine Schnittstelle eingebaut wird worauf von außen zugegriffen werden kann um benutzerdefinierte Scripte einzuhängen. Wenn das starr in der GameCoreDLL verankert wird kann ja keiner mehr dran rumschrauben ohne die GameCoreDLL neu zu kompilieren.

Zum Thema:
Kermit, vielleicht liegt der Fehler darin, dass du für alle Yields den Ertrag änderst. Wirkt die Ertragsänderung dann nur bei den Waren, die auf dem Feld ursprünglich vor kamen?! Ich könnte mir vorstellen, dass es Probleme gibt, wenn ein Feld bei zu vielen Feldern Ertrag abwirft. Negative Erträge sollten auch vermieden werden (wird wahrscheinlich eh schon abgefangen).

Eine Änderung sollte laut des oben zu sehenden Test-Events nur dann vorgenommen werden wenn über die abgefragte Funktion: getYield aus dem Array: m_aiYield etwas zurückgeliefert wird was größer ist als 0. Also nur dann wen diese Ressource auf diesem Plot schon vorhanden ist. Anschließen wird eine zufällige Änderung von: -1 bis +1 über die neu hinzugefügte Funktion: setYieldChange an das neue Array: m_aiYieldChange übergeben wird. Die in m_aiYieldChange enthaltenen Yield-Änderungen werden am Ende der Funktion: calculateNatureYield hinzuaddiert. Solte sich dort etwas im negativen Bereich befinden wirde es über: max eh herausgefiltert und 0 zurückgegeben.

Am besten ersetzt zu zum Testen die innerste Schleife durch ein Variieren der Nahrung.

Ich werde mal weiter herumprobieren. Sehe allerdings schon langsam Phantom-Fehler, was immer dann auftritt wenn man zu lange auf der Stelle tritt.

Wäre ich der Fragesteller, würden sie mich eher abschrecken mich weiter mit dem Thema zu beschäftigen.

Nein, aber eine Priese Erfolg wehre mal ganz motivierend für den Mut zu weiteren eingriffen in die Spielmechanik!

Frage: Ist es die Annahme korrekt das in der CyPlot die Übermittlung von befehlen von Python Scripten an die CvPlot stattfindet?

[raystuttgart]

Frage: Ist es die Annahme korrekt das in der CyPlot die Übermittlung von befehlen von Python Scripten an die CvPlot stattfindet?

Ja, in CyPlot werden die Methoden programmiert, die auf die Methoden CvPlot durchgreifen (in denen die eigentliche Logik steckt).
Außerdem gibt es noch CyPlotInteface, was du dir mal ansehen solltest.

Machst du das nicht (oder falsch), kann dein Python Code die Methode in der DLL nicht aufrufen.
(Für sowas gibt es aber im Code Beispiele ohne Ende.)

Wenn das nicht klappt, sollte dir aber eine Python-Exception geworfen werden.
(Vorausgesetzt natürlich du hast diese aktiviert.)

[Ramkhamhaeng]

Kannst etwas genauer den Fehler beschreiben? Hängt das Spiel? Am besten hängst du mal deine modifizierte CvPlot.cpp (da müsste alles relevante drin sein?!) an, damit wir den kompletten Code sehen.

Scheint tatsächlich so zu sein, dass du meine Beiträge etwas seltsam auffasst.

Kann sein und daher werde ich das Thema jetzt auch wieder ruhen lassen.

[Kermit87]

So habe es jetzt hinbekommen!
Es gibt der Karte einen aufregend neuen Charakter! Muss natürlich alles noch in Python ausbalanciert werden, aber die Schnittstelle steht. Ich hab mir dann auch mal die Python-Exception angeschaltet. Er hat mir dann auch gleich so die ein oder andere Fehlermeldung ausgespuckt die ich dann korrigieren konnte. Der Python-Code sah zwar oberflächlich korrekt aus aber es gab doch die ein oder andere Ungereimtheiten mit der weitergab der Parameter. Außerdem musste noch etwas in: CyPlotInterface2.cpp eingetragen werden.

Am besten hängst du mal deine modifizierte CvPlot.cpp (da müsste alles relevante drin sein?!) an, damit wir den kompletten Code sehen.

Generell wäre es sinnvoll wenn jemand mit mehr Erfahrung nochmal drüber schaut wenn ich fertig gebastelt habe. Dann steht der Code zum implementieren zur Verfügung! Vielleicht mochte ja auch eine große Mod dieses Future adaptieren?

[raystuttgart]

Außerdem musste noch etwas in: CyPlotInterface2.cpp eingetragen werden.

Das sind halt so die Kleinigkeiten, über die man am Anfang stolpert.
Glückwunsch, das es jetzt funktioniert.