Hallo MitmagierInnen *g*,

Ok, dann gehts mal ein bischen zur Sache:

/std/thing/commands.c wurde so erweitert, dass man auch komplexe Syntax
direkt im AddCmd vorparsen kann.

Dazu ein kurzes Beispiel:
-------------------------

In einem Objekt (ein Busch) findet sich folgende Syntaxdefinition.

 AddCmd("pfluecke|ernte&fruechte|beeren&@ID","cmd_pfluecken",
        "Was willst Du denn @verben?|Wo willst Du denn die Beeren @verben?");

Der erste Parameter definiert die Syntax. Das Zeichen & trennt verschiedene
zu parsende Items:

1. pfluecke|ernte
2. fruechte|beeren
3. @ID

Unter 1. finden sich die Verben - das sind die gleichen, die man in der
alten Version auch belegen konnte. Die Regel reagiert also auf "pfluecke"
oder auf "ernte".

Alle weiteren Regeln muessen erfuellt werden, damit der zweite Parameter
(die Funktion) aufgerufen wird. @ID steht dabei fuer die ID des Objektes,
in dem das AddCmd steht. Hier also der Busch.

Dazu einige Beispiele:

a) > pfluecke beeren
 -> erfuellt 1 und 2. Aber nicht 3. => Fehlermeldung.

b) > ernte von busch
 -> erfuellt 1 und 3, jedoch 2 nicht. => Fehlermeldung.

c) > pfluecke fruechte von busch
 -> erfuellt 1, 2 und 3 -> busch->cmd_pfluecken() wird aufgerufen. Das "von"
    ist Fuellwerk. Davon kann beliebig viel im String sein. Sie werden 
    ignoriert.
    Es sind also auch unsinnige Syntaxe richtig, solange der String die 
    Items erufellt.

Im Fall c) wird das Verhalten des Busches durch die Funktion "cmd_pfluecken"
definiert, wie auch in der alten Version von AddCmd.

Was passiert aber in den Faellen a) und b)? Dafuer ist der dritte
Parameter da:
  "Was willst Du denn @VERBen?|Wo willst Du denn die Beeren @VERBen?");

Hier sind zwei Fehlermeldungen, durch | getrennt, definiert:

x) Was willst Du denn @VERBen?
y) Wo willst Du denn die Beeren @VERBen?

Erst wird geprueft, ob 2. erfuellt ist. Falls nicht, gibt es Fehlermeldung x)
Dann wird auf 3. geprueft. Ist das nicht erfuellt (aber 2. schon) gibt es
Fehlermeldung y).

Im Fall a sind 1 und 2 erfuellt. Demnach wird y) ausgegeben. @VERB wird
dabei durch das benutzte Verb ersetzt (das abschliessende en, bzw e wird
abgeschnitten):
 Wo willst Du denn die Beeren pfluecken?

Im Fall b ist 1 erufellt, 2 aber schon nicht. Daher gibt es Fehlermeldung
x). Auf 3. wird nicht mehr geprueft.
 Was willst Du denn ernten?

Wie schon erwaehnt erfuellt c) alle Bedingungen und es gibt keine Ausgabe -
Statt dessen kann man das Pfluecken in der Funktion abhandeln.

In den Faellen 1 und 2 wird die Fehlermeldung ueber notify_fail()
abgehandelt. Ergo wird hier anderen Befehlen von anderen Objekten noch
eine Chance gegeben. Gleiches gilt fuer die Funktion cmd_pfluecken(), wenn
deren Rueckgabewert 0 ist. Auch hier gibt es die Analogie zum alten AddCmd.

Gibt cmd_pfluecken() einen Wert ungleich 0 zurueck, wird die Suche nach
der richtigen Syntax danach abgebrochen, so dass auch kein anderes Objekt
mehr gefragt wird (wie gehabt).

Das ist auch fuer Forscherpunkte wichtig. FP werden generell nur bei einem
Rueckgabewert ungleich 0 vergeben.

