[BLOG]Metin2Client Python 3

Wie bekannt sein dürfte werden die Python Scripts aus dem M2 Client mittels CPython im Client Source verarbeitet. CPython ist open-source auf github verfügbar, was das ganze sehr freundlich gestaltet das Update an sich zu machen.

Ich habe mich dazu entschieden mit CPython 3.10 zu arbeiten, da die Version 3.11 noch ein paar Einschränkungen hatte (als ich mit dem Projekt gestartet habe) und version 3.12 war noch kein stable release.

Schritt 1 war es also das repo zu klonen und die entsprechenden Schritte aus den Docs durchzuführen.

Bitte melden Sie sich an, um diesen Link zu sehen.

Die Vorbereitung zum Kompilieren der entsprechenden libs für den Client sind einfach. Das repo gibt ein batch Script für Windows Hosts, welches alles für einen erledigt.

Alle nötigen Infos sind auch in einer Bitte melden Sie sich an, um diesen Link zu sehen. zu finden, dieses file war mein bester Freund um die Solution zum laufen zu bekommen.

Um die passenden Libraries für den M2 Client zu kompilieren habe ich jeweils im Debug und Release Mode für Win32 Konfiguration folgende Projekte der Solution kompiliert:

- python

- python3dll

Die daraus resultierenden Libraries sind dann im Ordner PCBuild\win32 zu finden.

Für den Client an sich, nicht die Executable, wird die Python310.dll benötigt.

Als Include im Source (Extern\Python3\libs) die python3.lib, python310.lib und python311.lib. Wenn man Funktionen aus der CPython library debugen will, dann auch die entsprechenden *_d.lib Libraries.

Warum die python311.lib benötigt wird ist mir nicht ganz klar, diese ist jedoch im repo unter "externals\pythonx86\tools\libs" zu finden.

Kommen wir generell zum Include im Metin2 Source. In dem EXTERN Ordner, wie er bei den meisten von euch wahrscheinlich auch heißt, habe ich einfach einen neuen Unterordner "Python3" erstellt. Darin sind alle nötigen C/C++ Header und die entsprechenden libraries enthalten. Den Ordner, so wie ich ihn habe, lade ich hier als Anhang hoch.

Der Python3\libs Ordner muss noch in den Einstellungen von dem UserInterface Projekt mit in die Configs(Debug/Distribute*/Release*) aufgenommen werden:

- UserInterface -> Linker -> Alle Optionen -> Zusätzliche Bibliotheksverzeichnisse -> $(ProjectDir)../../Extern\Python3\libs

* Welche Konfiguration ihr benutzt ist hier entscheidend

Nun konnte ich auch anfangen richtigen Code zu schreiben und den M2 Client Source anpassen. Erster Schritt war es ein neues Präprozesser Symbol in der locale_inc.h zu definieren

Alle meine Änderungen habe ich immer über das Symbol bedingt, sodass ich auch ein Fallback auf Python2 jederzeit möglich ist.

Erste Aufgabe für mich war es die Initalisierungsfunktionen für die Python Module wie app, player, item usw. zu korrigieren. Mit dem Upgrade von Python2.X auf Python3 hat sich da grundsätzlich etwas geändert.

Die Funktionen zum Initialisieren der Extension Modules müssen 1. vor dem Initialisieren des eigentlichen Python Interpreters ausgerufen werden und 2. auch anders als Modul registriert werden.

Als Einstiegspunkt dafür nehmen wir den Kontruktor der CPythonLauncher Klasse -> ScriptLib\PythonLauncher.cpp -> CPythonLauncher::CPythonLauncher()

Bevor Py_Initialize(); aufgerufen wird müssen alle Module initialisiert werden. Die Liste der benötigten Module ist in UserInterface.cpp zu finden:

bool RunMainScript(CPythonLauncher& pyLauncher, const char* lpCmdLine)

Hierbei sind alle Funktionen mit folgendem Schema zu berücksichtigen:

initpack();

initdbg();

initime();

initgrp();

initgrpImage();

initgrpText();

Ich bin jeweils so vorgegangen, dass ich mir zu jeder der Funktionen die Deklaration angesehen habe, das war meistens in den StdAfx.h files von den entspechenden Projekten, und dort erstmal die Deklaration verändert habe. Beispiel aus der StdAfx.h aus UserInterface

Dieses Vorgehen habe ich für alle Funktionsaufrufe aus der o.g. Funktion RunMainScript angewandt.

Hierbei ist unbedingt darauf zu achten, dass die Init Funktionen zu 100% nach dem Schema benannt werden:

PyMODINITFUNC PyInit_<ModuleName>(void)

