MG Mud User | 88f1247 | 2016-06-24 23:31:02 +0200 | [diff] [blame^] | 1 | General Mud Communication Protocol im MorgenGrauen |
| 2 | ================================================== |
| 3 | |
| 4 | 0. Einleitung |
| 5 | GMCP wird benutzt, um Daten zwischen MUD und Client "out of band" zu |
| 6 | uebertragen. "Out of band" bedeutet hier, dass der Datenaustausch hinter |
| 7 | den Kulissen passiert statt in der normalen textuellen Spielausgabe, |
| 8 | welcher vom Client mittels mehr oder weniger komplizierter Trigger |
| 9 | ausgewertet werden muss. |
| 10 | |
| 11 | Vorteile: |
| 12 | * keine komplexen Trigger (Regexps) mehr. |
| 13 | * Daten werden in einem definierten Format uebertragen, welches der Client |
| 14 | fuer euch interpretiert. |
| 15 | * keine Gagtrigger mehr noetig, um empfangenen Text auszublenden |
| 16 | * keine stoerenden Ausgaben, falls man diese Gagtrigger nicht hat. |
| 17 | * Daten koennen auch uebertragen werden in Situationen, in denen eine |
| 18 | normale Textausgabe nicht so gut geht, z.B. in Editoren. |
| 19 | * Daten, die die Clientscripte nicht verarbeiten, stoeren nicht den |
| 20 | Textfluss. |
| 21 | * Der Client kann konfigurieren, welche Informationen er bekommen will. |
| 22 | * Im MG ist neben Dingen wie LP und KP die Uebertragung div. anderer Dinge |
| 23 | geplant, vor allem andere Informationen ueber den Char oder den Raum |
| 24 | (z.B. eindeutige Raum-IDs (in den meisten Faellen)). |
| 25 | |
| 26 | |
| 27 | 1. Unterstuetzte Module |
| 28 | |
| 29 | 1.1. Core (aus IRE (Iron Realms Entertainment) MUDs) |
| 30 | Das Core Modul ist immer aktiv. Es verwaltet die grundsaetzlichen |
| 31 | Einstellungen von GMCP. Die MG-Variante ist fast identisch zur IRE-Variante, |
| 32 | hat allerdings zusaetzliche das "Debug"-Kommando. |
| 33 | |
| 34 | Vom Client gesendet: |
| 35 | - Core.Hello |
| 36 | Muss die erste Nachricht sein, welche der Client nach Aktivierung von |
| 37 | GMCP sendet. |
| 38 | Die Daten sind ein Objekt mit den Schluesseln "client" und "version", |
| 39 | welche entsprechend den Clientnamen und seine Versionskennung |
| 40 | enthalten. |
| 41 | Core.Hello { "client": "Nexus", "version": "3.1.90" } |
| 42 | - Core.Supports.Set |
| 43 | Informiert das MUD ueber die Pakete/Module, die der Client |
| 44 | unterstuetzt, d.h. die der Client empfangen kann. Es ist immer noch |
| 45 | Entscheidung des Muds, welche dieser Module ihre Daten senden (z.B. |
| 46 | wird MG einem "MG.char" den Vorzug geben vor einem generischen "Char", |
| 47 | falls vom Client beide unterstuetzt werden. |
| 48 | Wenn bereits vorher ein Core.Supports.* Kommando empfangen wurde, wird |
| 49 | die Liste der unterstuetzten Module durch die neue ersetzt. |
| 50 | Daten sind ein Array von Strings, welche jeweils den Modulnamen und |
| 51 | die Versionsnummer angeben (mit einem Leerzeichen getrennt). |
| 52 | Die Versionsnummer muss eine positive Ganzzahl sein. |
| 53 | Die meisten Clients werden Set nur einmal am Anfang senden und |
| 54 | brauchen kein Add/Remove. |
| 55 | Core.Supports.Set [ "MG.char 1", "MG.room 1" ] |
| 56 | - Core.Supports.Add |
| 57 | aehnlich zu Set, aber es fuegt die angegeben Module an die in der |
| 58 | Vergangenheit uebermittelten an. |
| 59 | Wenn noch keine Liste gesendet wurde, ist das Ergebnis wie bei Set. |
| 60 | Wenn die Liste Module enthaelt, die bereits aktiv sind, wird die neue |
| 61 | Versionsnummer Prioritaet vor der alten haben, selbst wenn die kleiner |
| 62 | ist. |
| 63 | Die Daten sind identisch zu Set. |
| 64 | - Core.Supports.Remove |
| 65 | Entfernt die angebenen Module aus der Liste der unterstuetzen Module. |
| 66 | Die Daten sind identisch zu Set. Die Modulversionen sind NICHT |
| 67 | optional (anders als bei IRE). Allerdings werden auch Module anderer |
| 68 | Version abgeschaltet. (Insofern koennte man - zur Zeit - einfach immer 1 |
| 69 | als Versionsnummer senden.) |
| 70 | - Core.KeepAlive |
| 71 | Vom MG ignoriert, weil Verbindungen nicht automatisch getrennt werden. |
| 72 | - Core.Ping |
| 73 | Veranlasst das MG mit einem Core.Ping zu antworten. |
| 74 | Die Daten ist eine Ganzzahl, welche die durchschnittliche Pingzeit |
| 75 | aus verherigen Pings enthaelt, falls verfuegbar. |
| 76 | (Anmerkung: IRE macht keine Angabe ueber die Einheit dieser Zahl. MG |
| 77 | geht von Millisekunden aus.) |
| 78 | Core.Ping 120 |
| 79 | - Core.Debug |
| 80 | Kann gesendet werden, um die Ausgabe von menschenlesbaren |
| 81 | Debugmeldungen vom GMCP zu aktivieren. |
| 82 | Die Daten sind eine Ganzzahl. Je groesser, desto mehr Debugmeldungen |
| 83 | werden ausgegeben. |
| 84 | 0 schaltet die Debugmeldungen aus. |
| 85 | 1 schaltet nur die Ausgabe von GMCP-Fehlern an. |
| 86 | 100 schaltet alles an. |
| 87 | Core.Debug 1 |
| 88 | Vom Server gesendet: |
| 89 | - Core.Ping |
| 90 | Als Antwort eines vom Client empfangenen Core.Ping gesendet. |
| 91 | Keine Daten. |
| 92 | - Core.Goodbye [NOT IMPLEMENTED YET!] |
| 93 | Gesendet vom MUD unmittelbar vor Verbindungstrennung. |
| 94 | Die Daten sind eine Nachricht (string), welche dem User angezeigt |
| 95 | werden kann und koennen den Grund fuer den Disconnect erklaeren. |
| 96 | Core.Goodbye "Goodbye, adventurer" |
| 97 | |
| 98 | 1.2. MG.char 1 (angelehnt an Aardwolf, aber modifiziert) |
| 99 | Die Uebertragung der Kommandos in diesem Modul wird aktiviert, wenn |
| 100 | "MG.char" aktiv ist. Es gibt keine Submodule, die getrennt aktiviert werden |
| 101 | muessten. Die jeweiligen Kommandos werden gesendet, wenn sich eins der |
| 102 | gesendeten Daten aendert. |
| 103 | Alle Kommandos werden einmal bei Modulaktivierung gesendet (auch wenn ein |
| 104 | Modul durch ein Core.Supports.Set (erneut) aktiviert wird). |
| 105 | Ist dieses Modul vom Client unterstuetzt, werden keine Daten aus den |
| 106 | Modulen "Char" und "char" gesendet. |
| 107 | (Spieler aelter als 12.05.2013 muessen einmalig den textuellen Report mit |
| 108 | "report ein" und "report vorsicht" einschalten, damit die Uebertragung |
| 109 | via GMCP freigeschaltet wird. Der Report kann danach wieder |
| 110 | ausgeschaltet werden.) |
| 111 | |
| 112 | 1.2.2. MG.char.base |
| 113 | Vom Server gesendet: |
| 114 | - MG.char.base |
| 115 | Einige grundlegende Eigenschaften des Chars, die sich selten aendern. |
| 116 | Ein "wizlevel" von 1 zeigt an, dass der Char ein Seher ist. |
| 117 | Der "title" kann am Anfang ein Backspace "\b" gefolgt von "," oder "'" |
| 118 | enthalten. |
| 119 | MG.char.base { "name": "Jof", "guild": "Abenteurer", |
| 120 | "race": "Elf", "presay": "Mudgott", |
| 121 | "title": "idlet.", "wizlevel": 101 } |
| 122 | |
| 123 | 1.2.3. MG.char.vitals |
| 124 | Vom Server gesendet: |
| 125 | - MG.char.vitals |
| 126 | Aktuelle Lebenspunkte, Konzentrationspunkte und Vergiftungzustand. |
| 127 | Im Falle von Gift: je groesser, desto staerker die Vergiftung. |
| 128 | MG.char.vitals { "hp": 210, "sp": 90, "poison": 3 } |
| 129 | - MG.char.maxvitals |
| 130 | Aktuelle Maximalwerte fuer LP, KP und Vergiftungszustand. Werden in |
| 131 | einer separaten Gruppe uebertragen, weil sie sich viel seltener aendern. |
| 132 | MG.char.maxvitals { "max_hp": 210, "max_sp": 226, "max_poison": 10 } |
| 133 | |
| 134 | 1.2.4. MG.char.attributes |
| 135 | Vom Server gesendet: |
| 136 | - MG.char.attributes |
| 137 | Aktuelle Attribute des Chars. |
| 138 | Die Daten sind ein Objekt Name-Wert-Paaren von Attributen. |
| 139 | MG.char.attributes {Â "int": 12, "con": 10, "str": 8, "dex": 12 } |
| 140 | |
| 141 | 1.2.5. MG.char.infoVars |
| 142 | Vom Server gesendet: |
| 143 | - MG.char.infoVars |
| 144 | Diese Nachricht gibt den "technischen" Namen aus MG.char.info einen |
| 145 | Namen, der dem Spieler stattdessen angezeigt werden sollte. |
| 146 | Diese Nachricht wird nur bei Modulaktivierung gesendet. |
| 147 | Die Daten sind ein Objekt von Name-Beschreibung-Paaren. |
| 148 | MG.char.infoVars { "level": "Stufe", "guildlevel": "Gildenstufe" } |
| 149 | |
| 150 | 1.2.6. MG.char.info |
| 151 | Vom Server gesendet: |
| 152 | - MG.char.info |
| 153 | Uebertraegt (ausgewaehlte) Daten aus dem Kommando <info>. |
| 154 | Die Daten sind ein Objekt von Name-Wert-Paaren. |
| 155 | (Moegliche weitere Angaben in der Zukunft: Questpunkte, Stufenpunkte |
| 156 | (Genauigkeit 20% einer Stufe), ...) |
| 157 | MG.char.info { "level": 210, "guildlevel": 9 } |
| 158 | |
| 159 | 1.2.7. MG.char.wimpy |
| 160 | Vom Server gesendet: |
| 161 | - MG.char.wimpy |
| 162 | Aktuelle Vorsicht und ggf. Fluchtrichtung des Char. |
| 163 | Die Daten sind ein Objekt Name-Wert-Paare von Vorsicht+Fluchtrichtung. |
| 164 | Ist keine Fluchtrichtung gesetzt, wird 0 uebertragen. |
| 165 | Fuer die Uebermittlung der Vorsicht muss der Char die Quest "Der Schrat |
| 166 | kann nicht einschlafen" geloest haben und fuer die Fluchtrichtung |
| 167 | Seher sein. |
| 168 | MG.char.wimpy {Â "wimpy": 50, "wimpy_dir": "norden" } |
| 169 | |
| 170 | |
| 171 | 1.3. char 1 (Aardwolf) |
| 172 | Dieses Modul ist so aehnlich zum "char" Modul von Aardwolf wie es geht, d.h. |
| 173 | es benutzt die gleichen Schluesselnamen. Es ist aber reduziert im Umfang der |
| 174 | Daten, d.h. es uebertraegt weniger Daten als Aardwolf es tut. |
| 175 | Wann immer moeglich, wird empfohlen, das Modul MG.char stattdessen zu |
| 176 | verwenden. |
| 177 | Wenn MG.char aktiv ist, werden von diesem Modul keine Daten uebertragen. |
| 178 | ES WIRD DAVON ABGERATEN, DIESES MODUL ZU VERWENDEN. |
| 179 | Wann immer moeglich, solltet ihr es in euren Clients abschalten! |
| 180 | |
| 181 | 1.3.1. char.base |
| 182 | Vom Server gesendet: |
| 183 | - char.base |
| 184 | Einige grundlegende Eigenschaften des Chars, die sich selten aendern. |
| 185 | char.base { "name": "Jof", "race": "Elf",} |
| 186 | |
| 187 | 1.3.2. char.vitals |
| 188 | Vom Server gesendet: |
| 189 | - char.vitals |
| 190 | Aktuelle Lebens- und Konzentrationspunkte. |
| 191 | char.vitals { "hp": 210, "mana": 90} |
| 192 | |
| 193 | 1.3.3. char.stats |
| 194 | Vom Server gesendet: |
| 195 | - char.stats |
| 196 | Aktuelle Attribute des Spielers. |
| 197 | Die Daten sind ein Objekt Name-Wert-Paaren von Attributen. |
| 198 | char.stats {Â "int": 12, "con": 10, "str": 8, "dex": 12 } |
| 199 | |
| 200 | 1.3.4. char.status |
| 201 | Vom Server gesendet: |
| 202 | - char.status |
| 203 | Aktueller Level des Chars. (Dies ist die einzige Angabe aus dem Aardwolf |
| 204 | char.status, welche das MG machen kann.) |
| 205 | Die Daten sind ein Objekt Name-Wert-Paaren von Attributen. |
| 206 | char.status { "level": 210 } |
| 207 | |
| 208 | |
| 209 | 1.4. Char 1 (IRE) |
| 210 | Dieses Modul ist so aehnlich zum "Char" Modul von IRE wie es geht, d.h. |
| 211 | es benutzt die gleichen Schluesselnamen. Es ist aber reduziert im Umfang der |
| 212 | Daten, d.h. es uebertraegt weniger Daten als IRE es tut. |
| 213 | Wann immer moeglich, wird empfohlen, das Modul MG.char stattdessen zu |
| 214 | verwenden. |
| 215 | Wenn MG.char aktiv ist, werden von diesem Modul keine Daten uebertragen. |
| 216 | ES WIRD DAVON ABGERATEN, DIESES MODUL ZU VERWENDEN. |
| 217 | Wann immer moeglich, solltet ihr es in euren Clients abschalten! |
| 218 | |
| 219 | 1.4.1. Char.Vitals |
| 220 | Vom Server gesendet: |
| 221 | - Char.Vitals |
| 222 | Aktuelle und maximale Lebens- und Konzentrationspunkte. |
| 223 | Char.Vitals { "hp": 210, "mp": 90, "maxhp": 210, "maxmp": 226 } |
| 224 | |
| 225 | 1.4.2. Char.Status |
| 226 | Vom Server gesendet: |
| 227 | - Char.Status |
| 228 | Aktueller Level und Gilde des Chars. |
| 229 | Die Daten sind ein Objekt Name-Wert-Paaren von Attributen. |
| 230 | Char.Status { "level": 210, "guild": "Zauberer" } |
| 231 | |
| 232 | 1.4.3. Char.StatusVars |
| 233 | Vom Server gesendet: |
| 234 | - Char.StatusVars |
| 235 | Diese Nachricht gibt den "technischen" Namen aus Char.Status einen |
| 236 | Namen, der dem Spieler stattdessen angezeigt werden sollte. |
| 237 | Dieses Kommando wird nur bei Modulaktivierung gesendet. |
| 238 | Die Daten sind ein Objekt von Name-Beschreibung-Paaren. |
| 239 | Char.StatusVars { "level": "Spielerstufe", "guild": "Gilde" } |
| 240 | |
| 241 | |
| 242 | 1.5. comm.channel 1 (Aardwolf) |
| 243 | Dieses Modul ist genauso wie es Aardwolf definiert. Allerdings werden |
| 244 | natuerlich aus dem MG andere Ebenen uebertragen. ;-) |
| 245 | Vom Server gesendet: |
| 246 | - comm.channel |
| 247 | Diese Nachricht wird immer dann gesendet, wenn jemand was auf einer |
| 248 | eingeschalteten Ebene sagt. (Nicht bei Abruf der History!) |
| 249 | Zur Zeit ist es nicht moeglich, Ebenen per GMCP ein- oder auszuschalten. |
| 250 | Wenn dieses GMCP-Modul eingeschaltet ist, wird die Ausgabe der |
| 251 | Ebenenmeldung in der normalen Spielausgabe des MG unterdrueckt. |
| 252 | Achtung: Zur Zeit erfolgt (noch) keine Beruecksichtung eurer |
| 253 | "ignoriere"-Einstellungen bei den via GMCP uebertragenen |
| 254 | Ebenenmeldungen. |
| 255 | comm.channel { "chan": "allgemein", |
| 256 | "msg": "[Allgemein:Maharet] Guten Morgen, Grauen!", |
| 257 | "player": "Maharet" } |
| 258 | |
| 259 | |
| 260 | 1.5. MG.team 1 (eigene Variante, inspiriert von Aardwolf) |
| 261 | Kommt spaeter. ;-) |
| 262 | |
| 263 | |
| 264 | 1.6. MG.room 1 (eigene Variante, inspiriert von Aardwolf) |
| 265 | MG.room beinhaltet Informationen ueber den aktuellen Raum des Spielers |
| 266 | |
| 267 | Vom Server gesendet: |
| 268 | - MG.room.info |
| 269 | Diese Nachrichtig wird immer nach Betreten eines neuen Raumes gesendet |
| 270 | und enthaelt folgende Informationen: |
| 271 | * id: Eine eindeutige ID des Raumes (technisch: ein MD5-Hash) |
| 272 | Diese Angabe fehlt in Labyrinthraeumen (nicht gewollt) und in einigen |
| 273 | speziellen Raeumen (technische Gruende, z.B. manche 'virtual |
| 274 | compiler'). In diesem Fall ist die ID "" (leerer String). |
| 275 | * short: Die Kurzbeschreibung des Raumes |
| 276 | * domain: Die Region, in der der Raum liegt |
| 277 | Manche Raeume liegen nicht in den Regionen. In dem Fall fehlt diese |
| 278 | Angabe. |
| 279 | * exits: eine Liste von sichtbaren Ausgaengen (d.h. unsichtbare Ausgaenge |
| 280 | werden nicht angezeigt). |
| 281 | Hinweis: es ist moeglich, dass der Spieler in einen Raum bewegt wird, |
| 282 | der zwar technisch ein anderer Raum ist, aber kein anderer Ort. In |
| 283 | diesem Fall unterbleibt diese Nachricht. |
| 284 | room.info { "id": "d41d8cd98f00b204e9800998ecf8427e", |
| 285 | "short": "Die beruehmte Abenteurergilde", |
| 286 | "domain": "Ebene", |
| 287 | exits: [ "norden", "oben" ] } |
| 288 | |
| 289 | |
| 290 | 2. Vergleich mit GMCP in Aardwolf und IRE Muds |
| 291 | Im Morgengrauen wird GMCP letztendlich nur als Spezifikation des Transport |
| 292 | Layers betrachtet, da bei den Modulen jedes Mud seine eigene Definition der |
| 293 | uebertragenen Daten und ihrer Bedeutung vornimmt. |
| 294 | |
| 295 | Das Modul "Char" ist aus den IRE-Muds, welches nur existiert, weil einige |
| 296 | Clients es standardmaessig schonmal einschalten. Es sendet aber nur einen |
| 297 | Minimalsatz an Daten. |
| 298 | Das Modul "char" ist aus Aardwolf, welches nur existiert, weil einige |
| 299 | Clients es standardmaessig schonmal einschalten. Es sendet aber nur einen |
| 300 | Minimalsatz an Daten. |
| 301 | |
| 302 | Dem Modul MG.char sollte immer der Vorzug vor "Char" oder "char" gegeben |
| 303 | werden, da dort deutlich mehr Daten uebertragen werden. |
| 304 | |
| 305 | Das Modul "Room" aus IRE wird nicht unterstuetzt, weil seine Daten vom MG |
| 306 | groesstenteils nicht in der geforderten Form bereitgestellt werden koennen |
| 307 | (zumindest nicht ohne ungerechtfertigten Aufwand). |
| 308 | |
| 309 | 3. Transport Specification |
| 310 | Einstweilen am besten auf http://www.gammon.com.au/gmcp nachlesen. |
| 311 | |
| 312 | Kommt hier vielleicht spaeter noch, einstweilen am besten im Netz |
| 313 | nachgucken. |
| 314 | |
| 315 | 4. Implementationsdetails |
| 316 | Im MG ist Gross-/Kleinschreibung des Modulnamens wichtig, im Gegensatz zum |
| 317 | IRE. Meines Wissens (bitte korrigiert mich ggf.), machte die |
| 318 | Transportspezifikation keine Aussage in diesem Punkt, sondern IRE hat dies |
| 319 | entschieden. |
| 320 | Jetzt ist es so, dass Aardwolf teils Module mit dem gleichen Namen, aber |
| 321 | anderer Funktion wie IRE gebaut hat. Alle Doku von Aardwolf schreibt aber |
| 322 | immer von kleingeschriebenen Modulnamen. Insofern ist das jetzt ein Versuch, |
| 323 | die Module von IRE/Aardwolf doch irgndendwie auseinander zu halten. |
| 324 | |
| 325 | |
| 326 | 5. Client-Kram |
| 327 | 5.1. Tips und Hinweiss |
| 328 | Manche Clients zeigen die empfangenen GMCP-Daten standardmaessig auf dem |
| 329 | Bildschirm an. |
| 330 | Normalerweise sortieren sie die Daten aber in von Scripten nutzbare |
| 331 | Tabellen ein, so dass es entfaellt, irgendeinen Text zu parsen. |
| 332 | In der Regel ist es dann auch so, dass der Client Moeglichkeiten anbietet, |
| 333 | auf den Empfang von GMCP-Daten reagieren zu koennen (z.B. nen Script |
| 334 | aufrufen zu lassen). |
| 335 | |
| 336 | 5.2. Clients mit GMCP-MG-Support |
| 337 | |
| 338 | 5.3. Clients mit GMCP-Support (Transport Spec) |
| 339 | * Mudlet (http://forums.mudlet.org/viewtopic.php?f=7&t=1547) |
| 340 | Im Netz sind div. weitere Quellen und Tutorial zu finden. |
| 341 | * Tintin++ (http://tintin.sourceforge.net/board/viewtopic.php?p=4651) |
| 342 | * TF 5 (http://mikeride.chaosnet.org/abelinc/scripts/telopt.html) |
| 343 | * CMUD (http://forums.zuggsoft.com/forums/viewtopic.php?p=158455#158455) |
| 344 | * Mushclient (http://www.aardwolf.com/wiki/index.php/Clients/MushclientGMCP) |
| 345 | |
| 346 | |
| 347 | 6. Angedachte Module fuer die Zukunft |
| 348 | Ob und wann etwas aus diesem Bereich kommt, ist voellig offen. Haengt auch vom |
| 349 | Interesse der Spielerschaft ab. |
| 350 | |
| 351 | 6.3. Char.Items (IRE) |
| 352 | Eigentlich eher weniger geplant... |
| 353 | |
| 354 | LETZTE AeNDERUNG: |
| 355 | 09.01.2016, Zesstra |
| 356 | |