Source Code Einführung/Doku

Guron · 11/18/2020, 16:19

Hallo Leute,
ich interessiere mich sehr dafür am Source Code der Fliege Files bspw. zu arbeiten. Gibt es hierzu eine Art Dokumentation oder jemanden der da bock hat zusammen sich da was anzulernen? Oder gibt es hier auch jemanden der mich da einführen und mir helfen möchte?

Allgemein - Erste Schritte zum Einstieg in die Entwicklung by @

Spoiler

Quote:

Originally Posted by Rainer Wahnsinn

Hey,

eine Dokumentation in dem Sinne gibt es nicht.
Ein paar koreanische Kommentare hier und da, das wars dann aber auch.

Das meiste muss man für sich selbst erkunden und nachvollziehen.
Ein paar Tipps für den Start kann ich dir jedoch mit auf den Weg geben.

Vorweg:
Ich selbst habe damit begonnen den Server zu modifizieren, bevor ich mir den Client angeschaut habe.

Es ist außerdem sehr empfehlenswert Visual Studio zum bearbeiten des Codes zu verwenden.
Damit sieht nicht nur alles strukturiert und schön aus, sondern du kannst direkt zu den jeweiligen Aufrufen von Funktionen navigieren,
ohne mühsam 321 Dateien mit NP++ durchsuchen zu müssen.

Eine weitere bewährte Methode ist es, Funktionsblöcke ein- bzw. aufzuklappen (Bearbeiten -> Gliedern -> Alle Gliederungen umschalten).
So verlierst du nicht die Übersicht.

Zu Beginn kann ich nur raten die Character- sowie Item-Klasse genauer zu untersuchen.
Dazu zählen char.h char.cpp char_battle.cpp char_item.cpp char_skill.cpp item.h item.cpp
Außerdem interessant für den Anfang:
constants.h constants.cpp cmd.cpp cmd_general.cpp cmd_gm.cpp config.h config.cpp
/common/item_length.h & length.h

Alleine in der Character-Klasse lassen sich schon viele Dinge so abändern, um ingame Veränderungen feststellen zu können.
Dann würde ich einen Blick auf die Kommunikation zwischen Server & Client sowie umgekehrt werfen.

Ausschlaggebende Dateien für die Kommunikation sind:
packet.h => enthält die Struktur der Pakete (muss 1:1 mit Client übereinstimmen)
packet_info.cpp => registriert vom Client gesendete Pakete
input_main.cpp => handled ankommende Pakete vom Client

Im Anschluss daran ist dann noch die Kommunikation zwischen Server und dem DB-Core interessant.
/common/tables.h => entspricht der packet.h zur Client-Kommunikation
/db/ClientManager.cpp => handled ankommende Pakete vom GAME-Core
/game/input_db.cpp => handled ankommende Pakete vom DB-Core

Ein paar wenige Konventionen an welche man sich tatsächlich durchgehend gehalten hat gibt es übrigens auch noch.
Zum Beispiel enthalten die Paket-Header immer ein eindeutiges Kürzel im Namen, wie HEADER_CG_QUICKSLOT_ADD.
In diesem Fall steht CG für Client-Game, sprich dieses Paket wird vom Client erwartet und auf Serverseite verarbeitet.
Weitere Kürzel: GC (Game-Client) CG (Client-Game) GD (Game-Database) DG (Database-Game)

Ich denke mit den Informationen solltest du dich erstmal etwas einlesen können. Wenn du bereit für den Client bist, melde dich.

Grüße

UI programming guideline by masodikbela:

UI - what are .sub files? explained by Sonitex @ metin2 dev discord

Spoiler

Rainer Wahnsinn · 11/18/2020, 22:48

Hey,

eine Dokumentation in dem Sinne gibt es nicht.
Ein paar koreanische Kommentare hier und da, das wars dann aber auch.

Das meiste muss man für sich selbst erkunden und nachvollziehen.
Ein paar Tipps für den Start kann ich dir jedoch mit auf den Weg geben.

Vorweg:
Ich selbst habe damit begonnen den Server zu modifizieren, bevor ich mir den Client angeschaut habe.

Es ist außerdem sehr empfehlenswert Visual Studio zum bearbeiten des Codes zu verwenden.
Damit sieht nicht nur alles strukturiert und schön aus, sondern du kannst direkt zu den jeweiligen Aufrufen von Funktionen navigieren,
ohne mühsam 321 Dateien mit NP++ durchsuchen zu müssen.

Eine weitere bewährte Methode ist es, Funktionsblöcke ein- bzw. aufzuklappen (Bearbeiten -> Gliedern -> Alle Gliederungen umschalten).
So verlierst du nicht die Übersicht.