Die Dokumentation weißt dort explizit drauf hin.

Nun müssen noch die Funktionen an sich verändert werden.

Die jeweiligen Implementierungen müssen angepasst werden, z.B. wie hier

Nun kommt der erste etwas komplizierte Teil. jede der Init Funktionen muss zwangsweise ein PyObject zurückgeben, dieses wird in der Funktion selbst erstellt. Dazu wurde in der alten Python Version die Funktion Py_InitModule() benutzt. Diese Funktion ist mittlerweile aber nicht mehr verfügbar. Es muss nun wie folgt vorgegangen werden:

Wir erstellen ein struct PyModuleDef mit dem Namen des Moduls. Die Parameter des structs sind als Kommentar im Code beschrieben. Mit diesem struct wird die PyModule_Create Funktion aufgerufen und wir bekommen ein PyObject zurück.

Nun ist es wichtig zu unterscheiden ob mit diesem PyObject (Module) noch etwas passiert, also ob noch Konstanten zugewiesen werden wie z.B. in dem app Module

Wenn dies der Fall ist, dann dürfen wir das PyObject erst ganz am Ende der Funktion zurückgeben. Wenn mit dem Module, also dem Object, nichts mehr passiert, dann könne wir direkt ein return programmieren wie in diesem Beispiel.

Nachdem ich alle vorhandenen Init Funktionen umgeschrieben habe, habe ich diese im Konstruktur des PythonLaunchers augerufen und die Module entsprechend registriert.

Gleichzeitig musste ich die "alten" Funktionsaufrufe ungültig machen, bzw. durch das Preprocessor Symbol ausschließen

Direkt in dem selben Source File musste ich feststellen, dass sich der Python Modulimport für "__builtin__" verändert hat. Dieses Modul ist nun mit "builtins" zu importieren.

Zusätzlich muss direkt am Anfang der UserInterface.cpp noch auf die neue Python lib verwiesen werden. Auch hier kann wieder unterschieden werden zwischen Debug und nicht Debug, das habe ich mir aber geschenkt da ich keinen Sinn darin sehe die CPython Funktionen aus der Lib zu debuggen.

So richtig trial & error war es heruaszufinden welcher der bytecode libs nun wirklich benötigt werden und welche nicht. Ich bin mit dieser Anpassung in UserInterface bis jetzt ganz gut klargekommen.

Generell müssen sämtliche Includes von Python2 Header Files durch das preprocessor symbol bedingt werden. Ich hier bin ich mir noch nicht zu 100% sicher ob ich etwas Wichtiges ausgelassen habe, so weit konnte ich leider noch nicht testen.

Das erste Include befindet sich in scriptLib/PythonLauncher.cpp sowie in dem entspechenden Header File

Ein Include musste tatsächlich ausgebaut werden, hier habe ich kein Replacement zu gefunden bzw. keine wirkliche verwendung im Quellcode

Ein weiteres Problem, welches ich irgendwie auflösen musste, war das Update von PyString_* zu PyUnicode_*, neue Funktionen/getter-setter von PyFrameObjects sowie Update von PyInt_* zu PyLong_*. Diese Themen gab es glücklicherweise nicht allzu oft, den ganzen Kack aufzulösen hat ewig gedauert. Ich komprimiere hier mal als Code-Ausschnitte was ich alles geändert habe.

Die erste Frage die es zu beantworten gilt: Was ist Python bytecode und wofür brauche ich das? -> Bitte melden Sie sich an, um diesen Link zu sehen.

Nachdem wir das geklärt haben ist die Frage, wie bekomme ich Python bytecode? Und welche Script Files will ich in bytecode kompilieren?

Ich habe mir dazu aus dem CPython 3.10 repo im Ordner Lib die entsprechenden Python Scripts raus gesucht, welche bereits in meinem Lib ordner als alter bytecode vorhanden waren.

Den alten bytecode bitte als Backup speichern!

Einige Module/Scripts wurden umbenannt oder verschoben/verschmolzen. Wenn ihr etwas nicht findet, dann ist Google da der beste Freund.

Alle diese Basis Scripts habe ich mir dann in ein separates Verzeichnis kopiert und mit dem Python CLI allesamt in bytecode kompiliert. Siehe hierfür die Bitte melden Sie sich an, um diesen Link zu sehen.

Mit dem daraus resultierenden bytecode ist der Client erstmal zufrieden. Wie es später aussieht, wenn ich auch die Python Scripts des Clients konvertiert habe, ist eine ganz andere Frage.

Jedes "Kapitel" wird hier dann aber aktualisiert sobald ich einen neueren Stand habe.