doc/help/GMCP

General Mud Communication Protocol im MorgenGrauen
==================================================

0. Einleitung
   GMCP wird benutzt, um Daten zwischen MUD und Client "out of band" zu
   uebertragen. "Out of band" bedeutet hier, dass der Datenaustausch hinter
   den Kulissen passiert statt in der normalen textuellen Spielausgabe,
   welcher vom Client mittels mehr oder weniger komplizierter Trigger
   ausgewertet werden muss.

   Vorteile:
   * keine komplexen Trigger (Regexps) mehr.
   * Daten werden in einem definierten Format uebertragen, welches der Client
     fuer euch interpretiert.
   * keine Gagtrigger mehr noetig, um empfangenen Text auszublenden
   * keine stoerenden Ausgaben, falls man diese Gagtrigger nicht hat.
   * Daten koennen auch uebertragen werden in Situationen, in denen eine
     normale Textausgabe nicht so gut geht, z.B. in Editoren.
   * Daten, die die Clientscripte nicht verarbeiten, stoeren nicht den
     Textfluss.
   * Der Client kann konfigurieren, welche Informationen er bekommen will.
   * Im MG ist neben Dingen wie LP und KP die Uebertragung div. anderer Dinge
     geplant, vor allem andere Informationen  ueber den Char oder den Raum
     (z.B. eindeutige Raum-IDs (in den meisten Faellen)).


1. Unterstuetzte Module