Zu Beginn kann ich nur raten die Character- sowie Item-Klasse genauer zu untersuchen.
Dazu zählen char.h char.cpp char_battle.cpp char_item.cpp char_skill.cpp item.h item.cpp
Außerdem interessant für den Anfang:
constants.h constants.cpp cmd.cpp cmd_general.cpp cmd_gm.cpp config.h config.cpp
/common/item_length.h & length.h

Alleine in der Character-Klasse lassen sich schon viele Dinge so abändern, um ingame Veränderungen feststellen zu können.
Dann würde ich einen Blick auf die Kommunikation zwischen Server & Client sowie umgekehrt werfen.

Ausschlaggebende Dateien für die Kommunikation sind:
packet.h => enthält die Struktur der Pakete (muss 1:1 mit Client übereinstimmen)
packet_info.cpp => registriert vom Client gesendete Pakete
input_main.cpp => handled ankommende Pakete vom Client

Im Anschluss daran ist dann noch die Kommunikation zwischen Server und dem DB-Core interessant.
/common/tables.h => entspricht der packet.h zur Client-Kommunikation
/db/ClientManager.cpp => handled ankommende Pakete vom GAME-Core
/game/input_db.cpp => handled ankommende Pakete vom DB-Core

Ein paar wenige Konventionen an welche man sich tatsächlich durchgehend gehalten hat gibt es übrigens auch noch.
Zum Beispiel enthalten die Paket-Header immer ein eindeutiges Kürzel im Namen, wie HEADER_CG_QUICKSLOT_ADD.
In diesem Fall steht CG für Client-Game, sprich dieses Paket wird vom Client erwartet und auf Serverseite verarbeitet.
Weitere Kürzel: GC (Game-Client) CG (Client-Game) GD (Game-Database) DG (Database-Game)

Ich denke mit den Informationen solltest du dich erstmal etwas einlesen können. Wenn du bereit für den Client bist, melde dich.

Grüße

Guron · 11/19/2020, 09:05

Quote:

Originally Posted by Rainer Wahnsinn

Hey,

eine Dokumentation in dem Sinne gibt es nicht.
Ein paar koreanische Kommentare hier und da, das wars dann aber auch.

Das meiste muss man für sich selbst erkunden und nachvollziehen.
Ein paar Tipps für den Start kann ich dir jedoch mit auf den Weg geben.

Vorweg:
Ich selbst habe damit begonnen den Server zu modifizieren, bevor ich mir den Client angeschaut habe.

Es ist außerdem sehr empfehlenswert Visual Studio zum bearbeiten des Codes zu verwenden.
Damit sieht nicht nur alles strukturiert und schön aus, sondern du kannst direkt zu den jeweiligen Aufrufen von Funktionen navigieren,
ohne mühsam 321 Dateien mit NP++ durchsuchen zu müssen.

Eine weitere bewährte Methode ist es, Funktionsblöcke ein- bzw. aufzuklappen (Bearbeiten -> Gliedern -> Alle Gliederungen umschalten).
So verlierst du nicht die Übersicht.

Zu Beginn kann ich nur raten die Character- sowie Item-Klasse genauer zu untersuchen.
Dazu zählen char.h char.cpp char_battle.cpp char_item.cpp char_skill.cpp item.h item.cpp
Außerdem interessant für den Anfang:
constants.h constants.cpp cmd.cpp cmd_general.cpp cmd_gm.cpp config.h config.cpp
/common/item_length.h & length.h

Alleine in der Character-Klasse lassen sich schon viele Dinge so abändern, um ingame Veränderungen feststellen zu können.
Dann würde ich einen Blick auf die Kommunikation zwischen Server & Client sowie umgekehrt werfen.

Ausschlaggebende Dateien für die Kommunikation sind:
packet.h => enthält die Struktur der Pakete (muss 1:1 mit Client übereinstimmen)
packet_info.cpp => registriert vom Client gesendete Pakete
input_main.cpp => handled ankommende Pakete vom Client

Im Anschluss daran ist dann noch die Kommunikation zwischen Server und dem DB-Core interessant.
/common/tables.h => entspricht der packet.h zur Client-Kommunikation
/db/ClientManager.cpp => handled ankommende Pakete vom GAME-Core
/game/input_db.cpp => handled ankommende Pakete vom DB-Core

Ein paar wenige Konventionen an welche man sich tatsächlich durchgehend gehalten hat gibt es übrigens auch noch.
Zum Beispiel enthalten die Paket-Header immer ein eindeutiges Kürzel im Namen, wie HEADER_CG_QUICKSLOT_ADD.
In diesem Fall steht CG für Client-Game, sprich dieses Paket wird vom Client erwartet und auf Serverseite verarbeitet.
Weitere Kürzel: GC (Game-Client) CG (Client-Game) GD (Game-Database) DG (Database-Game)

Ich denke mit den Informationen solltest du dich erstmal etwas einlesen können. Wenn du bereit für den Client bist, melde dich.