Eine kleine Erweiterung der Beispielsyntax:
-------------------------------------------

 AddCmd("pfluecke|ernte&fruechte|beeren&@ID@\impossible",0,
  "Was willst Du denn @VERBen?|Wo willst Du denn die Beeren @VERBen?|"
  "Du pflueckst ein paar Beeren und isst sie auf.^@WER isst ein paar
  Beeren.");

Eine neue Regel:

4. \impossible

Und eine neue Fehlermeldung:
z) Du pflueckst ein paar Beeren und isst sie auf.^@WER isst ein paar Beeren.

Zur Regel:

Die Regel ist nicht erfuellbar, da Spieler das \i nicht erzeugen
koennen. Zwangslaeufig gibt es auch keine Funktion, die aufgerufen werden
koennte.

Dafuer gibt es eine Fehlermeldung, die ein neues Element enthaelt. Das
^. Wird diese Meldung ausgegeben ist das genau wie ein return 1 in der
Funktion. Die Syntax wird als richtig anerkannt. (Es kann hierfuer also
auch FP geben).

Der Text vor dem ^ geht an den Spieler, alles dahinter geht an die Spieler
im Raum. Steht hinter dem ^ nichts, gibt es keine Raummeldung.

Auf diese Weise kann man leicht ein Raumkommando erstellen, dass nur
Textausgaben macht, aber keine Funktionalitaet enthaelt. Es ist keine
eigenstaendige Funktion mit irgendwelchem eigenen Parsing mehr noetig.

Das @WER wird durch this_player()->Name() ersetzt, so dass man auch einen
Persoenlichen bezug in den Meldungen herstellen kann.

Abwaertskompatibel
------------------

Die Erweiterungen von AddCmd erlauben ein einfacheres Erstellen von
Standard-Kommandos, ohne dass man sich mit dem Parsen in Funktionen
beschaeftigen muss.

Die Aenderung ist vollstaendig abwaertskompatibel. Wer sich also sagt,
das das alles viel zu kompliziert sei, kann weiterhin:

 AddCmd(({"pfluecke","ernte"}),"cmd_pfluecken");

benutzen. Das Verhalten ist haargenau das selbe wie bisher. Dementsprechend
ist auch kaum Aufwand beim Einpflegen dieser Aenderung notwendig.

Zur Beachtung
-------------

Ueberall, wo direkt auf P_COMMANDS zugegriffen wird, kann es prinzipiell
zu Problemen kommen, da sich die Struktur des Mappings und der Zugriff
darauf geaendert hat.

Im Folgeartikel findet sich eine Liste mit allen Objekten, die das machen. In
den oeffentlichen Verzeichnissen werde ich mich mit den Magiern in Verbindung
setzen oder selbst kontrollieren, ob Aenderungen notwendig sind.

Objekte in den Players-Verzeichnissen werde ich nur in Ausnahmefaellen
anpassen. Zur Erinnerung: Angeschlossenes gehoert nicht nach /players/.

Der Code ist auf Kompatibilitaet mit dem alten System ausgelegt, dennoch
gibt es ein paar Aenderungen. Zum Beispiel ist P_COMMANDS keine echte
Property mehr sondern eine lokale Variable. Demzufolge wird P_COMMANDS
bei "xprop" nicht mehr angezeigt. Die Schnittstelle wird durch _set_
und _query_funktionen realisiert. Die Mappings werden _immer_ als Kopien
rausgegeben, so dass man damit nicht versehentlich Unsinn machen kann.

Schlusswort
-----------

Dieser Artikel stellt nur eine Einleitung in die Aenderung und deren
Moeglichkeiten dar und ist keinesfalls vollstaendig. Wer mehr darueber wissen
will, ist eingeladen, sich die Manpage zu "AddCmd" und zu den Beispielen
"AddCmd_bsp" anzuschauen.

Die Seiten sind aus dem Regenbogen "geliehen" und werden in den kommenden
Tagen noch auf die Beduerfnisse des Morgengrauen angepasst.

Mein Dank geht an Gloinson, der die Idee hatte, die Anpassungen vorzunehmen
und Migration des Codes ins MorgenGrauen uebernommen hat.

Falls nun noch Fragen sind, nur zu! :)

V*,