1.1. Core (aus IRE (Iron Realms Entertainment) MUDs)
  Das Core Modul ist immer aktiv. Es verwaltet die grundsaetzlichen
  Einstellungen von GMCP. Die MG-Variante ist fast identisch zur IRE-Variante,
  hat allerdings zusaetzliche das "Debug"-Kommando.

  Vom Client gesendet:
    - Core.Hello
        Muss die erste Nachricht sein, welche der Client nach Aktivierung von
        GMCP sendet.
        Die Daten sind ein Objekt mit den Schluesseln "client" und "version",
        welche entsprechend den Clientnamen und seine Versionskennung
        enthalten.
      Core.Hello { "client": "Nexus", "version": "3.1.90" }
    - Core.Supports.Set
        Informiert das MUD ueber die Pakete/Module, die der Client
        unterstuetzt, d.h. die der Client empfangen kann. Es ist immer noch
        Entscheidung des Muds, welche dieser Module ihre Daten senden (z.B.
        wird MG einem "MG.char" den Vorzug geben vor einem generischen "Char",
        falls vom Client beide unterstuetzt werden.
        Wenn bereits vorher ein Core.Supports.* Kommando empfangen wurde, wird
        die Liste der unterstuetzten Module durch die neue ersetzt.
        Daten sind ein Array von Strings, welche jeweils den Modulnamen und
        die Versionsnummer angeben (mit einem Leerzeichen getrennt).
        Die Versionsnummer muss eine positive Ganzzahl sein.
        Die meisten Clients werden Set nur einmal am Anfang senden und
        brauchen kein Add/Remove.
      Core.Supports.Set [ "MG.char 1", "MG.room 1" ]
    - Core.Supports.Add
        aehnlich zu Set, aber es fuegt die angegeben Module an die in der
        Vergangenheit uebermittelten an.
        Wenn noch keine Liste gesendet wurde, ist das Ergebnis wie bei Set.
        Wenn die Liste Module enthaelt, die bereits aktiv sind, wird die neue
        Versionsnummer Prioritaet vor der alten haben, selbst wenn die kleiner
        ist.
        Die Daten sind identisch zu Set.
    - Core.Supports.Remove
        Entfernt die angebenen Module aus der Liste der unterstuetzen Module.
        Die Daten sind identisch zu Set. Die Modulversionen sind NICHT
        optional (anders als bei IRE). Allerdings werden auch Module anderer
        Version abgeschaltet. (Insofern koennte man - zur Zeit - einfach immer 1
        als Versionsnummer senden.)
    - Core.KeepAlive
        Vom MG ignoriert, weil Verbindungen nicht automatisch getrennt werden.
    - Core.Ping
        Veranlasst das MG mit einem Core.Ping zu antworten.
        Die Daten ist eine Ganzzahl, welche die durchschnittliche Pingzeit
        aus verherigen Pings enthaelt, falls verfuegbar.
        (Anmerkung: IRE macht keine Angabe ueber die Einheit dieser Zahl. MG
         geht von Millisekunden aus.)
      Core.Ping 120
    - Core.Debug
        Kann gesendet werden, um die Ausgabe von menschenlesbaren
        Debugmeldungen vom GMCP zu aktivieren.
        Die Daten sind eine Ganzzahl. Je groesser, desto mehr Debugmeldungen
        werden ausgegeben.
        0 schaltet die Debugmeldungen aus.
        1 schaltet nur die Ausgabe von GMCP-Fehlern an.
        100 schaltet alles an.
      Core.Debug 1
  Vom Server gesendet:
    - Core.Ping
        Als Antwort eines vom Client empfangenen Core.Ping gesendet.
        Keine Daten.
    - Core.Goodbye [NOT IMPLEMENTED YET!]
        Gesendet vom MUD unmittelbar vor Verbindungstrennung.
        Die Daten sind eine Nachricht (string), welche dem User angezeigt
        werden kann und koennen den Grund fuer den Disconnect erklaeren.
      Core.Goodbye "Goodbye, adventurer"

1.2. MG.char 1 (angelehnt an Aardwolf, aber modifiziert)
  Die Uebertragung der Kommandos in diesem Modul wird aktiviert, wenn
  "MG.char" aktiv ist. Es gibt keine Submodule, die getrennt aktiviert werden
  muessten. Die jeweiligen Kommandos werden gesendet, wenn sich eins der
  gesendeten Daten aendert.
  Alle Kommandos werden einmal bei Modulaktivierung gesendet (auch wenn ein
  Modul durch ein Core.Supports.Set (erneut) aktiviert wird).
  Ist dieses Modul vom Client unterstuetzt, werden keine Daten aus den
  Modulen "Char" und "char" gesendet.
  (Spieler aelter als 12.05.2013 muessen einmalig den textuellen Report mit
   "report ein" und "report vorsicht" einschalten, damit die Uebertragung
   via GMCP freigeschaltet wird. Der Report kann danach wieder
   ausgeschaltet werden.)

1.2.2. MG.char.base
  Vom Server gesendet:
    - MG.char.base
      Einige grundlegende Eigenschaften des Chars, die sich selten aendern.
      Ein "wizlevel" von 1 zeigt an, dass der Char ein Seher ist.
      Der "title" kann am Anfang ein Backspace "\b" gefolgt von "," oder "'"
      enthalten.
      MG.char.base { "name": "Jof", "guild": "Abenteurer",
                     "race": "Elf", "presay": "Mudgott",
                     "title": "idlet.", "wizlevel": 101 }

1.2.3. MG.char.vitals
  Vom Server gesendet:
    - MG.char.vitals
      Aktuelle Lebenspunkte, Konzentrationspunkte und Vergiftungzustand.
      Im Falle von Gift: je groesser, desto staerker die Vergiftung.
      MG.char.vitals { "hp": 210, "sp": 90, "poison": 3 }
    - MG.char.maxvitals
      Aktuelle Maximalwerte fuer LP, KP und Vergiftungszustand. Werden in
      einer separaten Gruppe uebertragen, weil sie sich viel seltener aendern.
      MG.char.maxvitals { "max_hp": 210, "max_sp": 226, "max_poison": 10 }

1.2.4. MG.char.attributes
  Vom Server gesendet:
    - MG.char.attributes
      Aktuelle Attribute des Chars.
      Die Daten sind ein Objekt Name-Wert-Paaren von Attributen.
      MG.char.attributes { "int": 12, "con": 10, "str": 8, "dex": 12 }

1.2.5. MG.char.infoVars
  Vom Server gesendet:
    - MG.char.infoVars
      Diese Nachricht gibt den "technischen" Namen aus MG.char.info einen
      Namen, der dem Spieler stattdessen angezeigt werden sollte.
      Diese Nachricht wird nur bei Modulaktivierung gesendet.
      Die Daten sind ein Objekt von Name-Beschreibung-Paaren.
      MG.char.infoVars { "level": "Stufe", "guildlevel": "Gildenstufe" }

1.2.6. MG.char.info
  Vom Server gesendet:
    - MG.char.info
      Uebertraegt (ausgewaehlte) Daten aus dem Kommando <info>.
      Die Daten sind ein Objekt von Name-Wert-Paaren.
      (Moegliche weitere Angaben in der Zukunft: Questpunkte, Stufenpunkte
       (Genauigkeit 20% einer Stufe), ...)
      MG.char.info { "level": 210, "guildlevel": 9 }

1.2.7. MG.char.wimpy
  Vom Server gesendet:
    - MG.char.wimpy
      Aktuelle Vorsicht und ggf. Fluchtrichtung des Char.
      Die Daten sind ein Objekt Name-Wert-Paare von Vorsicht+Fluchtrichtung.
      Ist keine Fluchtrichtung gesetzt, wird 0 uebertragen.
      Fuer die Uebermittlung der Vorsicht muss der Char die Quest "Der Schrat
      kann nicht einschlafen" geloest haben und fuer die Fluchtrichtung
      Seher sein.
      MG.char.wimpy { "wimpy": 50, "wimpy_dir": "norden" }


1.3. char 1 (Aardwolf)
  Dieses Modul ist so aehnlich zum "char" Modul von Aardwolf wie es geht, d.h.
  es benutzt die gleichen Schluesselnamen. Es ist aber reduziert im Umfang der
  Daten, d.h. es uebertraegt weniger Daten als Aardwolf es tut.
  Wann immer moeglich, wird empfohlen, das Modul MG.char stattdessen zu
  verwenden.
  Wenn MG.char aktiv ist, werden von diesem Modul keine Daten uebertragen.
  ES WIRD DAVON ABGERATEN, DIESES MODUL ZU VERWENDEN.
  Wann immer moeglich, solltet ihr es in euren Clients abschalten!

1.3.1. char.base
  Vom Server gesendet:
    - char.base
      Einige grundlegende Eigenschaften des Chars, die sich selten aendern.
      char.base { "name": "Jof", "race": "Elf",}

1.3.2. char.vitals
  Vom Server gesendet:
    - char.vitals
      Aktuelle Lebens- und Konzentrationspunkte.
      char.vitals { "hp": 210, "mana": 90}

1.3.3. char.stats
  Vom Server gesendet:
    - char.stats
      Aktuelle Attribute des Spielers.
      Die Daten sind ein Objekt Name-Wert-Paaren von Attributen.
      char.stats { "int": 12, "con": 10, "str": 8, "dex": 12 }

1.3.4. char.status
  Vom Server gesendet:
    - char.status
      Aktueller Level des Chars. (Dies ist die einzige Angabe aus dem Aardwolf
      char.status, welche das MG machen kann.)
      Die Daten sind ein Objekt Name-Wert-Paaren von Attributen.
      char.status { "level": 210 }


1.4. Char 1 (IRE)
  Dieses Modul ist so aehnlich zum "Char" Modul von IRE wie es geht, d.h.
  es benutzt die gleichen Schluesselnamen. Es ist aber reduziert im Umfang der
  Daten, d.h. es uebertraegt weniger Daten als IRE es tut.
  Wann immer moeglich, wird empfohlen, das Modul MG.char stattdessen zu
  verwenden.
  Wenn MG.char aktiv ist, werden von diesem Modul keine Daten uebertragen.
  ES WIRD DAVON ABGERATEN, DIESES MODUL ZU VERWENDEN.
  Wann immer moeglich, solltet ihr es in euren Clients abschalten!

1.4.1. Char.Vitals
  Vom Server gesendet:
    - Char.Vitals
      Aktuelle und maximale Lebens- und Konzentrationspunkte.
      Char.Vitals { "hp": 210, "mp": 90, "maxhp": 210, "maxmp": 226 }

1.4.2. Char.Status
  Vom Server gesendet:
    - Char.Status
      Aktueller Level und Gilde des Chars. 
      Die Daten sind ein Objekt Name-Wert-Paaren von Attributen.
      Char.Status { "level": 210, "guild": "Zauberer" }

1.4.3. Char.StatusVars
  Vom Server gesendet:
    - Char.StatusVars
      Diese Nachricht gibt den "technischen" Namen aus Char.Status einen
      Namen, der dem Spieler stattdessen angezeigt werden sollte.
      Dieses Kommando wird nur bei Modulaktivierung gesendet.
      Die Daten sind ein Objekt von Name-Beschreibung-Paaren.
      Char.StatusVars { "level": "Spielerstufe", "guild": "Gilde" }


1.5. comm.channel 1 (Aardwolf)
  Dieses Modul ist genauso wie es Aardwolf definiert. Allerdings werden
  natuerlich aus dem MG andere Ebenen uebertragen. ;-)
  Vom Server gesendet:
    - comm.channel
      Diese Nachricht wird immer dann gesendet, wenn jemand was auf einer
      eingeschalteten Ebene sagt. (Nicht bei Abruf der History!)
      Zur Zeit ist es nicht moeglich, Ebenen per GMCP ein- oder auszuschalten.
      Wenn dieses GMCP-Modul eingeschaltet ist, wird die Ausgabe der
      Ebenenmeldung in der normalen Spielausgabe des MG unterdrueckt.
      Achtung: Zur Zeit erfolgt (noch) keine Beruecksichtung eurer
      "ignoriere"-Einstellungen bei den via GMCP uebertragenen
      Ebenenmeldungen.
      comm.channel { "chan": "allgemein",
          "msg": "[Allgemein:Maharet] Guten Morgen, Grauen!", 
          "player": "Maharet" }


