| MG Mud User | 88f1247 | 2016-06-24 23:31:02 +0200 | [diff] [blame] | 1 | Was sind 'virtuelle Objekte'? |
| 2 | ============================= |
| 3 | Virtuelle Objekte sind Objekte fuer die es keine explizite Quelldatei gibt. |
| 4 | Ansonsten sind die Objekte (fast) genauso wie alle anderen auch. |
| 5 | |
| 6 | Was macht ein Virtual Compiler? |
| 7 | =============================== |
| 8 | Wenn der Driver ein Objekt "/pfad/objekt" laden soll, guckt er erstmal nach, |
| 9 | ob es so ein File (/pfad/objekt.c) auf der Platte gibt. Wenn ja, laedt er es |
| 10 | ganz normal. Wenn nicht, passiert folgendes: |
| 11 | |
| 12 | 1. Der Driver fragt den Master der Mudlib nach dem Objekt. |
| 13 | 2. Der Master guckt im Verzeichnis "/pfad/" nach, ob es ein virtual_compiler.c |
| 14 | dort gibt. Wenn ja, wird dieses virtual_compiler.c gefragt, ob es sich |
| 15 | dafuer zustaendig fuehlt, ein Objekt mit dem Namen "/pfad/objekt" zu |
| 16 | erzeugen. |
| 17 | 3. Wenn sich der VC fuer zustaendig fuehlt, clont er ein Objekt (z.B. sein |
| 18 | Standardobjekt, "stdob.c"), konfiguriert es evtl. noch ein bisschen und |
| 19 | gibt es an den Master zurueck. Das erzeugte Objekt heisst an dieser Stelle |
| 20 | z.B. "/pfad/stdob#42" (weil es ein Clon von "/pfad/stdob" ist). |
| 21 | 4. Der Master gibt dieses erzeugte Objekt an den Driver zurueck. |
| 22 | 5. Der Driver benennt das vom Master erhaltene Objekt "/pfad/stdob#42" um in |
| 23 | das gewuenschte Objekt "/pfad/objekt". Von diesem Moment an ist es, als ob |
| 24 | es ein File "/pfad/objekt.c" gaebe, was dieses Objekt definiert. |
| 25 | |
| 26 | Das ist grundsaetzlich das, was ein VC macht. |
| 27 | |
| 28 | Was macht der VC in /std/? |
| 29 | ========================== |
| 30 | Erstmal das oben beschriebene. Fuer welchen Pfad sich dieser VC zustaendig |
| 31 | fuehlt und welches Objekt er jeweils clonen soll, wird per P_COMPILER_PATH und |
| 32 | P_STD_OBJECT konfiguriert. |
| 33 | Zusaetzlich fuehrt er besagte Liste seiner erzeugten Objekte, damit bei einem |
| 34 | 'ls' auf das Verzeichnis diese Objekte mit angezeigt werden. |
| 35 | Weiterhin zerstoert er alle diese Objekte in seinem eigenen Remove. |
| 36 | Ausserdem hat er 2 Funktionen, mit denen er entscheiden kann, ob er fuer ein |
| 37 | bestimmtes angefragtes Objekt zustaendig ist, Validate() und |
| 38 | QueryValidObject() und eine Funktion CustomizeObject(), die einem frisch |
| 39 | geclonten Objekt sagen kann, welchen Namen es spaeter einmal haben soll (s. |
| 40 | jeweilige Manapages). |
| 41 | |
| 42 | Wie baut man sich seinen eigenen VC? |
| 43 | ==================================== |
| 44 | Sagen wir, ihr wollt einen VC bauen, der jedem Spieler seinen eigenen Raum |
| 45 | gibt, damit jeder Spieler in diesem Raum ein Monster allein erlegen muss, |
| 46 | ohne dass andere Spieler mit drin sind. |
| 47 | Dann braucht ihr zuerst mal einen Raum, der die Vorlage fuer alle VC-Raeume |
| 48 | sein soll, z.B. std_arena.c. Diesen legt ihr in das Verzeichnis, wo der VC hin |
| 49 | soll, z.B. /d/region/magier/vc/. |
| 50 | In diesem Verzeichnis legt ihr nun ein File virtual_compiler.c an, welches |
| 51 | /std/virtual/v_compiler erbt. |
| 52 | Im create() setzt ihr nun P_COMPILER_PATH auf "/d/region/magier/vc/" und |
| 53 | P_STD_OBJECT auf "/d/region/magier/vc/std_arena". |
| 54 | Soll euer VC keine Para-Raeume erzeugen, setzt ihr P_PARA auf ({}). |
| 55 | Sodann muesst ihr ein Validate() formulieren (s. Manpage), welches prueft, ob |
| 56 | ein spaeter gewuenschtes Objekt den richtigen Namen (ohne Pfad) hat, z.B. |
| 57 | 'arena|spielername' und in diesem Fall genau diesen Namen zurueckliefert und |
| 58 | in anderen Faellen 0. |
| 59 | Das wars. Zumindest in diesem einfachen Fall seid ihr im wesentlichen fertig. |
| 60 | Ihr koennt einen Spieler nun mit |
| 61 | pl->move("/d/region/magier/vc/arena|spielername",M_GO) |
| 62 | in 'seinen' persoenlichen Raum bewegen. |
| 63 | |
| 64 | Bitte beachtet allerdings noch die Hinweise und Beschreibungen in den Manpages |
| 65 | zu den einzelnen Funktionen und Properties. |
| 66 | |
| 67 | |
| 68 | Beispiele: |
| 69 | ========== |
| 70 | 1. /doc/beispiele/virtual/zesstra/virtual_compiler.c |
| 71 | VC, der jedem Spieler einen eigenen Raum gibt. Da hier der Inhalt aller |
| 72 | Raeume gleich ist (alle Spieler sollen gleiche Bedingungen haben), ist |
| 73 | keine Konfigurierung mit Hilfe von CustomizeObject() noetig. |
| 74 | |
| 75 | 2. /doc/beispiele/virtual/hate/vr_compiler.c |
| 76 | Dies ist ein Beispiel fuer einen sehr allgemeinen VC, der es |
| 77 | erlaubt anzugeben in welchem Bereich sich die x und y Koordinaten befinden |
| 78 | und dann Raeume erzeugt, welche Ausgaenge in alle vier Himmelsrichtungen |
| 79 | haben. |
| 80 | |
| 81 | ----------------------------------------------------------------------------- |
| 82 | 27.10.2007, Zesstra |