SDK-Experimente

[Flunky]

Also irgendwas hab ich grad grundlegend falsch gemacht: die Runden dauern länger als vorher^^

[Flunky]

Pie, Thorgal und wer sonst noch nen Plan davon hat: Könnt ihr euch irgendeine Abbildung der Python-Events auf xml-Dateien vorstellen?

[Pie]

Häh? Du meinst, du willst komplett weg von den Event-Pythonfunktionen von Events, dessen Überprüfungen und Auswirkungen über die normale EventInfo-XML nicht einstellbar sind?

[Flunky]

Ich überleg nur, obs sinnvoll möglich wär. Am besten über ne Erweiterung der Event.xml.

[Pie]

Als modmod kannst du machen was du willst

Ich glaube, das Python selbst gar nicht so arg langsam ist. Nur die CallBackDefines sind extrem langsam, wenn die aktiviert sind. Und auch erst da greift der K-Mod. Denn ohne PythonCallbacks, aber mit K-Mod ist K-Mod viel langsamer als PAE. Ein Mod mit PythonCallbacks is extrem langsam, was dann durch K-Mod verbessert wird.

Die Chance bei den Events werden ja sowieso über SDK gewürfelt. Erst wenn so ein Event aktiv ist, greift es auf die Infos und auch auf die Pythonfunktionen, wenn da welche existieren. Wenn dieses Event oder Quest erfüllt ist, wird das ganze Event ja nicht wieder beachtet.

ZB: Typisch für so ein BTS-Python-Event (eigentlich Quest) ist der Heilige Berg. Irgendwie isses schwierig, per XML Gebäude zu definieren, die er absuchen muss, ob die Quest weitergeht. Dann noch die Gewichtung der Gebäude und die gesuchte Anzahl! Also wie gesagt, da ist mit Python viel mehr zu schaffen. Und andersrum: je weniger XML-Einträge überprüft werden müssen, desto schneller auch SDK.

Ich glaub, wegen den paar pythonevents ist es nicht sonderlich wirkungsvoll.

[Flunky]

Alles klar, dann lass ich die wie gehabt. Ich dachte, da wären die Trigger und alles auch in Python geschrieben.

Was ist der K-Mod? PythonCallback heißt, wir geben ne Berechnung an die dll ab und warten auf Rückmeldung?

[alpha civ]

PythonCallback heißt, wir geben ne Berechnung an die dll ab und warten auf Rückmeldung?

Nein. Es wird die Python-Funktion innerhalb der DLL aufgerufen.

Der Ablauf ist i.a. so:

C++ -Objekte, die der Python-Funktion übergeben werden sollen, müssen vorher in Python-Objekte konvertiert werden.
Diese Objekte werden dann der Funktion übergeben.
Das Ergebnis dieser Funktion (sofern vorhanden), ist ein Python-Objekt, welches in in C++ -Objekt konvertiert werden muss.

[Flunky]

Neues von Firaxis. Heute: Python. Wir sollten lieber sichergehen, dass playerX auch wirklich nicht null ist.

if playerX and playerX and unitX and playerY:

Gemeint war wohl:

if playerX and playerYand unitX and unitY:

[Flunky]

Nein. Es wird die Python-Funktion innerhalb der DLL aufgerufen.

Der Ablauf ist i.a. so:

C++ -Objekte, die der Python-Funktion übergeben werden sollen, müssen vorher in Python-Objekte konvertiert werden.
Diese Objekte werden dann der Funktion übergeben.
Das Ergebnis dieser Funktion (sofern vorhanden), ist ein Python-Objekt, welches in in C++ -Objekt konvertiert werden muss.

Warum sollte ich das tun? Wenn ich doch eh schon an der dll rumschraube, kann ich da doch alles drin implementieren. Und was ich davon zusätzlich im Python brauch halt sichtbar machen.

[alpha civ]

Firaxis:

Warum sollte ich das tun? Wenn ich doch eh schon an der dll rumschraube, kann ich da doch alles drin implementieren. Und was ich davon zusätzlich im Python brauch halt sichtbar machen.

Python-Code ist einfacher, kürzer und sauberer als C++ -Code. Und Python-Code muss man bei Änderungen nicht neu kompilieren, was schon mal ein Vorteil ist.
Sofern man Python keine laufzeitintensiven Dinge anstellt ist Python vorzuziehen.
Bevor du was in die DLL verlegst, solltest du überlegen, ob du wirklich eine spürbare Verbesserung erzielst.

[Flunky]

Sauberer? Ich mag ja Typsicherheit^^

[alpha civ]

Sauberer? Ich mag ja Typsicherheit^^

Typsicherheit ist auch gut. Ist nur immer die Frage, wie die Sprache das statische Typsystem einführt. Bei Java hat man nur immer das Gefühl, dass das Typsystem nur für den Kompiler gut ist.
In C++ geht es noch, vorallem mit dem C++ 11 -Standard (auto).
Dennoch, beide Sprachen (C++ und Java) haben Mist bezüglich generischen Containern gemacht. (Aber das gehört nicht hierher...)


Was willst du eigentlich in die DLL verschieben? Die ganzen Callbacks? (Nicht den EventManager, oder?)
Die Callbacks sind da wirklich Kandidaten fürs DLL.

[Ramkhamhaeng]

Viele Pythoncalls sind auch extra für die Mod-Erstellung eingebaut worden. Es war ja ein Riesenvorteil, wenn man sich nur mit XML+Python auskennen musste.

[Flunky]

Im Moment schieb ich ein bissl Eventmanagerzeug. Sowas wie Versorgung ins XML integrieren, Flucht als reguläres Kampfergebnis...

KI wär auch noch so ne Sache, wobei da erstmal ne bessere KI rein sollte, bevor PAE-spezifische Sachen drankommen.

Ich hab mal den aktuellen Stand der Dinge hochgeladen. Da ist relativ viel mit reingepackt, weil ich grad nemmer weiß, an welchen xml- und Pythondateien ich nu wirklich was geändert hab. Vorgehen ist ja bekannt, PAE-Ordner sichern und dann einfach in Assets schmeißen.

[alpha civ]

Viele Pythoncalls sind auch extra für die Mod-Erstellung eingebaut worden. Es war ja ein Riesenvorteil, wenn man sich nur mit XML+Python auskennen musste.

Es wäre nur auch gut gewesen, wenn man wirklich Python beherrschen würde. Z.B. range statt xrange in for-Schleifen zu verwenden macht den Code nur unnötig langsamer, weil bei range erst Listen erzeugt werden, bei xrange hingegen nicht. (Was aber auch keinen Unterschied macht, wenn der Zahlenbereich klein ist.)