1.5. MG.team 1 (eigene Variante, inspiriert von Aardwolf)
     Kommt spaeter. ;-)


1.6. MG.room 1 (eigene Variante, inspiriert von Aardwolf)
  MG.room beinhaltet Informationen ueber den aktuellen Raum des Spielers

  Vom Server gesendet:
  - MG.room.info
    Diese Nachrichtig wird immer nach Betreten eines neuen Raumes gesendet
    und enthaelt folgende Informationen:
    * id: Eine eindeutige ID des Raumes (technisch: ein MD5-Hash)
        Diese Angabe fehlt in Labyrinthraeumen (nicht gewollt) und in einigen
        speziellen Raeumen (technische Gruende, z.B. manche 'virtual
        compiler'). In diesem Fall ist die ID "" (leerer String).
    * short: Die Kurzbeschreibung des Raumes
    * domain: Die Region, in der der Raum liegt
        Manche Raeume liegen nicht in den Regionen. In dem Fall fehlt diese
        Angabe.
    * exits: eine Liste von sichtbaren Ausgaengen (d.h. unsichtbare Ausgaenge
        werden nicht angezeigt).
    Hinweis: es ist moeglich, dass der Spieler in einen Raum bewegt wird,
    der zwar technisch ein anderer Raum ist, aber kein anderer Ort. In
    diesem Fall unterbleibt diese Nachricht.
    room.info { "id": "d41d8cd98f00b204e9800998ecf8427e",
                "short": "Die beruehmte Abenteurergilde",
                "domain": "Ebene",
                exits: [ "norden", "oben" ] }


2. Vergleich mit GMCP in Aardwolf und IRE Muds
   Im Morgengrauen wird GMCP letztendlich nur als Spezifikation des Transport
   Layers betrachtet, da bei den Modulen jedes Mud seine eigene Definition der
   uebertragenen Daten und ihrer Bedeutung vornimmt.

   Das Modul "Char" ist aus den IRE-Muds, welches nur existiert, weil einige
   Clients es standardmaessig schonmal einschalten. Es sendet aber nur einen
   Minimalsatz an Daten.
   Das Modul "char" ist aus Aardwolf, welches nur existiert, weil einige
   Clients es standardmaessig schonmal einschalten. Es sendet aber nur einen
   Minimalsatz an Daten.

   Dem Modul MG.char sollte immer der Vorzug vor "Char" oder "char" gegeben
   werden, da dort deutlich mehr Daten uebertragen werden.

   Das Modul "Room" aus IRE wird nicht unterstuetzt, weil seine Daten vom MG
   groesstenteils nicht in der geforderten Form bereitgestellt werden koennen
   (zumindest nicht ohne ungerechtfertigten Aufwand).

3. Transport Specification
   Einstweilen am besten auf http://www.gammon.com.au/gmcp nachlesen.

   Kommt hier vielleicht spaeter noch, einstweilen am besten im Netz
   nachgucken.

4. Implementationsdetails
  Im MG ist Gross-/Kleinschreibung des Modulnamens wichtig, im Gegensatz zum
  IRE. Meines Wissens (bitte korrigiert mich ggf.), machte die
  Transportspezifikation keine Aussage in diesem Punkt, sondern IRE hat dies
  entschieden.
  Jetzt ist es so, dass Aardwolf teils Module mit dem gleichen Namen, aber
  anderer Funktion wie IRE gebaut hat. Alle Doku von Aardwolf schreibt aber
  immer von kleingeschriebenen Modulnamen. Insofern ist das jetzt ein Versuch,
  die Module von IRE/Aardwolf doch irgndendwie auseinander zu halten.


5. Client-Kram
5.1. Tips und Hinweiss
  Manche Clients zeigen die empfangenen GMCP-Daten standardmaessig auf dem
  Bildschirm an.
  Normalerweise sortieren sie die Daten  aber in von Scripten nutzbare
  Tabellen ein, so dass es entfaellt, irgendeinen Text zu parsen.
  In der Regel ist es dann auch so, dass der Client Moeglichkeiten anbietet,
  auf den Empfang von GMCP-Daten reagieren zu koennen (z.B. nen Script
  aufrufen zu lassen).

5.2. Clients mit GMCP-MG-Support

5.3. Clients mit GMCP-Support (Transport Spec)
  * Mudlet (http://forums.mudlet.org/viewtopic.php?f=7&t=1547)
    Im Netz sind div. weitere Quellen und Tutorial zu finden.
  * Tintin++ (http://tintin.sourceforge.net/board/viewtopic.php?p=4651)
  * TF 5 (http://mikeride.chaosnet.org/abelinc/scripts/telopt.html)
  * CMUD (http://forums.zuggsoft.com/forums/viewtopic.php?p=158455#158455)
  * Mushclient (http://www.aardwolf.com/wiki/index.php/Clients/MushclientGMCP)


6. Angedachte Module fuer die Zukunft
Ob und wann etwas aus diesem Bereich kommt, ist voellig offen. Haengt auch vom
Interesse der Spielerschaft ab.

6.3. Char.Items (IRE)
  Eigentlich eher weniger geplant...

LETZTE AeNDERUNG:
09.01.2016, Zesstra