| MG Mud User | 88f1247 | 2016-06-24 23:31:02 +0200 | [diff] [blame^] | 1 | Hallo MitmagierInnen *g*, |
| 2 | |
| 3 | Ok, dann gehts mal ein bischen zur Sache: |
| 4 | |
| 5 | /std/thing/commands.c wurde so erweitert, dass man auch komplexe Syntax |
| 6 | direkt im AddCmd vorparsen kann. |
| 7 | |
| 8 | Dazu ein kurzes Beispiel: |
| 9 | ------------------------- |
| 10 | |
| 11 | In einem Objekt (ein Busch) findet sich folgende Syntaxdefinition. |
| 12 | |
| 13 | AddCmd("pfluecke|ernte&fruechte|beeren&@ID","cmd_pfluecken", |
| 14 | "Was willst Du denn @verben?|Wo willst Du denn die Beeren @verben?"); |
| 15 | |
| 16 | Der erste Parameter definiert die Syntax. Das Zeichen & trennt verschiedene |
| 17 | zu parsende Items: |
| 18 | |
| 19 | 1. pfluecke|ernte |
| 20 | 2. fruechte|beeren |
| 21 | 3. @ID |
| 22 | |
| 23 | Unter 1. finden sich die Verben - das sind die gleichen, die man in der |
| 24 | alten Version auch belegen konnte. Die Regel reagiert also auf "pfluecke" |
| 25 | oder auf "ernte". |
| 26 | |
| 27 | Alle weiteren Regeln muessen erfuellt werden, damit der zweite Parameter |
| 28 | (die Funktion) aufgerufen wird. @ID steht dabei fuer die ID des Objektes, |
| 29 | in dem das AddCmd steht. Hier also der Busch. |
| 30 | |
| 31 | Dazu einige Beispiele: |
| 32 | |
| 33 | a) > pfluecke beeren |
| 34 | -> erfuellt 1 und 2. Aber nicht 3. => Fehlermeldung. |
| 35 | |
| 36 | b) > ernte von busch |
| 37 | -> erfuellt 1 und 3, jedoch 2 nicht. => Fehlermeldung. |
| 38 | |
| 39 | c) > pfluecke fruechte von busch |
| 40 | -> erfuellt 1, 2 und 3 -> busch->cmd_pfluecken() wird aufgerufen. Das "von" |
| 41 | ist Fuellwerk. Davon kann beliebig viel im String sein. Sie werden |
| 42 | ignoriert. |
| 43 | Es sind also auch unsinnige Syntaxe richtig, solange der String die |
| 44 | Items erufellt. |
| 45 | |
| 46 | Im Fall c) wird das Verhalten des Busches durch die Funktion "cmd_pfluecken" |
| 47 | definiert, wie auch in der alten Version von AddCmd. |
| 48 | |
| 49 | Was passiert aber in den Faellen a) und b)? Dafuer ist der dritte |
| 50 | Parameter da: |
| 51 | "Was willst Du denn @VERBen?|Wo willst Du denn die Beeren @VERBen?"); |
| 52 | |
| 53 | Hier sind zwei Fehlermeldungen, durch | getrennt, definiert: |
| 54 | |
| 55 | x) Was willst Du denn @VERBen? |
| 56 | y) Wo willst Du denn die Beeren @VERBen? |
| 57 | |
| 58 | Erst wird geprueft, ob 2. erfuellt ist. Falls nicht, gibt es Fehlermeldung x) |
| 59 | Dann wird auf 3. geprueft. Ist das nicht erfuellt (aber 2. schon) gibt es |
| 60 | Fehlermeldung y). |
| 61 | |
| 62 | Im Fall a sind 1 und 2 erfuellt. Demnach wird y) ausgegeben. @VERB wird |
| 63 | dabei durch das benutzte Verb ersetzt (das abschliessende en, bzw e wird |
| 64 | abgeschnitten): |
| 65 | Wo willst Du denn die Beeren pfluecken? |
| 66 | |
| 67 | Im Fall b ist 1 erufellt, 2 aber schon nicht. Daher gibt es Fehlermeldung |
| 68 | x). Auf 3. wird nicht mehr geprueft. |
| 69 | Was willst Du denn ernten? |
| 70 | |
| 71 | Wie schon erwaehnt erfuellt c) alle Bedingungen und es gibt keine Ausgabe - |
| 72 | Statt dessen kann man das Pfluecken in der Funktion abhandeln. |
| 73 | |
| 74 | In den Faellen 1 und 2 wird die Fehlermeldung ueber notify_fail() |
| 75 | abgehandelt. Ergo wird hier anderen Befehlen von anderen Objekten noch |
| 76 | eine Chance gegeben. Gleiches gilt fuer die Funktion cmd_pfluecken(), wenn |
| 77 | deren Rueckgabewert 0 ist. Auch hier gibt es die Analogie zum alten AddCmd. |
| 78 | |
| 79 | Gibt cmd_pfluecken() einen Wert ungleich 0 zurueck, wird die Suche nach |
| 80 | der richtigen Syntax danach abgebrochen, so dass auch kein anderes Objekt |
| 81 | mehr gefragt wird (wie gehabt). |
| 82 | |
| 83 | Das ist auch fuer Forscherpunkte wichtig. FP werden generell nur bei einem |
| 84 | Rueckgabewert ungleich 0 vergeben. |
| 85 | |
| 86 | Eine kleine Erweiterung der Beispielsyntax: |
| 87 | ------------------------------------------- |
| 88 | |
| 89 | AddCmd("pfluecke|ernte&fruechte|beeren&@ID@\impossible",0, |
| 90 | "Was willst Du denn @VERBen?|Wo willst Du denn die Beeren @VERBen?|" |
| 91 | "Du pflueckst ein paar Beeren und isst sie auf.^@WER isst ein paar |
| 92 | Beeren."); |
| 93 | |
| 94 | Eine neue Regel: |
| 95 | |
| 96 | 4. \impossible |
| 97 | |
| 98 | Und eine neue Fehlermeldung: |
| 99 | z) Du pflueckst ein paar Beeren und isst sie auf.^@WER isst ein paar Beeren. |
| 100 | |
| 101 | Zur Regel: |
| 102 | |
| 103 | Die Regel ist nicht erfuellbar, da Spieler das \i nicht erzeugen |
| 104 | koennen. Zwangslaeufig gibt es auch keine Funktion, die aufgerufen werden |
| 105 | koennte. |
| 106 | |
| 107 | Dafuer gibt es eine Fehlermeldung, die ein neues Element enthaelt. Das |
| 108 | ^. Wird diese Meldung ausgegeben ist das genau wie ein return 1 in der |
| 109 | Funktion. Die Syntax wird als richtig anerkannt. (Es kann hierfuer also |
| 110 | auch FP geben). |
| 111 | |
| 112 | Der Text vor dem ^ geht an den Spieler, alles dahinter geht an die Spieler |
| 113 | im Raum. Steht hinter dem ^ nichts, gibt es keine Raummeldung. |
| 114 | |
| 115 | Auf diese Weise kann man leicht ein Raumkommando erstellen, dass nur |
| 116 | Textausgaben macht, aber keine Funktionalitaet enthaelt. Es ist keine |
| 117 | eigenstaendige Funktion mit irgendwelchem eigenen Parsing mehr noetig. |
| 118 | |
| 119 | Das @WER wird durch this_player()->Name() ersetzt, so dass man auch einen |
| 120 | Persoenlichen bezug in den Meldungen herstellen kann. |
| 121 | |
| 122 | Abwaertskompatibel |
| 123 | ------------------ |
| 124 | |
| 125 | Die Erweiterungen von AddCmd erlauben ein einfacheres Erstellen von |
| 126 | Standard-Kommandos, ohne dass man sich mit dem Parsen in Funktionen |
| 127 | beschaeftigen muss. |
| 128 | |
| 129 | Die Aenderung ist vollstaendig abwaertskompatibel. Wer sich also sagt, |
| 130 | das das alles viel zu kompliziert sei, kann weiterhin: |
| 131 | |
| 132 | AddCmd(({"pfluecke","ernte"}),"cmd_pfluecken"); |
| 133 | |
| 134 | benutzen. Das Verhalten ist haargenau das selbe wie bisher. Dementsprechend |
| 135 | ist auch kaum Aufwand beim Einpflegen dieser Aenderung notwendig. |
| 136 | |
| 137 | Zur Beachtung |
| 138 | ------------- |
| 139 | |
| 140 | Ueberall, wo direkt auf P_COMMANDS zugegriffen wird, kann es prinzipiell |
| 141 | zu Problemen kommen, da sich die Struktur des Mappings und der Zugriff |
| 142 | darauf geaendert hat. |
| 143 | |
| 144 | Im Folgeartikel findet sich eine Liste mit allen Objekten, die das machen. In |
| 145 | den oeffentlichen Verzeichnissen werde ich mich mit den Magiern in Verbindung |
| 146 | setzen oder selbst kontrollieren, ob Aenderungen notwendig sind. |
| 147 | |
| 148 | Objekte in den Players-Verzeichnissen werde ich nur in Ausnahmefaellen |
| 149 | anpassen. Zur Erinnerung: Angeschlossenes gehoert nicht nach /players/. |
| 150 | |
| 151 | Der Code ist auf Kompatibilitaet mit dem alten System ausgelegt, dennoch |
| 152 | gibt es ein paar Aenderungen. Zum Beispiel ist P_COMMANDS keine echte |
| 153 | Property mehr sondern eine lokale Variable. Demzufolge wird P_COMMANDS |
| 154 | bei "xprop" nicht mehr angezeigt. Die Schnittstelle wird durch _set_ |
| 155 | und _query_funktionen realisiert. Die Mappings werden _immer_ als Kopien |
| 156 | rausgegeben, so dass man damit nicht versehentlich Unsinn machen kann. |
| 157 | |
| 158 | Schlusswort |
| 159 | ----------- |
| 160 | |
| 161 | Dieser Artikel stellt nur eine Einleitung in die Aenderung und deren |
| 162 | Moeglichkeiten dar und ist keinesfalls vollstaendig. Wer mehr darueber wissen |
| 163 | will, ist eingeladen, sich die Manpage zu "AddCmd" und zu den Beispielen |
| 164 | "AddCmd_bsp" anzuschauen. |
| 165 | |
| 166 | Die Seiten sind aus dem Regenbogen "geliehen" und werden in den kommenden |
| 167 | Tagen noch auf die Beduerfnisse des Morgengrauen angepasst. |
| 168 | |
| 169 | Mein Dank geht an Gloinson, der die Idee hatte, die Anpassungen vorzunehmen |
| 170 | und Migration des Codes ins MorgenGrauen uebernommen hat. |
| 171 | |
| 172 | Falls nun noch Fragen sind, nur zu! :) |
| 173 | |
| 174 | V*, |