Grüße

Vielen Dank für diesen wahnsinnig guten Beitrag. Ich werde mir das mal im laufe der Zeit anschauen und Fragen... viele Fragen stellen

Edit:
Ich hab mir gestern das Skybox System runtergeladen und hab mir da mal den Code angeschaut. Recht simpel und hat mir geholfen ein wenig hinter dem GUI zu blicken. Evtl. für den ein oder anderen ein interessanter Hinweis. Vielleicht können wir diesen Thread hier gemeinsam pflegen und ein Tipps und Leitfaden für die Source halten?

Guron · 11/23/2020, 11:54

Ich hab euch mal im Startbeitrag guidelines zur UI verlinkt, eventuell hilft das dem ein oder anderen der genau so wie ich tiefer in die Materie will. Hier nochmal der Link:

- vielleicht habt ihr ja auch etwas zum teilen, würde es gerne in den Startbeitrag für die Nachwelt festhalten

Guron · 11/25/2020, 15:16

Kleines aber feines Pflegeupdate zur ui:

UI - what are .sub files? explained by Sonitex @ metin2 dev discord

Spoiler

Gerne könnt ihr euch anschließen und ein paar hilfreiche Sachen posten um ein bisschen die Entwicklerszene zu unterstützen

Erklärung wurde im Startpost verlinkt

Guron · 11/26/2020, 23:10

Ich habe mich etwas mehr mit der UI beschäftigt und konnte auch schon einiges an Notizen sammeln. Gerne stelle ich hier mal ein paar Notizen zur verfügung und erläutere das ganze mal anhand des Escape Menü. Achtung: Bisherige Notizen bestehen aus Halbwissen! Die Notizen gelten für die Fliege Files aus dem Versuch das Skybox System dafür zu recoden.

game.py:
Nach meiner Recherche besteht die game.py aus Interface/Windows/Dialoge Aufrufen die über Keytoggles getriggerd werden. Dabei wird nach aktuellem Stand, immer eine Funktion für den Key innerhalb der Klasse aufgerufen. Bisher ist es so, dass die game.py selber kein Interface/Windows/Dialoge erstellt bzw. aufruft, sondern die dazugehörige Python Klasse aufruft. Diese ist einzig und allein dafür verantwortlich, dass das Window erstellt und aufgerufen wird.

Im Fall des Escape Menüs, wird die Funktion "OpenSystemDialog()" aufgerufen von der Variable interface in der die Klasse interfaceModule gespeichert ist.

interfacemodule.py
So ganz konnte ich leider noch nicht deuten und herausfinden was diese Klasse macht, in Fall des Escape Menu wird die Klasse uiSystem aufgerufen. Das ist aktuell die Klasse für das tatsächliche Escape Menü.

uiSystem.py
Diese Klasse ist tatsächlich das Frontend für das Escape Menü. Hier werden die Buttons geholt und einzelnen Funktionen die eine Aufgabe haben (beispielsweise das Game Option Menu öffnen) zugewiesen.

Es gibt zu den Buttons ein kleines Detail in den Fliege Files bei denen ich nicht weiß inwiefern dieses Konzept in anderen Files verbreitet ist. Das Skybox System dass ich mir runtergeladen habe hat jedenfalls eine andere Struktur, dort lässt sich ein Button bereits in der game.py erstellen (meiner Meinung nach nicht wirklich intuitiv und sicher).

In den Fliege Files gibt es die uiscriptlocale.py in der die Variable "LOCALE_UISCRIPT_PATH" mit dem Pfad für die Sprachdatei festgelegt wird. In meinem Fall ist das die deutsche Sprache, also referenzieren wir die Files in de. Die Buttons in der Fliege File werden in diesem Sprachordner in der systemdialog.py (für das Menü) initalisiert und anschließend von der uisystem Klasse aufgerufen.

Die Vorteile dieses System stecken im Detail die ich leider noch nicht kenne, aber im groben ergibt sich folgendes daraus:
- Redundanz wird vermieden
- Middleware Ähnliche Funktionsweise
- Übersichtliche Darstellung von Buttons

In der [B]systemdialog.py[/B werden die Buttons für das System (ESCP Menü) aufgebaut und können anschließend benutzt werden. Die Buttons erhalten einen Identifier der gleichzeitig auch die Beschreibung des Btns in der local_interface.txt ist. In der systemdialog.py lässt sich Frontendtechnisch noch einiges ändern wie z.B. die Breite und Höhe des Fenster.

Nettes Konzept das in größeren Projekten sein Einsatz findet. Hiermit lässt sich auf jeden Fall was anfangen. Mein nächstes Ziel wird es dann sein das Skybox System dass ich gefunden habe auf die Fliege Files umzuschreiben. Danach steht eine Verbesserung des Codes an.

Wie immer könnt ihr eure Erfahrung gerne teilen.