![[Tutorial]Metin2 Programmierung Teil 1](https://www.elitepvpers.com/forum/iconimages/metin2-pserver-guides-strategies/tutorial-metin2-programmierung-teil-1-a_ltr.gif){kind=small}
Der 1. Teil befasst sich neben einer kleinen einführung über grundsätzliches und Eckdaten von Client und Server die sowohl interessant als auch wichtig zum scripten sind.
Hier nun eine kleine Übersicht über die Punkte:
- Clientseitig
- Wie entpacke ich die Dateien?
- In welcher Programmiersprache ist Metin2 geschrieben?
- Was ist möglich, was nicht?
- Modding
- Hacking
- Wie packe ich die Dateien?
- Serverseitig
- Welche Dateien kann man bearbeiten?
- Configs
- Quests
- Datenbank
- Was macht Sinn es zu ändern?
- Was ist möglich, was nicht?
- Welche Dateien kann man bearbeiten?
- Schlusswort
A Clientseitig
Hier werden wir uns mit der Programmierung des Metin2-Clients auseinandersetzten und erläutern wie man grundlegende Sachen ändert.
Wie entpacke ich die Dateien?
Die wesentlichen Dateien, in denen entscheidene Sachen für das Spiel stehen sind gepackt nur ungefähr 430kb groß und in der root.epk und root.eix enthalten.
Ohne diese Dateien würde nichts laufen. Vielleicht fragt sich nun der ein oder andere von euch, warum zur Hölle ist der Metin2 Client dann ca. 500 MegaByte groß?
Nunja diese Frage lässt sich recht einfach beantworten. Es liegt an den 3D-Modellen, an den tausenden von Bildern und an den Landschaften, die einzeln zwar klein sein mögen, aber in der Menge unheimlich viel Platz verschlingen. Auch wenn 500 MB heutzutage Peanuts sind und fast jeder Festplatten mit über 100 GigaByte Speicher hat, sind es dennoch nicht wenige Dateien.
Kommen wir nun zum entpacken der Dateien.
Es gibt in elitepvpers schon seit längerer Zeit ein paar Entpacker, die es ermöglichen .epk und .eix Dateien zu öffnen und zu bearbeiten.
An dieser Stelle empfehle ich euch den Extracter von Eddy² zu nutzen.
Ihr erhaltet ihn unter folgender Adresse:
Natürlich könnt ihr auch jeden anderen nutzen, jedoch nehme ich diesen aus dem einfachen Grund das er eine Grafische Oberfläche hat und somit leichter zu bedienen ist.
Entpackt nun den Editor von Eddy². (Zum entpacken könnt ihr z.B. WinRar(kostenlos) benutzen)
Verschiebt den Extracter in den pack Ordner eures Metin2-Clients. Standardmässig befindet dieser sich nach der Installation in C:\Programme\Metin2_Germany .
Startet den Extracter mit einem Doppelklick und wählt den Reiter EPK / EIX aus.
Jetzt müsst ihr noch in das Textfeld hinter Archive "root" (ohne die Gänsefüßchen) eingeben und auf Extract! drücken.
Wartet bis der Extracter meldet er sei fertig und wechselt in den pack Ordner. Dort sollten, sobald das root-Archiv entpackt ist, ein Ordner mit dem Namen Source und eine Datei Namens pack.xml auftauchen. Die pack.xml wird vom Entpacker automatisch erstellt, damit man die Dateien später wieder packen kann. Im Source Ordner befinden die soeben entpackten Dateien.
Damit der Client später die entpackten Dateien läd und nicht die gepackten, müsst ihr den gesamten Inhalt des Source Ordners in euren Metin2 Ordner transferieren und die Root.epk und Root.eix löschen.
Nun wären wir mit dem Entpacken fertig.
Ohne diese Dateien würde nichts laufen. Vielleicht fragt sich nun der ein oder andere von euch, warum zur Hölle ist der Metin2 Client dann ca. 500 MegaByte groß?
Nunja diese Frage lässt sich recht einfach beantworten. Es liegt an den 3D-Modellen, an den tausenden von Bildern und an den Landschaften, die einzeln zwar klein sein mögen, aber in der Menge unheimlich viel Platz verschlingen. Auch wenn 500 MB heutzutage Peanuts sind und fast jeder Festplatten mit über 100 GigaByte Speicher hat, sind es dennoch nicht wenige Dateien.
Kommen wir nun zum entpacken der Dateien.
Es gibt in elitepvpers schon seit längerer Zeit ein paar Entpacker, die es ermöglichen .epk und .eix Dateien zu öffnen und zu bearbeiten.
An dieser Stelle empfehle ich euch den Extracter von Eddy² zu nutzen.
Ihr erhaltet ihn unter folgender Adresse:
Natürlich könnt ihr auch jeden anderen nutzen, jedoch nehme ich diesen aus dem einfachen Grund das er eine Grafische Oberfläche hat und somit leichter zu bedienen ist.
Entpackt nun den Editor von Eddy². (Zum entpacken könnt ihr z.B. WinRar(kostenlos) benutzen)
Verschiebt den Extracter in den pack Ordner eures Metin2-Clients. Standardmässig befindet dieser sich nach der Installation in C:\Programme\Metin2_Germany .
Startet den Extracter mit einem Doppelklick und wählt den Reiter EPK / EIX aus.
Jetzt müsst ihr noch in das Textfeld hinter Archive "root" (ohne die Gänsefüßchen) eingeben und auf Extract! drücken.
Wartet bis der Extracter meldet er sei fertig und wechselt in den pack Ordner. Dort sollten, sobald das root-Archiv entpackt ist, ein Ordner mit dem Namen Source und eine Datei Namens pack.xml auftauchen. Die pack.xml wird vom Entpacker automatisch erstellt, damit man die Dateien später wieder packen kann. Im Source Ordner befinden die soeben entpackten Dateien.
Damit der Client später die entpackten Dateien läd und nicht die gepackten, müsst ihr den gesamten Inhalt des Source Ordners in euren Metin2 Ordner transferieren und die Root.epk und Root.eix löschen.
Nun wären wir mit dem Entpacken fertig.
In welcher Programmiersprache ist Metin2 geschrieben?
Metin2 ist mit mehreren Sprachen geschrieben, welche zusammen ein Programm ergeben.
Metin2 wurde ursprünglich für Windows2000/XP entwickelt. Bisher sind keine Mac oder Linux Versionen erschienen.
Die .exe-Datei welche das Programm an sich ist, wurde in C++ verfasst. Die Version ist noch unbekannt, aber es liegt auch noch kein offizieller Source der .exe vor und wird wahrscheinlich auch nicht publiziert werden.
Die anderen Dateien die wir im 1. Unterpunkt entpackt haben und sich im Root-Archiv befanden sind in Python 2.2 geschrieben.
Selbst die Fenster die man bei Metin2 sieht (Inventarfenster usw.) haben eine eigene Sprache. Beziehungsweise wurden sie so programmiert, dass sie zwar keine eigenständigen Programme hervorbingen können, aber vom Client interpretiert und angezeigt werden.
Serverseitig wurde Metin2 für die Plattform FreeBSD entwickelt welche auf UNIX basiert.
Metin2 wurde ursprünglich für Windows2000/XP entwickelt. Bisher sind keine Mac oder Linux Versionen erschienen.
Die .exe-Datei welche das Programm an sich ist, wurde in C++ verfasst. Die Version ist noch unbekannt, aber es liegt auch noch kein offizieller Source der .exe vor und wird wahrscheinlich auch nicht publiziert werden.
Die anderen Dateien die wir im 1. Unterpunkt entpackt haben und sich im Root-Archiv befanden sind in Python 2.2 geschrieben.
Selbst die Fenster die man bei Metin2 sieht (Inventarfenster usw.) haben eine eigene Sprache. Beziehungsweise wurden sie so programmiert, dass sie zwar keine eigenständigen Programme hervorbingen können, aber vom Client interpretiert und angezeigt werden.
Serverseitig wurde Metin2 für die Plattform FreeBSD entwickelt welche auf UNIX basiert.
Was ist möglich, was nicht?
Hier müssen wir meiner Meinung nach zwischen zwei dingen unterscheiden. Das wäre einmal das sogenannte Modding, was sich mit dem ändern und abwandeln des ursprünglichen Codes handelt, welches durchaus im Sinne von Serverbetreibern sein kann, und dann wäre da noch das Hacking womit ich das ändern des Codes verbinde um sich selbst zu bevorteiligen.
Kommen wir ersteinmal zum Modding.
Modding
Modding ist schlicht und ergreifend das verändern von Code ohne das es irgendjemandem schadet. So fallen unter den Stichpunkt Modding Sachen, wie zum Beispiel das abändern der Farben von Skills, Landschaften oder Erleichterung der Benutzung.
Hier nun eine Liste der Sachen die durch Modding veränderbar sind:
- Veränderung von Texten
- Verändurung der Farben von Charackteren, Maps, Häusern, Skills, dem Interface, Items, Waffen, Rüstungen und fast allem anderem Sichtbarem.
- Veränderung von Funktionen um zum Beispiel Spam aus dem Weg zu gehen.
Hacking
Das böswilligere Hacking ist gedacht, um sich selbst einen Vorteil gegenüber anderen Spielern zu verschaffen und somit besser und/oder schneller an ein Ziel zu gelangen als diese.
Hier nun eine Aufzählung der Möglichkeiten, die Hacking bietet:
- Entfernung der Landschaften und Häuser etc. => Alles auf einer Ebene und man kann durch Wände, Flüsse und Häuser laufen und sehen.
- Veränderung von Formen und Farben um Objekte besser zu erkennen
- Veränderung von Funktionen um schneller zu sein als andere.
Dies soll nur eine kleine Aufzählung der Möglichkeiten sein, denn es gibt noch ein paar mehr Sachen.
Es gilt außerdem nur zur Demonstration der Möglichkeiten die durch das Ändern des Codes entstehen.
Kommen wir ersteinmal zum Modding.
Modding
Modding ist schlicht und ergreifend das verändern von Code ohne das es irgendjemandem schadet. So fallen unter den Stichpunkt Modding Sachen, wie zum Beispiel das abändern der Farben von Skills, Landschaften oder Erleichterung der Benutzung.
Hier nun eine Liste der Sachen die durch Modding veränderbar sind:
- Veränderung von Texten
- Verändurung der Farben von Charackteren, Maps, Häusern, Skills, dem Interface, Items, Waffen, Rüstungen und fast allem anderem Sichtbarem.
- Veränderung von Funktionen um zum Beispiel Spam aus dem Weg zu gehen.
Hacking
Das böswilligere Hacking ist gedacht, um sich selbst einen Vorteil gegenüber anderen Spielern zu verschaffen und somit besser und/oder schneller an ein Ziel zu gelangen als diese.
Hier nun eine Aufzählung der Möglichkeiten, die Hacking bietet:
- Entfernung der Landschaften und Häuser etc. => Alles auf einer Ebene und man kann durch Wände, Flüsse und Häuser laufen und sehen.
- Veränderung von Formen und Farben um Objekte besser zu erkennen
- Veränderung von Funktionen um schneller zu sein als andere.
Dies soll nur eine kleine Aufzählung der Möglichkeiten sein, denn es gibt noch ein paar mehr Sachen.
Es gilt außerdem nur zur Demonstration der Möglichkeiten die durch das Ändern des Codes entstehen.
Wie packe ich die Dateien?
Um eine sichtbare Veränderung zu haben öffnen wir die Datei introloading.py aus dem Root-Archiv mit Notepad++().
Wählt nun in der Menüleiste Sprachen -> P -> Python und ihr solltet eine andere Farbe sehen und nun besser erkennen was zusammengehört.Drückt nun STRG+F, wählt Ersetzen und fügt bei Suchen nach 25600 ein und bei Ersetzen durch tragt ihr 600000 ein. Klickt nun auf ersetzen und ihr könnt ESC drücken, sobald Notepad ersetzt hat. Das Fenster sollte sich nun schließen und ihr speichert die Datei.
Je nach dem wo sich die .py Dateien aus dem Root-Archiv nun befinden, müsst ihr die Pack.xml und den Packer von Eddy² in den den direkten Überornder verschieben in dem sich die .py-Dateien befinden.
Öffnet nun erneut den Extracter/Packer und wählt wieder den Reiter EPK / EIX aus. Tragt dort jetzt bei Archive wieder "root" ein und drückt diesmal auf das untere Feld mit der Aufschrift Pack!
Fetig sind eure neuen Archivdateien. Startet nun Metin2 per Bypass
und logt euch ein. Sobald ihr die Spieltwelt betretet solltet ihr verstehen warum ihr vorhin 25600 durch 600000 ersetzten solltet.
).Wählt nun in der Menüleiste Sprachen -> P -> Python und ihr solltet eine andere Farbe sehen und nun besser erkennen was zusammengehört.Drückt nun STRG+F, wählt Ersetzen und fügt bei Suchen nach 25600 ein und bei Ersetzen durch tragt ihr 600000 ein. Klickt nun auf ersetzen und ihr könnt ESC drücken, sobald Notepad ersetzt hat. Das Fenster sollte sich nun schließen und ihr speichert die Datei.
Je nach dem wo sich die .py Dateien aus dem Root-Archiv nun befinden, müsst ihr die Pack.xml und den Packer von Eddy² in den den direkten Überornder verschieben in dem sich die .py-Dateien befinden.
Öffnet nun erneut den Extracter/Packer und wählt wieder den Reiter EPK / EIX aus. Tragt dort jetzt bei Archive wieder "root" ein und drückt diesmal auf das untere Feld mit der Aufschrift Pack!
Fetig sind eure neuen Archivdateien. Startet nun Metin2 per Bypass
im Metin2 Verzeichnis eine .bat-Datei erstellen mit dem Inhalt:
und Ausführen
Code:
@echo off metin2.bin
B Serverseitig
Kommen wir nun zum 2. großen Punkt des 1. Teils. Hier erwartet euch eine ähnliche Gliederung wie bei A, aber dieser Teil ist besonders für Serveradministratoren gedacht.
Außerdem möchte ich hier auch Neulinge dazu bewegen etwas an ihren Servern zu verändern und keine 0815-Server fördern.
Also fangen wir an.
Welche Dateien kann man bearbeiten?
Serverseitig sind deutlich schwerwiegendere Veränderungen möglich als Clientseitig, jedoch beschränkt sich dies nur auf einen kleineren Bereich.
Es gibt in meinen Augen drei große Teile die Spielentscheidend sind.
Das wären:
a) die CONFIGs
b) die Quests
c) die Datenbank
Also gehen wir doch mal Reihenweise durch, welche Möglichkeiten uns die verschiedenen Teile bieten.
Configs
Quests
Datenbank
Es gibt in meinen Augen drei große Teile die Spielentscheidend sind.
Das wären:
a) die CONFIGs
b) die Quests
c) die Datenbank
Also gehen wir doch mal Reihenweise durch, welche Möglichkeiten uns die verschiedenen Teile bieten.
Configs
Die Config-Dateien sind für die einzelnen Spielteilserver eine Art Lebenselexir. Sie enthalten wichtige Informationen damit die Server überhaupt laufen können, aber sie sind durchaus in der Lage auch Begrenzungen zu erstellen.
Dabei ist jedoch zu beachten welche Config für welchen Teil des Servers verantwortlich ist. Dies geht vorallem aus der MAP-ALLOW: Zeile vor.
Hier folgt nun eine kurze Auflistung der einzelnen Config Dateien und ein paar Worte zu eben diesen.
1.) /game/auth/CONFIG
Diese Config, bzw. der Auth-Ordner ist für Login-Server zuständig. Hierrüber laufen jegliche Kontakte auf euren Server. Es ist also wichtig, dass dieser Server permanent online ist. Anosnten bleibt der Besuch aus.
2.) /game/db/conf.txt
Diese Config ist für den Datenbankserver und den Kontakt zwischen Server und Datenbank zuständig. Sie verbindet mit dem Server, regelt die Übertragung der Daten aus dem Zwischenspeicher (idr. alle 7 Minuten), dass Limit zum löschen von Charackteren und die Übertragungsrate zwischen Client und Server.
3.) /game/channel/first/CONFIG
Dies ist der Charserver der die Verteilung der einzelnen Spieler auf die anderen Serverteile verwaltet.
4.) /game/channel/game1_1/CONFIG
Dieser Server beschäftigt sich ausschließlich mit der Map1 des roten Reichs.
5.) /game/channel/game1_2/CONFIG
Dieser Server beschäftigt sich ausschließlich mit der Map1 des gelben Reichs.
6. /game/channel/game1_3/CONFIG
Dieser Server beschäftigt sich ausschließlich mit der Map1 des blauen Reichs.
7. /game/channel/game2/CONFIG
Dieser Serverteil ist für alle Zweitmaps zuständig. Das heißt für Map2 und die Gildenzonen aller Reiche sowie ein paar kleineren Maps.
8. /game/channel/game61/CONFIG
Über diesen Server läuft der Dämonenturm, die Maps Feuerland, Orktal, Eisland, RW usw.
9. /game/channel99/CONFIG
Auf diesem Server laufen hauptsächlich die Dungeons (AD,SD,SD2 etc.)
Wer sich intressiert welche Map genau zu welchem Serverteil gehört, kann die Nummern mit den Nummern in der index-Datei in folgendem Pfad vergleichen: game/share/locale/hongkong/map
Jedoch bieten euch die Configs noch deutlich mehr Optionen:
Dabei ist jedoch zu beachten welche Config für welchen Teil des Servers verantwortlich ist. Dies geht vorallem aus der MAP-ALLOW: Zeile vor.
Hier folgt nun eine kurze Auflistung der einzelnen Config Dateien und ein paar Worte zu eben diesen.
1.) /game/auth/CONFIG
Code:
HOSTNAME: metin2_auth CHANNEL: 1 #PORT: 11009 PORT: 11002 P2P_PORT: 12001 DB_PORT: 15001 DB_ADDR: localhost TABLE_POSTFIX: ITEM_ID_RANGE: 000000001 000000002 PASSES_PER_SEC: 25 SAVE_EVENT_SECOND_CYCLE: 180 PING_EVENT_SECOND_CYCLE: 180 AUTH_SERVER: master PLAYER_SQL: account_m auth dhels account LOG_SQL: log_m auth dhels log COMMON_SQL: common auth dhels common
2.) /game/db/conf.txt
Code:
WELCOME_MSG = "DB Server has been started" SQL_ACCOUNT = "account_m account dbcache dhels 0" SQL_PLAYER = "player_m player dbcache dhels 0" SQL_COMMON = "account_m common dbcache dhels 0" SQL_HOTBACKUP = "player_m hotbackup dbcache dhels 0" TABLE_POSTFIX = "" BIND_PORT = 15001 DB_SLEEP_MSEC = 10 CLIENT_HEART_FPS = 25 HASH_PLAYER_LIFE_SEC = 600 BACKUP_LIMIT_SEC = 3600 PLAYER_ID_START = 100 PLAYER_DELETE_LEVEL_LIMIT = 70 ITEM_ID_RANGE = 70000001 100000000 LOCALE = big5
3.) /game/channel/first/CONFIG
Code:
HOSTNAME: first CHANNEL: 1 PORT: 13000 P2P_PORT: 14000 DB_PORT: 15001 DB_ADDR: dbcache MAP_ALLOW: TABLE_POSTFIX: ITEM_ID_RANGE: 5000001 10000000 PASSES_PER_SEC: 25 SAVE_EVENT_SECOND_CYCLE: 180 PING_EVENT_SECOND_CYCLE: 180 PLAYER_SQL: player_m game dhels player COMMON_SQL: common game dhels common LOG_SQL: log_m game dhels log #TEST_SERVER: 1
4.) /game/channel/game1_1/CONFIG
Code:
HOSTNAME: game1_1 CHANNEL: 1 PORT: 13001 P2P_PORT: 14001 DB_PORT: 15001 DB_ADDR: dbcache MAP_ALLOW: 1 TABLE_POSTFIX: ITEM_ID_RANGE: 100000001 150000000 PASSES_PER_SEC: 25 SAVE_EVENT_SECOND_CYCLE: 180 PING_EVENT_SECOND_CYCLE: 180 PLAYER_SQL: player_m game dhels player COMMON_SQL: common game dhels common LOG_SQL: log_m game dhels log #TEST_SERVER: 1
5.) /game/channel/game1_2/CONFIG
Code:
HOSTNAME: game1_2 CHANNEL: 1 PORT: 13002 P2P_PORT: 14002 DB_PORT: 15001 DB_ADDR: dbcache MAP_ALLOW: 21 TABLE_POSTFIX: ITEM_ID_RANGE: 150000001 200000000 PASSES_PER_SEC: 25 SAVE_EVENT_SECOND_CYCLE: 180 PING_EVENT_SECOND_CYCLE: 180 PLAYER_SQL: player_m game dhels player COMMON_SQL: common game dhels common LOG_SQL: log_m game dhels log #TEST_SERVER: 1
6. /game/channel/game1_3/CONFIG
Code:
HOSTNAME: game1_3 CHANNEL: 1 PORT: 13003 P2P_PORT: 14003 DB_PORT: 15001 DB_ADDR: dbcache MAP_ALLOW: 41 TABLE_POSTFIX: ITEM_ID_RANGE: 200000001 250000000 PASSES_PER_SEC: 25 SAVE_EVENT_SECOND_CYCLE: 180 PING_EVENT_SECOND_CYCLE: 180 PLAYER_SQL: player_m game dhels player COMMON_SQL: common game dhels common LOG_SQL: log_m game dhels log #TEST_SERVER: 1
7. /game/channel/game2/CONFIG
Code:
HOSTNAME: game2 CHANNEL: 1 PORT: 13004 P2P_PORT: 14004 DB_PORT: 15001 DB_ADDR: dbcache MAP_ALLOW: 3 4 23 24 43 44 107 5 25 45 TABLE_POSTFIX: ITEM_ID_RANGE: 250000001 300000000 PASSES_PER_SEC: 25 SAVE_EVENT_SECOND_CYCLE: 180 PING_EVENT_SECOND_CYCLE: 180 COMMON_SQL: common game dhels common PLAYER_SQL: player_m game dhels player LOG_SQL: log_m game dhels log #TEST_SERVER: 1
8. /game/channel/game61/CONFIG
Code:
HOSTNAME: game61 CHANNEL: 1 PORT: 13061 P2P_PORT: 14061 DB_PORT: 15001 DB_ADDR: dbcache #MAP_ALLOW: 61 62 63 64 65 66 67 68 69 70 74 75 77 78 104 108 109 129 130 131 132 180 MAP_ALLOW: 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 77 78 104 108 109 129 130 131 132 180 184 185 186 187 188 189 112 TABLE_POSTFIX: ITEM_ID_RANGE: 300000001 350000000 PASSES_PER_SEC: 25 SAVE_EVENT_SECOND_CYCLE: 180 PING_EVENT_SECOND_CYCLE: 180 PLAYER_SQL: player_m game dhels player COMMON_SQL: common game dhels common LOG_SQL: log_m game dhels log #TEST_SERVER: 1
9. /game/channel99/CONFIG
Code:
HOSTNAME: game99 CHANNEL: 99 PORT: 13099 P2P_PORT: 14099 DB_PORT: 15001 DB_ADDR: dbcache #MAP_ALLOW: 103 105 110 111 81 113 114 118 119 120 121 122 123 124 125 126 127 128 181 182 183 MAP_ALLOW: 103 105 110 111 81 113 114 118 119 120 121 122 123 124 125 126 127 128 181 182 183 TABLE_POSTFIX: ITEM_ID_RANGE: 50000001 100000000 PASSES_PER_SEC: 25 SAVE_EVENT_SECOND_CYCLE: 180 PING_EVENT_SECOND_CYCLE: 180 PLAYER_SQL: player_m game dhels player COMMON_SQL: common game dhels common LOG_SQL: log_m game dhels log #TEST_SERVER: 1
Wer sich intressiert welche Map genau zu welchem Serverteil gehört, kann die Nummern mit den Nummern in der index-Datei in folgendem Pfad vergleichen: game/share/locale/hongkong/map
Jedoch bieten euch die Configs noch deutlich mehr Optionen:
Code:
CHANNEL: <- Definiert den Channel. (Besonders wichtig bei Servern auf den mehr als 1 CH laufen) PORT: <- Definieret den Port über den dieser Server erreichbar ist. P2P_PORT: <- Port der die Datenübertragung von Spieler zu Spieler managed. DB_PORT: <- Port über den der DB-Server (game/db) erreichbar ist. Dieser ist nur intern verfügbar, aber dennoch wichtig. DB_ADDR: <- Adresse der Datenbank (in der Regel ist dies Localhost (game/db)) MAP_ALLOW: <- Maps die dieser Teilserver betreibt TABLE_POSTFIX: <- Endung des Namens der Tabelle. So können zum Beispiel in einer Player-Datenbank mehrere player-Tabellen mit unterschiedlichen Endungen existieren. (Gilt natürlich auch für alle anderen Tabellen in der Player-Datenbank dann) ITEM_ID_RANGE: <- Weißt dem Server einen Bereich zu, der definiert welche IDs Items bekommen die gedroppt werden oder ähnliches. Muss bei jedem Serverteil verschieden sein (Syntax= Zahl1-Zahl2) PASSES_PER_SEC: <- Nicht genau bekannt, aber anscheinend eine Zeitverzögerrungsangabe. SAVE_EVENT_SECOND_CYCLE: <- Zeitabstand in dem der Clientpuffer an den Serverpuffer übergeben wird. PING_EVENT_SECOND_CYCLE: <- Zeit die der Client zum Antworten hat. PLAYER_SQL: <- Zugangsdaten für die Player-Datenbank COMMON_SQL: <- Zugangsdaten für die Common-Datenbank LOG_SQL: <- Zugangsdaten für die Log-Datenbank TEST_SERVER: <- Wenn auf 1 gestellt wird, haben alle auf dem Server Rechte und jede einzelne Handlung wird genaustens im Chat angegeben. NO_MORE_CLIENT: <- Kann jeglich Logins verbieten. Wird zum Beispiel bei gestartet Shutdownvorgang vom Server intern auf 1 gesetzt damit sich niemand mehr einloggt. NO_REGEN: <- Wenn auf 1 gestellt wurde, spawnen keine Monster mehr auf allen Maps dieses Teilservers. TRAFFIC_PROFILE_ON: <- Wenn auf 1 gestellt, werden alle Packets geloggt. DISTRIBUTION_TEST_SERVER: <- Vereinfachter Modus. Zeit wird z.B. durch 3 dividiert und das testen insgesamt wird erleichtert. CHINA_EVENT_SERVER: <- Wenn auf 1 gestellt, wird vermutlich eine Art Fun-Server-Modus aktiviert. NO_WANDER: <- Mobs laufen nicht weit von ihrem Spawnpunkt weg. SKILL_DISABLE: <- Skills deaktiviert AUTH_SERVER: <- Deklariert den Server als Loginserver. QUEST_DIR: <- Gibt eine optionales Questverzeichnis statt /game/share_data/locale/hongkong/quest an. DEFAULT_QUEST_OBJECT_DIR: <- Gibt ein anderes vordefiniertes Verzeichnis statt Gibt eine optionales Questverzeichnis statt /game/share_data/locale/hongkong/quest/object an. QUEST_OBJECT_DIR: <- Gibt eine optionales Questverzeichnis statt /game/share_data/locale/hongkong/quest/object an.
Quests
Kommen wir nun zur Questprogrammierung. Dies ist ein sehr interessantes Thema, da zwar nicht jeder Server Quests braucht sie, aber dank ihnen wird das Spielerlebnis deutlich besser.
Für die Quests hat Ymir Entertainment eine eigene Sprache entwickelt und AARG genannt. Es ist eine Abwandlung von ArgScript, einer andern Questsprache. Beide basieren auf LUA. Also hilft es auch bei der Questprogrammierung wieder unter Sprache -> L -> Lua auszuwählen. So erkennt man wieder deutlich besser was wohin gehört.
Auch wenn die Quests in unserer Community bereits in sehr viele Tutorials Eingeflossen sind, trage ich hier nocheinmal mein Wissen zusammen.
Für die Quests gibt es bereits ca. 510 Funktionen (ihr findet sie in der /game/share/locale/hongkong/quest/quest_functions-Datei.
Diese sind teilweise nichteinmal alle benutzt, bieten aber genug Möglichkeiten für neue Quests.
Hier folgt nun ein grober Aufbau einer jeden Quest.
Ja Kenner haben die Erlaubnis rumzuheulen, es wäre nur ganz wenig, jedoch geht es hier um die Grundprinzipien und nicht um erweiterte Programmierung. (Heißt ja nich umsonst Teil 1)
Wer sich noch weiter für Quests schlau machen will, dem kann ich nur einen sehr Informativen Thread von Lolkid2009 empfehlen ()
Für die Quests hat Ymir Entertainment eine eigene Sprache entwickelt und AARG genannt. Es ist eine Abwandlung von ArgScript, einer andern Questsprache. Beide basieren auf LUA. Also hilft es auch bei der Questprogrammierung wieder unter Sprache -> L -> Lua auszuwählen. So erkennt man wieder deutlich besser was wohin gehört.
Auch wenn die Quests in unserer Community bereits in sehr viele Tutorials Eingeflossen sind, trage ich hier nocheinmal mein Wissen zusammen.
Für die Quests gibt es bereits ca. 510 Funktionen (ihr findet sie in der /game/share/locale/hongkong/quest/quest_functions-Datei.
Diese sind teilweise nichteinmal alle benutzt, bieten aber genug Möglichkeiten für neue Quests.
Hier folgt nun ein grober Aufbau einer jeden Quest.
Code:
quest questname begin -- Questbegin wird gekennzeichnet.
state status1 begin -- Begin eines neuen Zustandes wird gekennzeichnet
when levelup begin -- When-Schleife wartet auf das eintreten eines Ereignisses (Ereignis=LevelUp)
say("Test") -- Fenster mit dem Text Test öffnet sich.
end -- When-Schleife wird beendet.
end -- state status1 wird beendet.
end -- Quest wird beendet.
Wer sich noch weiter für Quests schlau machen will, dem kann ich nur einen sehr Informativen Thread von Lolkid2009 empfehlen (
)Datenbank
Das ändern der Datenbankinhalte bezeichne ich nicht Grundsätzlich als Programmieren, aber dennoch hat es Einwirkungen auf das Ingame-Erlebnis.
Grundsätzlich gibt es 3 Wichtige Datenbanken.
Das wäre einmal die Accountdatenbank, welche alle Accounts verwaltet und für den Login sowie einige Koordinationssachen verantwortlich ist.
Außerdem existiert noch die Playerdatenbank, welche alle wichtigen Inhalte für den Betrieb eures Server von Spielern über Gilden bis zu den Items enthält.
Und dann hätten wir da noch die Commondatenbank, welche neben der definierung der GM-IPs und der GMs eueres Servers auch eine Art Verbindung zwischen den Serverfiles und der Datenbank darstellt.
Grundsätzliches ändern an der Datenbank macht eigentlich nur beim aufsetzten eines Server Sinn. Danach sollte man Sachen wie Ingamebonis gleich bei der Anmeldung vergeben.
Hier eine kurze übersicht über die account.account Tabelle.
Zu erwähnen ist, dass alle Bonis der Accountdatenbank Sonderbonis sind und nicht Ingame erwerbbar.
Kommen wir zur Common-Datenbank.
Dort gibt es die gmhost-Tabelle mit der Spalte mIP. Dort müsst ihr die GM-IPs eintragen. Am besten macht sich jedoch ein Proxy, da die meisten Menschen IPs besitzen, die sich jeden Tag ändern.
Dann existiert da noch die gmlist-Tabelle
Außerdem existiert noch die locale-Tabelle die von Bedeutung ist.
Hab hier mal nur die wichtigen Reihen der locale-Tabelle aufgelistet. Die anderen solltet ihr besser nicht ändern.
Die 4. und letzte Tabelle in der Common-Datenbank Namens locale_bug, wird nicht benutzt.
Kommen wir zur letzten und wichtigsten Datenbank, der Player-Datenbank.
Sie beinhaltet die wichtigsten Daten für die Erstellung der virtuellen Metin2-Spielwelt.
Als erstes Liste ich die Tabellen auf und beschreibe Kurz ihren Inhalt und dann werde ich mich einigen Tabellen widmen.
Nun erkläre ich noch die einzelnen Spalten von folgenden Tabellen: item_attr, item_attr_rare, item_proto, mob_proto, object_proto, refine_proto, shop und shop_item
Also fangen wir an.
item_attr
item_attr_rare
item_proto
mob_proto
object_proto
refine_proto
shop
shop_item
Grundsätzlich gibt es 3 Wichtige Datenbanken.
Das wäre einmal die Accountdatenbank, welche alle Accounts verwaltet und für den Login sowie einige Koordinationssachen verantwortlich ist.
Außerdem existiert noch die Playerdatenbank, welche alle wichtigen Inhalte für den Betrieb eures Server von Spielern über Gilden bis zu den Items enthält.
Und dann hätten wir da noch die Commondatenbank, welche neben der definierung der GM-IPs und der GMs eueres Servers auch eine Art Verbindung zwischen den Serverfiles und der Datenbank darstellt.
Grundsätzliches ändern an der Datenbank macht eigentlich nur beim aufsetzten eines Server Sinn. Danach sollte man Sachen wie Ingamebonis gleich bei der Anmeldung vergeben.
Hier eine kurze übersicht über die account.account Tabelle.
Code:
id <- AccountID. Mit ihr werden später die Spielcharacktere ihren Accounts zugeordnet. login <- LoginID, Name denn man beim Login eingeben muss. password <- Passwort welches beim Login benötigt wird. real_name <- Name der Person (unter anderem für Sicherheitsabfragen oder zum persönlichen Ansprechen bei Newslettern gedacht) social_id <- SocialID ist eine Art Ausweisnummer in Korea email <- E-Mail Adresse des Accounts phone1 <- Telefonnummer 1 phone2 <- Telefonnummer 2 address <- Adresse zipcode <- Postleitzahl create_time <- Erstellungszeit des Accounts question1 <- Sicherheitsfrage Nummer 1 answer1 <- Antwort auf Sicherheitsfrage Nummer 1 question2 <- Sicherheitsfrage Nummer 2 answer2 <- Antwort auf Sicherheitsfrage Nummer 2 is_testor <- Testaccount Ja/Nein status <- Status des beim Login angezeigt werden kann. (Normal ist OK, es gehen aber auch sachen wie MAIL oder BLOCK) securitycode <- Löschcode newsletter <- Newsletterempfangen Ja/Nein empire <- Zugehörigkeit des Accounts zu einem bestimmten Reich (Nicht genutzt) name_checked <- Ungenutzt & Unbekannt availDt <- Zeit bis der Account verfügbar ist. mileage <- Drachenmarken cash <- Drachenmünzen gold_expire <- Zeitpunkt bis zu dem Yangdrop erhöt ist. silver_expire <- Unbekannt safebox_expire <- Zeitpunkt bis zu dem die Größe der Safebox auf 3 ist. autoloot_expire <- Zeitpunkt bis zu dem 3. Hand vom Server aus wirkt. fish_mind_expire <- Zeitpunkt bis zu dem Fichbonus wirkt. marriage_fast_expire <- Zeitpunkt bis zu dem Hochzeitbonus wirkt. money_drop_rate_expire <- Zeitpunkt bis zu dem Doppeldrop wirkt. ttl_cash <- Gültigkeitszeitraum der Drachenmünzen im YMir-Shopscript ttl_mileage <- Gültigkeitszeitraum der Drachenmarken im YMir-Shopscript channel_company <- Ungenutzt & Unbekannt
Kommen wir zur Common-Datenbank.
Dort gibt es die gmhost-Tabelle mit der Spalte mIP. Dort müsst ihr die GM-IPs eintragen. Am besten macht sich jedoch ein Proxy, da die meisten Menschen IPs besitzen, die sich jeden Tag ändern.
Dann existiert da noch die gmlist-Tabelle
Code:
mID <- ID für die Rechtevergabe (muss weder Account, noch PlayerID des GMs sein) mAccount <- Accountname des GMs mName <- Charname des GMs mContactIP <- KontaktIP des GMs (Buggy, bzw. Unbekannt How to Use) mServerIP <- Zuständigkeitsbereich für GM (Falls nur eine Common-Datenbank für mehrere Server benutzt wird) mAuthority <- Macht des GMs (IMPLEMENTOR = Herrscher = Alle Rechte, GOD = Gott = Hat die wichtigsten Rechte, kann aber keine Servertechnischen Sachen machen, HIGH_WIZARD = Hoher Zauberer = Ähnliche Rechte wie GOD, jedoch keine zum erstellen von Items, LOW_WIZARD = Typische Trial oder GM Rechte, PLAYER = normale Rechte (keine Commands))
Code:
LOCALE <- Hier müsst ihr den Localenamen eingeben den der Server laden soll (game/share_data/locale/EINGEGEBENER NAME/) DB_NAME_COLUMN <- Definiert die Namensspalte für NPCs auf eurem Server. Könntet also auch nur name schreiben. Aber die Voreinstellung ist auch hier sinnvoll getätigt.
Die 4. und letzte Tabelle in der Common-Datenbank Namens locale_bug, wird nicht benutzt.
Kommen wir zur letzten und wichtigsten Datenbank, der Player-Datenbank.
Sie beinhaltet die wichtigsten Daten für die Erstellung der virtuellen Metin2-Spielwelt.
Als erstes Liste ich die Tabellen auf und beschreibe Kurz ihren Inhalt und dann werde ich mich einigen Tabellen widmen.
Code:
affect <- Affect-Tabelle enthält alle Statuswerte (Tag/Nacht, Sichtbar/Unsichtbar usw.) banword <- Hier Wörter eintragen die der Server automatisch zu ****** macht. (Anti-Beleidigung) guild <- Enthält wichtige Daten zu Gilden wie Name, Level und Gründer. guild_comment <- Tabelle die alle Kommentare der Gilden enthält. guild_grade <- Enthält alle Ränge der einzelnen Gilden. (Co-Leader und selbsterstellte) guild_member <- Enthält alle Informationen über Gildenmitglieder guild_war <- Speichert jeglich Gildenkriegsanfragen. guild_war_bet <- Enthält alle Informationen über Wetten auf Gildenkriege. guild_war_reservation <- Speichert alle Informationen über ausgefochtene Gildekriege. highscore <- Unbenutzt, wahrscheinlich für die Rangliste auf der HP gewesen. item <- Enthält alle Items mit Werten, Steinen, IDs und ihren Besitzern. item_attr <- Die mögichen Werte für den 1. bis zum 5. Bonus werden in dieser Tabelle festgelegt. item_attr_rare <- Die mögichen Werte für den 6. und 7. Bonus werden in dieser Tabelle festgelegt. item_award <- Hier einfach per Shopscript gekaufte Items eintragen und sie werden den Spielern ins Shoplager gepackt. Es ist sogar eine Speicherfunktion enthalten, also werden Items die zuviel gekauft werden (wenn kein Platz mehr im Lager ist) nicht gelöscht sondern rücken mit der Zeit auf. item_proto <- Enthält alle Informationen über die Standardwerte der Waffen. item_proto_shop <- Ursprünglich für den ItemShop auf der Webseite gedacht. land <- Enthält alle Gildenländer und Informationen ob sie aktiviert sind oder nicht. marriage <- Verheiratet Characktere sind hier eingetragen. messenger_list <- Hier werden alle Messengerkontakte eingetragen. mob_proto <- Enthält jegliche Infos über Portale, NPCs und Monster. monarch <- Hier werden die Monarchen eingetragen. monarch_candidacy <- Hier wird eingetragen wer für das Monarchenamt kanidiert hat. monarch_election <- Hier wird geloggt wer wen gewählt hat. myshop_pricelist <- Preisliste vom Privaten Laden wird hier zwischengespeichert. object <- Gekaufte Häuser, Steine und Bäume der Gilden werden hier eingetragen. object_proto <- Hier werden alle möglichen Gebäude usw. die Gilden bauen können eingetragen mit den Preisen usw. pcbang_ip <- Hier IPs eintragen die vom Server geblockt werden sollen. player <- Hier sind alle Daten über die Spieler eingetragen. player_deleted <- Hier werden gelöschte Spieler eingetragen, so dass man sie Notfalls retten könnte. player_index <- Hier werden die Spieler eingetragen die zusammengehören und eine Account und einem Reich zugeordnet. quest <- Hier werden alle Queststatusse eingetragen. refine_proto <- Hier stehen alle Daten um Waffen zu uppen. Also die benötigten Items, die Rate wie es gelingt und so weiter. safebox <- Hier werden die Lagerdaten eingetragen. Das wären Passwort und Größe. shop <- Hier werden den NPCs die Läden zugeordnet. shop_class <- Ursprünglich wurde dies wahrscheinlich genutzt um Items im Itemshop in verschiedene Klassen zu unterteilen. (Ungenutzt) shop_item <- Hier werden den Shops die Items zugeordnet, sowie Anzahl und die Position. Zu beachten ist, dass hier nicht die VNum vom NPC sondern die VNum die in der shop-Tabelle eingestellt wurde angegeben werden muss. skill_proto <- Hier werden den Skills die Werte zugeordnet. sms_pool <- Hier werden alle verschickten SMS geloggt. string <- Scheint eventuell eine Art Auto-Nachricht zu sein (Wie bei .DE, dass GMs nie nach Passwort fragen etc.). Bin mir aber auch nicht ganz sicher und es ist untested.
Also fangen wir an.
item_attr
Code:
apply <- Wirkung die der Bonus verursacht. Möglich sind: MAX_HP, MAX_SP, CON, INT, STR, DEX, ATT_SPEED, MOV_SPEED, CAST_SPEED, HP_REGEN, SP_REGEN, POISON_PCT, STUN_PCT, SLOW_PCT, CRITICAL_PCT, PENETRATE_PCT, ATTBONUS_HUMAN, ATTBONUS_ANIMAL, ATTBONUS_ORC, ATTBONUS_MILGYO, ATTBONUS_UNDEAD, ATTBONUS_DEVIL, STEAL_HP, STEAL_SP, MANA_BURN_PCT, DAMAGE_SP_RECOVER, BLOCK, DODGE, RESIST_SWORD, RESIST_TWOHAND, RESIST_DAGGER, RESIST_BELL, RESIST_FAN, RESIST_BOW, RESIST_FIRE, RESIST_ELEC, RESIST_MAGIC, RESIST_WIND, REFLECT_MELEE, REFLECT_CURSE, POISON_REDUCE, KILL_SP_RECOVER, EXP_DOUBLE_BONUS, GOLD_DOUBLE_BONUS, ITEM_DROP_BONUS, POTION_BONUS, KILL_HP_RECOVER, IMMUNE_STUN, IMMUNE_SLOW, IMMUNE_FALL, SKILL, BOW_DISTANCE, ATT_GRADE_BONUS, DEF_GRADE_BONUS, MAGIC_ATT_GRADE, MAGIC_DEF_GRADE, CURSE_PCT, MAX_STAMINA prob <- Wahrscheinlichkeit in Prozent den entsprechenden Bonus zu erhalten. lv1 <- Stufe 1 des Bonus. lv2 <- Stufe 2 des Bonus. lv3 <- Stufe 3 des Bonus. lv4 <- Stufe 4 des Bonus. lv5 <- Stufe 5 des Bonus. weapon <- Auf 1-5 Stellen damit die entsprechenden Level des Bonus auf die Waffe kommen können. Wenn 1 eingestellt ist, erscheint also immer nur die 1. Stufe. body <- Auf 1-5 Stellen damit die entsprechenden Level des Bonus auf die Rüstung kommen können. wrist <- Auf 1-5 Stellen damit die entsprechenden Level des Bonus auf das Armband kommen können. foots <- Auf 1-5 Stellen damit die entsprechenden Level des Bonus auf die Schuhe kommen können. neck <- Auf 1-5 Stellen damit die entsprechenden Level des Bonus auf die Halskette kommen können. head <- Auf 1-5 Stellen damit die entsprechenden Level des Bonus auf den Helm kommen können. shield <- Auf 1-5 Stellen damit die entsprechenden Level des Bonus auf das Schild kommen können. ear <- Auf 1-5 Stellen damit die entsprechenden Level des Bonus auf die Ohrringe kommen können.
Code:
apply <- Wirkung die der Bonus verursacht. Möglich sind: MAX_HP, MAX_SP, CON, INT, STR, DEX, ATT_SPEED, MOV_SPEED, CAST_SPEED, HP_REGEN, SP_REGEN, POISON_PCT, STUN_PCT, SLOW_PCT, CRITICAL_PCT, PENETRATE_PCT, ATTBONUS_HUMAN, ATTBONUS_ANIMAL, ATTBONUS_ORC, ATTBONUS_MILGYO, ATTBONUS_UNDEAD, ATTBONUS_DEVIL, STEAL_HP, STEAL_SP, MANA_BURN_PCT, DAMAGE_SP_RECOVER, BLOCK, DODGE, RESIST_SWORD, RESIST_TWOHAND, RESIST_DAGGER, RESIST_BELL, RESIST_FAN, RESIST_BOW, RESIST_FIRE, RESIST_ELEC, RESIST_MAGIC, RESIST_WIND, REFLECT_MELEE, REFLECT_CURSE, POISON_REDUCE, KILL_SP_RECOVER, EXP_DOUBLE_BONUS, GOLD_DOUBLE_BONUS, ITEM_DROP_BONUS, POTION_BONUS, KILL_HP_RECOVER, IMMUNE_STUN, IMMUNE_SLOW, IMMUNE_FALL, SKILL, BOW_DISTANCE, ATT_GRADE_BONUS, DEF_GRADE_BONUS, MAGIC_ATT_GRADE, MAGIC_DEF_GRADE, CURSE_PCT, MAX_STAMINA, ATT_BONUS_TO_WARRIOR, ATT_BONUS_TO_ASSASSIN, ATT_BONUS_TO_SURA, ATT_BONUS_TO_SHAMAN, ATT_BONUS_TO_MONSTER, NORMAL_HIT_DEFEND_BONUS, SKILL_DEFEND_BONUS, NOUSE2NOUSE3, NOUSE4, NOUSE5, NOUSE6, NOUSE7, NOUSE8, NOUSE9, NOUSE10, NOUSE11, NOUSE12, NOUSE13, NOUSE14, RESIST_WARRIOR, RESIST_ASSASSIN, RESIST_SURA, RESIST_SHAMAN prob <- Wahrscheinlichkeit in Prozent den entsprechenden Bonus zu erhalten. lv1 <- Stufe 1 des Bonus. lv2 <- Stufe 2 des Bonus. lv3 <- Stufe 3 des Bonus. lv4 <- Stufe 4 des Bonus. lv5 <- Stufe 5 des Bonus. weapon <- Auf 1-5 Stellen damit die entsprechenden Level des Bonus auf die Waffe kommen können. Wenn 1 eingestellt ist, erscheint also immer nur die 1. Stufe. body <- Auf 1-5 Stellen damit die entsprechenden Level des Bonus auf die Rüstung kommen können. wrist <- Auf 1-5 Stellen damit die entsprechenden Level des Bonus auf das Armband kommen können. foots <- Auf 1-5 Stellen damit die entsprechenden Level des Bonus auf die Schuhe kommen können. neck <- Auf 1-5 Stellen damit die entsprechenden Level des Bonus auf die Halskette kommen können. head <- Auf 1-5 Stellen damit die entsprechenden Level des Bonus auf den Helm kommen können. shield <- Auf 1-5 Stellen damit die entsprechenden Level des Bonus auf das Schild kommen können. ear <- Auf 1-5 Stellen damit die entsprechenden Level des Bonus auf die Ohrringe kommen können.
Code:
vnum <- Virtuelle Nummer des Items. name <- Name des Items. gb2312name <- Name des Items im gb2312-Format. type <- Typ des Items. subtype <- Subtyp des Items. weight <- Gewicht des Items (Ungenutzt). size <- Größe des Items. (Feldergröße) antiflag <- Benutzung bei bestimmten Eigenschaften verbieten. Möglich sind: ITEM_ANTIFLAG_FEMALE, 1 ITEM_ANTIFLAG_MALE, 2 ITEM_ANTIFLAG_WARRIOR, 4 ITEM_ANTIFLAG_ASSASSIN, 8 ITEM_ANTIFLAG_SURA, 16 ITEM_ANTIFLAG_SHAMAN, 32 ITEM_ANTIFLAG_GET, 64 ITEM_ANTIFLAG_DROP, 128 ITEM_ANTIFLAG_SELL, 256 ITEM_ANTIFLAG_EMPIRE_A, 512 ITEM_ANTIFLAG_EMPIRE_B, 1024 ITEM_ANTIFLAG_EMPIRE_R, 2048 ITEM_ANTIFLAG_SAVE, 4096 ITEM_ANTIFLAG_GIVE, 8192 ITEM_ANTIFLAG_PKDROP, 16384 ITEM_ANTIFLAG_STACK, 32768 ITEM_ANTIFLAG_MYSHOP, 65536 Wenn ihr mehrere einstellen wollt, so müsst ihr die Werte einfach zusammenrechnen. Wenn also das Item nur für Weiblein nutzbar sein soll die Schamanen sind müsst ihr Rechnen, Nicht-Männlich+Nicht-Krieger+Nicht-Sura+Nicht-Ninja == 2 + 4 + 8 + 16 = 30 flag <- Besondere Eigenschaften. Möglich sind: ITEM_FLAG_RARE, 32 ITEM_FLAG_UNIQUE, 64 ITEM_FLAG_CONFIRM_WHEN_USE, 512 Jedoch muss ich hier zugeben, dass ich mir nicht ganz sicher bin. Es könnte auch einfach eine umkehrung von Antiflag sein. wearflag <- Begrenzung der Tragbarkeit des Items. Folgende Werte sind möglich: WEARABLE_BODY, 1 WEARABLE_HEAD, 2 WEARABLE_FOOTS, 4 WEARABLE_WRIST, 8 WEARABLE_WEAPON, 16 WEARABLE_NECK, 32 WEARABLE_EAR, 64 WEARABLE_UNIQUE, 128 WEARABLE_SHIELD, 256 WEARABLE_ARROW, 512 Achtung, nicht zusammenzählen! immuneflag <- Wenn die Person das Item trägt erhält sie einen Immunitätsbonus. Folgende sind möglich: PARA, CURSE, STUN, SLEEP, SLOW, POISON, TERROR gold <- Yang das man beim verkaufen erhält. shop_buy_price <- Preis des Items im Laden. refined_vnum <- VNum zu der das Item wird, wenn man es verbessert (uppt). refine_set <- Benötigtes Item 1 zum verbessern. refine_set2 <- Benötigtes Item 2 zum verbessern. magic_pct <- Unbekannt. Wahrscheinlich eine Art FKS-Erhöhung um einen bestimmten Prozentsatz. limittype0 <- Nutzungsbediengung Nummer 1 (idr. auch Zahl 1 für Level) limitvalue0 <- Zahl die erfüllt werden muss. (Bei einer Rüstung ab Level 80 muss also die Zahl 80 eingetragen werden.) limittype1 <- Nutzungsbediengung Nummer 2 (noch nie vergeben) limitvalue1 <- Selbes wie bei limitvalue0, aber wie gesagt noch nie benutzt. applytype0 <- Festgelegter Bonus Nummer 1 applyvalue0 <- Wert des festgelegten Bonus Nummer 1 (idr. Angriffsgeschwindigkeit) applytype1 <- Festgelegter Bonus Nummer 2 applyvalue1 <- Wert des festgelegten Bonus Nummer 2 applytype2 <- Festgelegter Bonus Nummer 3 applyvalue2 <- Wert des festgelegten Bonus Nummer 3 value0 <- Unbekannt, eventuell die Zeit, die das Item erhlaten bleibt bevor es sich auflöst. Also wie bei IS-Items. value1 <- Minimaler Magischer Angriffswert. value2 <- Maximaler Magischer Angriffswert. value3 <- Minimaler Angriffswert. value4 <- Maximaler Angriffswert. value5 <- Unbekannt. socket0 <- Unbekannt/Ungenutzt. socket1 <- Unbekannt/Ungenutzt. socket2 <- Unbekannt/Ungenutzt. socket3 <- Unbekannt/Ungenutzt. socket4 <- Unbekannt/Ungenutzt. socket5 <- Unbekannt/Ungenutzt. specular <- Glitzerwert der Waffe in Prozent. socket_pct <- Anzahl der Plätze um Steine einzufügen. addon_type <- Unbekannt/Ungenutzt.
Code:
vnum <- name <- Mobname (wichtig für NPCs, da deren Name vom Server definiert wird) rank <- Stufe des Monsters type <- Typ des Monster (1 = NPC, 2 Metin, 3 = Warp-Portal, 4 = Tor, 5 = Gildengebäude, 9 = Go-Portal) battle_type <- 1 - 5 für Radius und Hartnäckigkeit. (Portale, Gildengebäude und Metins = 3) level <- Level des Monsters. Darus resultiert die Menge an Erfahrung die ein Spieler erhält, wenn er das monster tötet. size <- Größe, möglich sind: SMALL, MEDIUM, BIG ai_flag <- Kampfverhalten des Monsters. Mehrere wählbar. Möglich sind: AGGR, NOMOVE, COWARD, NOATTSHINSU, NOATTCHUNJO, NOATTJINNO, ATTMOB, BERSERK, STONESKIN, GODSPEED, DEATHBLOW, REVIVE mount_capacity <- Reit Kapazität? Weiß nicht genau. Eventuell auch eine Möglichkeit Monster oder NPCs zu Reittieren zu machen. setRaceFlag <- Rasse des Monsters. Möglich sind: ANIMAL, UNDEAD, DEVIL, HUMAN, ORC, MILGYO, INSECT, FIRE, ICE, DESERT setImmuneFlag <- Immunität gegen negative Effekte. Möglich sind: STUN, SLOW, FALL, CURSE, POISON, TERROR empire <- Zugehörigkeit des Monsters bzw. des NPCs zu einem bestimmten Reich. folder <- Ordner in dem die .gr2 Dateien und Animationen des Monsters Serverside sind. on_click <- Handlung, die beim anklicken durchgeführt werden soll. (2 = Ansprechen, 1 = Laden) st <- Stärke des Monsters. (Entscheidend für den Schaden) dx <- Verteidigung des Monsters. (Entscheidend für die Defensive) ht <- Leben des Monsters. (HealtPoints) iq <- Manapunkt des Monsters. damage_min <- Minimaler Schaden des Monsters. damage_max <- Maximaler Schaden des Monsters. max_hp <- Maximale Lebenspunkte des Monsters. regen_cycle <- Respawnzeit in Minuten. regen_percent <- Respawnzeit bei Purge. gold_min <- Minimaler Yangdrop gold_max <- Maximaler Yangdrop exp <- Erfahrung die der Mob abgibt. def <- Verteidigung attack_speed <- Angriffsgeschwindigkeit move_speed <- Bewegungsgeschwindigkeit aggressive_hp_pct <- weiß ich nicht genau, aber wahrscheinlich eine Art Gnade. D.h. das der Spieler nur angegriffen wird wenn er mehr HP hat als dort angegeben. Aber nicht bestätigt. (Könnte auch andersrum sein, also dass der Mob niemanden angreift wenn er zu wenig HP hat.) aggressive_sight <- Agressivitätsreichweite attack_range <- Schlagweite. drop_item <- Item, welches das Monster definitv dropt. resurrection_vnum <- Das hier eingetragene Monster wird gespawnt, wenn dieses stirbt. (Zu beachten ist hier, VNUM angeben, nicht den Namen) enchant_curse <- Chance Fluch zu übertragen (keine Ahnung was das ist o.O) enchant_slow <- Chance zu Verlangsamen in Prozent. enchant_poison <- Chance zu Vergiften in Prozent. enchant_stun <- Chance zu Betäuben in Prozent. enchant_critical <- Chance einen kritischen Treffer zu landen in Prozent. enchant_penetrate <- Chance einen durchbohrenden Treffer zu landen in Prozent. resist_sword <- Verteidigung gegen Schwertschaden in Prozent. resist_twohand <- Verteidigung gegen 2Hand-Waffenschaden in Prozent. resist_dagger <- Verteidigung gegen Dolche in Prozent. resist_bell <- Verteidigung gegen Glocken in Prozent. resist_fan <- Verteidigung gegen Fächer in Prozent. resist_bow <- Verteidigung gegen Bögen in Prozent. resist_fire <- Verteidigung gegen Feuer(brennen) in Prozent. resist_elect <- Verteidigung gegen Elektrizität in Prozent. (Noch nirgendswo eingebaut!) resist_magic <- Verteidigung gegen Fertigkeitsschaden in Prozent. resist_wind <- Verteidigung gegen Wind in Prozent. resist_poison <- Verteidigung gegen Gift in Prozent. dam_multiply <- Eine Art Multiplikator. Ich weiß aber nicht so richtig für was. Erhöht jedoch deutlich die schwierigkeit. In der Regel ist es bei 1 oder 1,4. Bei Bossen auch mal etwas höher. summon <- Hier eingetragene Monster werden vom Monster gespawnt. (Nützlich bei Bossen. Zu beachten ist auch hier, VNUM angeben, nicht den Namen) drain_sp <- Mana Klauen in Prozent. mob_color <- Farbe des Monsters. Farbe um zum Beispiel Alpha- und nicht Alpha-Blauwölfe auseinderzuhalten. polymorph_item <- Verwandlungskugelart. skill_level0 <- Skillstufe von skill_vnum0. (0-59 wie bei normalen Spielerskills auch) skill_vnum0 <- Skill 1 (Jeder Skill eintragbar) skill_level1 <- Skillstufe von skill_vnum1. skill_vnum1 <- Skill 2 sp_berserk <- Berserker-Ausdauer sp_stoneskin <- Steinhaut-Ausdauer sp_godspeed <- Göttliche Geschwindigkeit Ausdauer sp_deathblow <- Todesstoß Ausdauer (Hat nur Wasserdrache) sp_revive <- Ausdauer für Wiederbelebung von durch das Monster gespawnte Monster.
Code:
vnum <- Vnum des Gebäudes. name <- Name des Gebäudes der angezeigt werden soll. price <- Kosten zum bauen. materials <- Benötigte Materialien zum bauen. upgrade_vnum <- Gebäude kann zu der hier eingetragenen aufgewertet werden. upgrade_limit_time <- Begrenzung der aufwertungen in einem Bestimmten Zeitraum. (Wartezeit) life <- Unbenutzt/Unbekannt reg_1 <- Unbenutzt/Unbekannt reg_2 <- Unbenutzt/Unbekannt reg_3 <- Unbenutzt/Unbekannt reg_4 <- Unbenutzt/Unbekannt npc <- NPC der zu dem Objekt gehört. group_vnum <- Zugehörigkeitsgruppe (Wahrscheinlich eine Art Typ) dependent_groups <- Anhängigkeitsgruppen?!
Code:
id <- ID (Unwichtig, aber nicht mehrmals die selbe vergeben) cat <- Unbekannt (Ungenutzt?) vnum0 <- Vnum des 1. benötigten Items count0 <- Anzahl des 1. benötigten Items. vnum1 <- Vnum des 2. benötigten Items count1 <- Anzahl des 2. benötigten Items. vnum2 <- Vnum des 3. benötigten Items count2 <- Anzahl des 3. benötigten Items. vnum3 <- Vnum des 4. benötigten Items count3 <- Anzahl des 4. benötigten Items. vnum4 <- Vnum des 5. benötigten Items count4 <- Anzahl des 5. benötigten Items. cost <- Benötigtes Yang. src_vnum <- Vnum des Items, welches geuppt werden soll. result_vnum <- Vnum des Items, welches entstehen soll. prob <- Wahrscheinlichkeit, dass das Item verbessert wird in Prozent.
Code:
vnum <- Hier die Vnum eintragen, welcher später die Items zum verkaufen zugeordnet werden soll. name <- Name des Ladens (Ungenutzt und nur zur besseren Übersicht) npc_vnum <- Vnum des NPCs bei dem der Shop erscheinen soll.
Code:
shop_vnum <- Hier die shop.vnum eintragen. item_vnum <- Hier die Itemvnum eintragen die der Laden verkaufen soll. count <- Anzahl der Items (Wv Items gestappelt sein sollen) order <- Position des Items im Shop.
Was macht Sinn es zu ändern?
Serverside Sachen zu ändern mach generell viel Sinn. Denn ohne jegliche Änderungen an den Files, Quests etc. wird dein Server nicht einzigartig. So wird er zu einer Flaute und als 0815-Server mit 10 Spielern abgestempelt. Um deinen Server einzigartig zu machen, ist zwar jede Menge Arbeit nötig, aber es lohnt sich.
Kommen wir aber zum Hauptpunkt dieses Themas.
Was macht Sinn?
Diese Frage ist recht schwer zu beantworten, da jeder von euch ein anderes Serverkonzept anstrebt.
Grundsätzliche Sachen, wie die übersetzung von Questfiles nehme ich mal für selbstverständlich, aber in meinen Augen machen auch Sachen wie die Änderung der Config Dateien, das Hinzufügen neuer Quests und die bearbeitung der Datenbank Sinn. Aber man sollte nie aus dem von YMir vorgegebenen Rahmen springen, da sie sich beim Verhältnis der Exp-Rate zu Drop- und Yangrate durchaus was gedacht haben.
Also lange Rede kurzer Sinn: Kleinigkeiten verbessern & neue Sachen hinzufügen, aber keine festen Rahmen sprengen.
Kommen wir aber zum Hauptpunkt dieses Themas.
Was macht Sinn?
Diese Frage ist recht schwer zu beantworten, da jeder von euch ein anderes Serverkonzept anstrebt.
Grundsätzliche Sachen, wie die übersetzung von Questfiles nehme ich mal für selbstverständlich, aber in meinen Augen machen auch Sachen wie die Änderung der Config Dateien, das Hinzufügen neuer Quests und die bearbeitung der Datenbank Sinn. Aber man sollte nie aus dem von YMir vorgegebenen Rahmen springen, da sie sich beim Verhältnis der Exp-Rate zu Drop- und Yangrate durchaus was gedacht haben.
Also lange Rede kurzer Sinn: Kleinigkeiten verbessern & neue Sachen hinzufügen, aber keine festen Rahmen sprengen.
Was ist möglich, was nicht?
Serverside ist zwar nicht so viel Möglich wie Clientseitig, aber dafür fallen dort die Änderungen schwerer ins Gewicht.
Grundsätzlich möglich sind die Veränderung von Texten und Werten wie zum Beispiel der Benötigten Exp pro Level.
Grundsätzlich möglich sind die Veränderung von Texten und Werten wie zum Beispiel der Benötigten Exp pro Level.
C Schlusswort
So Leute. Wer bis hierhin gelesen hat (oh es gibt wirklich jemanden der es gemacht hat o.ô), der hat sich erfolgreich durch den 1. Teil meiner Tutorialreihe gelesen bei der ich noch nicht weiß ob, wann und wie ich sie fortsetzte. Je nachdem wie die Community darauf reagiert, werde ich mich entscheiden.
Ich hoffe ich konte euch bei den Grundsätzen der Server- und Clientprogrammierung ein bisschen auf die Sprünge helfen und euch vielleicht ein paar neue Möglichkeiten nennen, bzw. euch eventuell sogar ein bisschen fürs Programmieren begeistern.
Puh 42.000 Zeichen scheiße war das aufwendig
Und Jetzt ist Schluss für diesen Post.
Mit freundlich grüßen,
Tanhel
PS: 1300 Posts und 600 Thanks xD
):
