MG Mud User | 88f1247 | 2016-06-24 23:31:02 +0200 | [diff] [blame^] | 1 | Inhaltsverzeichnis: |
| 2 | |
| 3 | 1.. Kurzuebersicht der Files |
| 4 | 2.. Der Hausverwalter |
| 5 | 3.. Sonderrechte |
| 6 | 4.. Die Tools |
| 7 | 4a... Der Hausmeister |
| 8 | 4b... liste.c |
| 9 | 4c... haustool.c |
| 10 | 5.. Das Haus |
| 11 | 5a... Aussenansicht - haus.c |
| 12 | 5b... Die Raeume - raum.c |
| 13 | 5c... Der Eingangsraum - raum0.c |
| 14 | 5d... Die Truhe - truhe.c |
| 15 | 6.. Seherbank/Hauserwerb |
| 16 | 7.. Beschreibungen |
| 17 | 7a... Details/ReadDetails/Lang- und Kurzbeschreibung |
| 18 | 7b... Ausgaenge |
| 19 | 7c... Licht |
| 20 | 7d... Befehle |
| 21 | 8.. Rueckmeldungen |
| 22 | 9.. Hilfeseiten |
| 23 | |
| 24 | 1. Kurzuebersicht der Files |
| 25 | =========================== |
| 26 | |
| 27 | /d/seher/haeuser/ |
| 28 | |
| 29 | /* Am allerwichtigsten: */ |
| 30 | haus.h .................... Definitionen, die ueberall benutzt werden |
| 31 | access_rights.c ........... Die Leute mit Hauszugriff |
| 32 | |
| 33 | /* Keine Haeuser ohne Verwaltung */ |
| 34 | hausverwalter.c ........... Die Zentralstelle der Seherhaeuser |
| 35 | HAEUSER ................... Infos ueber Hausbesitzer (Wer, wo, wie gross) |
| 36 | |
| 37 | save/ |
| 38 | haeuser.o ................. Das Savefile des Hausverwalters |
| 39 | |
| 40 | tools/ .................... Sammelplatz fuer Tools zu den Haeusern |
| 41 | hausmeister.c ............. Verlegen, Abreissen, .c-Files erstellen |
| 42 | haus.apx .................. Fuer .c-File eines Hauses |
| 43 | liste.c ................... Zeigt geloeschte und ge-Wiz-te Hausbesitzer |
| 44 | haustool.c ................ (obsolete) |
| 45 | |
| 46 | /* Erwerb eines Hauses/Raumes */ |
| 47 | seherbank.c ............... Das Bankgebaeude |
| 48 | |
| 49 | queue.c ................... Die Schlangen vor den Schaltern |
| 50 | queue.h |
| 51 | |
| 52 | sb_antrag.c ............... Schalter zum Beantragen eines Vertrages |
| 53 | sb_einzahlung.c ........... Schalter zum Einzahlen einer Rate |
| 54 | sb_ausgabe.c .............. Schalter zum Abholen eines Hauses |
| 55 | |
| 56 | bausparvertrag.c .......... Auf dem Vertrag werden die Raten vermerkt |
| 57 | kommentar.c ............... Kommentare zum unklaren Vertragstext |
| 58 | |
| 59 | txt/ ...................... Hier stehen die eigentlichen Vertragstexte |
| 60 | vertrag.txt ............... a) fuer einen Haus-Vertrag |
| 61 | vertrag_raum.txt .......... b) fuer einen Ausbauvertrag |
| 62 | kommentar.txt ............. c) erklaerende Bemerkungen zu den Texten |
| 63 | |
| 64 | block.c ................... Der Block verwaltet die laufende Rate |
| 65 | /std/player/shadows/block_shadow.c |
| 66 | |
| 67 | traghaus.c ................ Das bekommt man am Ausgabeschalter |
| 68 | |
| 69 | log/ ...................... Logging der Bank, des Blocks, des Vertrages |
| 70 | |
| 71 | /* Die Haeuser selbst */ |
| 72 | virtual_compiler.c ........ Ordnet die Haeuser passend zu |
| 73 | haus.c .................... Die Aussenansicht des Hauses |
| 74 | raum.c .................... Allgemeine Funktionen der Raeume |
| 75 | raum0.c ................... Der Eingangsraum hat einige Zusatzfeatures |
| 76 | modules/ .................. Hilfsmodule: |
| 77 | haustuer.c ................ Beschreibung der Haustuer, Oeffnen/Schliessen |
| 78 | losa.c .................... Erweitertes Laden und Speichern der Raeume |
| 79 | usercmd.c ................. Alles fuer benutzerdefinierte Befehle |
| 80 | truhe.c ................... Die Truhe |
| 81 | |
| 82 | save/ |
| 83 | name.o .................... Savefile der Aussenansicht des Hauses |
| 84 | name0.o ................... Savefile von Raum 0 |
| 85 | usw. |
| 86 | name9.o ................... Savefile von Raum 9 |
| 87 | nametruhe.o ............... Savefile der Truhe |
| 88 | |
| 89 | special/ .................. Besondere Objekte |
| 90 | rj.c ...................... "Romeo und Julia" von Etain |
| 91 | rom_jul/ .................. Hier liegen die Seiten der Geschichte |
| 92 | seherfaq.c ................ Die Seher-FAQ von Ryne |
| 93 | faq/ ...................... Die Seiten der FAQ |
| 94 | |
| 95 | rep/ ...................... Hier landen die 'typo'-Meldungen der Haeuser |
| 96 | |
| 97 | doc/ ...................... Hilfeseiten (nach /doc/scmd kopieren) |
| 98 | hausbau ................... Allgemeine Informationen |
| 99 | seherhaus ........... |
| 100 | instanthaus ........ |
| 101 | |
| 102 | aendere ....... |
| 103 | ausgang ........ |
| 104 | befehl .......... |
| 105 | beschreibe ....... |
| 106 | erlaube ........... |
| 107 | kopiere ............ |
| 108 | licht ............... |
| 109 | loesche ................... Seiten zu den einzelnen Befehlen |
| 110 | meldungen ........... |
| 111 | notiz .............. |
| 112 | schiebe ........... |
| 113 | sperre ........... |
| 114 | spion ........... |
| 115 | uebersicht ..... |
| 116 | verbiete ...... |
| 117 | werfe ........ |
| 118 | |
| 119 | /sys/player/base.h .......... Hier ist "HAUSVERWALTER" definiert |
| 120 | |
| 121 | 2. Der Hausverwalter |
| 122 | ==================== |
| 123 | |
| 124 | Dies ist die Zentralstelle der Seherhaeuser. Hier werden wichtige Daten |
| 125 | der Hausbesitzer verwaltet, naemlich: |
| 126 | - der Ort, an dem das Haus steht |
| 127 | - die Zahl der zusaetzlichen Raeume, ueber die das Haus verfuegt |
| 128 | - die Leute, die im Haus Sonderrechte besitzen |
| 129 | |
| 130 | Die Funktionen des Hausverwalters werden von diversen Objekten aus auf- |
| 131 | gerufen. Im Einzelnen waeren da: |
| 132 | |
| 133 | secure() - intern |
| 134 | Sicherheitsabfrage fuer einige Funktionen des Hausverwalters. Zugelassen |
| 135 | sind EMs und die Leute, die im access_rights.c stehen, ausserdem das |
| 136 | Instanthaus (fuer NeuesHaus()) und der Ausgabeschalter (fuer NeuerRaum()). |
| 137 | |
| 138 | dump() - intern |
| 139 | Bringt die Datei "HAEUSER" auf den neuesten Stand (nachdem ein neues Haus |
| 140 | oder ein neuer Raum dazugekommen ist oder ein Haus verlegt bzw. geloescht |
| 141 | wurde). |
| 142 | |
| 143 | check_exits() - intern |
| 144 | Beim Verlegen und Abreissen von Haeusern ist es noetig, dass Ausgaenge in |
| 145 | Nachbarhaeuser entfernt werden. Dafuer sorgt diese Funktion. |
| 146 | |
| 147 | NeuesHaus() - traghaus.c |
| 148 | Ein neues Seherhaus wird geschaffen: es wird im ObjectDaemon angemeldet, |
| 149 | die Truhe wird im Eingangsraum plaziert, und die "HAEUSER"-Datei wird auf |
| 150 | den neuesten Stand gebracht. |
| 151 | Wenn Du zu Testzwecken ein Haus haben willst, kannst Du die Funktion auch |
| 152 | von Hand aufrufen. |
| 153 | |
| 154 | NeuerRaum() - sb_ausgabe.c |
| 155 | Einem Haus wird ein neuer Raum hinzgefuegt. |
| 156 | Maximal sind 10 Raeume (raum0-raum9) erlaubt. |
| 157 | |
| 158 | _LadeHaus() - virtual_compiler.c |
| 159 | Wenn der potentielle Besitzer wirklich ein Haus hat und sich dessen |
| 160 | Environment laden laesst, wird das Haus erstellt und zuruekgegeben. |
| 161 | |
| 162 | _LadeRaum() - virtual_compiler.c |
| 163 | Aehnlich wie _LadeHaus(), nur fuer den Raum mit der gewuenschten Nummer. |
| 164 | Beim Eingangsraum wird noch der Ausgang nach draussen gesetzt. |
| 165 | |
| 166 | FindeHaus() - hausverwalter.c, sb_antrag.c, hausmeister.c, /std/player/base.c |
| 167 | Gibt das Hausobjekt zurueck oder 0, falls der Spieler kein Haus hat. |
| 168 | Das Haus wird ggf. geladen. |
| 169 | |
| 170 | LoescheHaus() - hausmeister.c |
| 171 | Ein Haus wird abgerissen: Es wird im ObjectDaemon abgemeldet, saemtliche |
| 172 | Savefiles werden geloescht, ebenso das .rep-File des Hausbesitzers. |
| 173 | |
| 174 | Rueckgabewerte: |
| 175 | 1 - alles OK, das Haus ist weg |
| 176 | -1 - secure() schlug fehl. |
| 177 | |
| 178 | VerlegeHaus() - hausmeister.c |
| 179 | Ein Haus wird an einen neuen Ort verlegt: Es wird im ObjectDaemon ab- und |
| 180 | am neuen Ort wieder angemeldet, und der Ausgang nach draussen wird |
| 181 | angepasst. |
| 182 | |
| 183 | Rueckgabewerte: |
| 184 | 1 - alles Ok, das Haus steht jetzt woanders |
| 185 | -111 - secure() schlug fehl. |
| 186 | -1 - der angebliche Besitzer hat gar kein Haus |
| 187 | -2 - das Haus steht gar nicht da, wo es sein sollte |
| 188 | -3 - der Zielraum existiert nicht |
| 189 | -4 - im Zielraum kann nicht gebaut werden |
| 190 | -5 - es gibt Ausgaenge in benachbarte Seherhaeuser (diese werden beim |
| 191 | Verlegen nicht automatisch geloescht; das muss der Hausbesitzer |
| 192 | selbst machen) |
| 193 | |
| 194 | Unbebaubar() - hausverwalter.c, traghaus.c |
| 195 | Diese Funktion ermittelt, ob in einem Raum ein Haus gebaut werden kann, und |
| 196 | wenn nein, warum nicht. |
| 197 | |
| 198 | Rueckgabewerte: |
| 199 | 0 - OK, es darf gebaut werden |
| 200 | 1 - der Zielraum ist entweder ein geclontes Objekt (und damit zumindest |
| 201 | nach dem naechsten Reboot auf immer verloren) oder ein Objekt, dass |
| 202 | von einem virtual_compiler erzeugt wurde (der ObjectDaemon wird zu |
| 203 | einem Zeitpunkt abgefragt, an dem das VC-Objekt noch nicht seinen |
| 204 | endgueltigen Namen hat). |
| 205 | 2 - Im Zielraum ist P_INDOORS gesetzt (wenn in so einem Raum trotzdem |
| 206 | gebaut werden soll, weil es zum Beispiel eine grosse Hoehle o.ae. |
| 207 | ist, kann man P_INDORRS immer noch temporaer auf 0 setzen). |
| 208 | 3 - Im Zielraum ist P_HAUS_ERLAUBT nicht gesetzt. |
| 209 | |
| 210 | Erlaube() - raum0.c |
| 211 | Einem oder mehreren Spielern werden Sonderrechte im Haus eingeraeumt. |
| 212 | Zurueckgegeben wird die neue erlaube-Liste. |
| 213 | |
| 214 | Verbiete() - raum0.c |
| 215 | Einem oder mehreren Spielern werden die Rechte entzogen. |
| 216 | Zurueckgegeben wird die neue erlaube-Liste. |
| 217 | |
| 218 | HausProp() - haus.c, raum.c, raum0.c, sb_antrag.c, hausmeister.c |
| 219 | Mit dieser Funktion koennen die Informationen ueber einen Hausbesitzer |
| 220 | abgefragt werden. Moeglich sind: |
| 221 | HP_ENV - der Raum, in dem das Haus steht |
| 222 | HP_ROOMS - die Zahl der zusaetzlichen Raeume, ueber die das Haus verfuegt |
| 223 | HP_ALLOWED - Array mit den Leuten, die Sonderrechte geniessen |
| 224 | |
| 225 | PCrunch() - raum.c, losa.c, hausmeister.c |
| 226 | Um Platz beim Speichern zu sparen, werden Details, ReadDetails und Befehle, |
| 227 | die den gleichen Text ergeben, zusammengepackt. Beim Hausmeister hat das |
| 228 | den Effekt, dass im generierten Quelltext z.B. |
| 229 | AddDetail( ({ "foo", "bar" }), "blafasel\n"); |
| 230 | steht anstelle von |
| 231 | AddDetail( "foo", "blafasel\n"); |
| 232 | AddDetail( "bar", "blafasel\n"); |
| 233 | |
| 234 | 3. Sonderrechte |
| 235 | =============== |
| 236 | |
| 237 | Der Hausbesitzer kann von seinem Eingangsraum aus anderen Leuten Rechte in |
| 238 | seinem Haus einraeumen. Dazu dient der Befehl "erlaube". Leute mit Sonder- |
| 239 | rechten koennen: |
| 240 | - das Haus auf- und abschliessen |
| 241 | - die Truhe oeffnen (schliessen darf sie jeder) |
| 242 | - netztot im Haus bleiben |
| 243 | - Rueckmeldungen aus dem Reportfile ansehen (aber nicht aendern) |
| 244 | |
| 245 | Ausserdem muss man Sonderrechte in einem Nachbarhaus haben, wenn man von |
| 246 | seinem Haus einen Ausgang dorthin legen will. |
| 247 | |
| 248 | Das Array mit den Namen der Berechtigten erhaelt man vom Hausverwalter per |
| 249 | HausProp(<owner>, HP_ALLOWED). In dem Array stehen die User-IDs der Leute, |
| 250 | allerdings mit grossem Anfangsbuchstaben. |
| 251 | |
| 252 | 4. Die Tools |
| 253 | ============ |
| 254 | |
| 255 | 4a. Der Hausmeister |
| 256 | ------------------- |
| 257 | |
| 258 | Der Hausmeister erlaubt das einfache Abreissen und Verlegen von Haeusern |
| 259 | sowie das Generieren von LPC-Quelltext aus den Savefiles. Dazu stellt er |
| 260 | drei Kommandos zur Verfuegung: |
| 261 | |
| 262 | verlege <name> nach <ziel> |
| 263 | Das Haus des Spielers <name> wird in den Raum <ziel> verlegt. <ziel> ist |
| 264 | dabei entweder der Filename des Zielraumes oder "hier", wenn das Haus |
| 265 | zu Deinem aktuellen Standort verlegt werden soll. |
| 266 | Sollte das Verlegen fehlschlagen (siehe VerlegeHaus() im Hausverwalter) |
| 267 | meldet sich der Hausmeister entsprechend. |
| 268 | |
| 269 | reisse <name> ab |
| 270 | Das Haus des Spielers <name> wird abgerissen. |
| 271 | ACHTUNG! Es gibt keine Sicherheitsabfrage! |
| 272 | |
| 273 | generiere <name> [<nr>] [soft | ganz] |
| 274 | Generiert aus dem Savefile ein LPC-File. |
| 275 | Ohne Angabe einer Nummer wird die Aussenansicht generiert, ansonsten der |
| 276 | Raum mit der entsprechenden Nummer. |
| 277 | Ausser wenn "soft" angegeben wurde, werden die Dateien in das Verzeichnis |
| 278 | "rep/" geschrieben, und zwar als "<name>haus.c", "<name>raum0.c" etc. |
| 279 | Befindet sich die Truhe in dem generierten Raum, wird auch noch eine Datei |
| 280 | "<name>truhe.c" angelegt. |
| 281 | Die Dateien sind im wesentlichen fuer Magier gedacht, die ihre Haeuser als |
| 282 | LPC-Files unter Eigenregie weiterfuehren wollen/sollen. Ausgaenge sind |
| 283 | relativ zu "/players/<name>/seherhaus". |
| 284 | Mit dem Parameter "ganz" laesst sich das gesamte Haus auf einen Schlag |
| 285 | umwandeln. |
| 286 | "soft" stammt noch aus der Zeit, als ich die Typos der Seher selber fixen |
| 287 | musste. Das Haus oder der Raum wird dabei in die Datei PATH+"fixed.c" |
| 288 | geschrieben. |
| 289 | |
| 290 | 4b. liste.c |
| 291 | ----------- |
| 292 | |
| 293 | Ab und zu sollte man mal nachsehen, welche Seher sich geloescht haben oder |
| 294 | zu Magiern wurden. Die Haeuser von geloeschten Sehern sollten ebenfalls |
| 295 | geloescht werden; Magier koennen ihre Haeuser als normale LPC-Objekte |
| 296 | weiterfuehren (sobald die Level 21 oder 25 haben). |
| 297 | |
| 298 | Die Liste zeigt an, welche Leute betroffen sind. Dazu muss sie einfach nur |
| 299 | geladen werden. |
| 300 | |
| 301 | Zwei Ausnahmen gibt es: |
| 302 | - Krigi hat sich zwar geloescht, er hat aber darum gebeten, dass sein Haus |
| 303 | weiter bestehen kann (er ist jetzt Dauergast) |
| 304 | - Fraggle ist zwar Magier, hat sein Haus aber mal zu Testzwecken bekommen |
| 305 | |
| 306 | 4c. haustool.c |
| 307 | -------------- |
| 308 | |
| 309 | Dieses Teil ist mittlerweile ueberholt; es stammt noch aus der Zeit, als |
| 310 | 'typo'- und aehnliche Meldungen noch in meinem eigenen .rep-File landeten |
| 311 | und ich den Kram auch abarbeiten musste. Mit dem Tool konnte ich die Mel- |
| 312 | dungen aus meinem .rep-File ansehen und eine Benachrichtigung an den Haus- |
| 313 | besitzer generieren. |
| 314 | |
| 315 | |
| 316 | 5. Das Haus |
| 317 | =========== |
| 318 | |
| 319 | Das Haus selbst zerfaellt, was die Beschreibungen angeht, in drei grosse |
| 320 | Bereiche: den von aussen sichtbaren Teil, die Raeume im Inneren, und die |
| 321 | Truhe. Bei den Raeumen hat der Eingangsraum noch ein paar Sonderfunktionen. |
| 322 | |
| 323 | 5a. Aussenansicht |
| 324 | ----------------- |
| 325 | |
| 326 | Dies ist das Objekt, das im ObjectDaemon angemeldet wird ("<name>haus"). |
| 327 | Der Hausbesitzer kann folgende Eigenschaften beschreiben: |
| 328 | - die Langbeschreibung (P_LONG) |
| 329 | - eine Zeile, wie die Haustuer aussehen soll (H_DOOR) |
| 330 | - die Zustaende der Haustuer (offen, geschlossen, abgeschlossen; H_DOORLSTAT) |
| 331 | |
| 332 | Ausserdem stehen folgende Kommandos zur Verfuegung: |
| 333 | - betritt/betrete <haus> |
| 334 | Sollte klar sein. Geht nur, wenn das Haus offen ist. |
| 335 | - klopfe an <haus> an |
| 336 | Das Klopfen hoert man im ganze Haus |
| 337 | - notiz <text> |
| 338 | Der Hausbesitzer kann damit eine kurze Notiz an der Haustuer anbringen. |
| 339 | |
| 340 | modules/haustuer.c stellt die Befehle zum Oeffnen und Schliessen des Hauses |
| 341 | zur Verfuegung. Aufgeschlossen werden kann das Haus nur von Leuten mit |
| 342 | spezieller Genehmigung. |
| 343 | |
| 344 | Wenn die Kurzbeschreibung geaendert werden soll, muss das ein Magier machen. |
| 345 | Offizieller Ansprechpartner dafuer ist der Hausmaintainer (also DU :-) |
| 346 | Man sollte dabei darauf achten, dass die Beschreibung a) in die Umgebung und |
| 347 | b) allgemein in eine Fantasywelt passt (das ist leider nicht bei allen |
| 348 | Haeusern der Fall...) |
| 349 | Wenn die Kurzbeschreibung geaendert wird, sollten ggf. auch noch die IDs, der |
| 350 | Name und das Geschlecht angepasst werden. |
| 351 | Um ein Haus unsichtbar zu machen, muss P_SHORT auf 0 gesetzt werden. |
| 352 | Wenn noch andere Seherhaeuser im gleichen Raum stehen, und in der Beschrei- |
| 353 | bung des geaenderten Hauses nichts mehr auf ein "haus" hinweist, kann und |
| 354 | sollte die ID "haus" entfernt werden. |
| 355 | Um die Aenderungen zu sichern, muss im Haus Save() aufgerufen werden. |
| 356 | |
| 357 | Zwei IDs sollten nie entfernt werden: "sehe\rhaus" und "\n<name>haus" |
| 358 | |
| 359 | |
| 360 | 5b. Die Raeume |
| 361 | -------------- |
| 362 | |
| 363 | Programmtechnisch befinden sich hier hauptsaechlich Funktionen zum Beschrei- |
| 364 | ben des Raumes, Hinzufuegen und Entfernen des Lichtes, An- und Abschalten |
| 365 | des Lichtes und Einsehen des .rep-Files. |
| 366 | Ausserdem kann man Personen, Gegenstaende oder alles aus dem Haus werfen. |
| 367 | |
| 368 | Auch die Raeume haben die ID "sehe\rhaus". |
| 369 | |
| 370 | Erwaehnenswerte Funktionen: |
| 371 | |
| 372 | normstr() |
| 373 | Ersetzt @@ in den Beschreibungen durch ** (damit kein process_string() |
| 374 | ausgefuehrt werden kann) |
| 375 | |
| 376 | brk() |
| 377 | Erzeugt aus einer durch Kommata getrennten Liste ein Array von Strings |
| 378 | |
| 379 | befCheck() |
| 380 | Faengt verbotene Befehle ab (Kommandos, die Leerzeichen enthalten; nicht |
| 381 | gesetzte Ausgaenge; alle Kommandos, die der Raum definiert, ausser |
| 382 | "oeffne", "schliess", "schliesse") |
| 383 | |
| 384 | owner_check() |
| 385 | Darf der Spieler das? Falls ohne Argument aufgerufen, ist die Aktion nur |
| 386 | erlaubt, wenn this_player() der Hausbesitzer ist. |
| 387 | Mit Argument wird auch die erlaube-Liste geprueft. |
| 388 | |
| 389 | arr_out() |
| 390 | Gibt ein Array von Strings aus oder zurueck, je nach Anwendung |
| 391 | |
| 392 | clean_up() |
| 393 | Sorgt dafuer, dass nur leere Raeume weggeraeumt werden |
| 394 | |
| 395 | BecomesNetDead() |
| 396 | Netztote verlassen das Haus (soweit sie nicht auf der erlaube-Liste stehen) |
| 397 | |
| 398 | init()/int_long() |
| 399 | Meldungen ueber unsichtbare Magier |
| 400 | |
| 401 | lies() |
| 402 | ReadDetails werden mit More() ausgegeben |
| 403 | |
| 404 | Die Befehle zur Beschreibung darf nur der Hausbesitzer benutzen. Den Befehl |
| 405 | "uebersicht" koennen auch die Magier, die im access_rights.c stehen, ver- |
| 406 | wenden. |
| 407 | Naeheres zu den moeglichen Beschreibungen folgen unten. |
| 408 | |
| 409 | |
| 410 | 5c. Der Eingangsraum |
| 411 | -------------------- |
| 412 | |
| 413 | Der Eingangsraum stellt zusaetzlich noch folgende Befehle und Moeglichkeiten |
| 414 | zur Verfuegung: |
| 415 | |
| 416 | - Oeffnen, Schliessen und Abschliessen des Hauses von innen |
| 417 | - Einraeumen und Entziehen von Sonderrechten mit "erlaube" und "verbiete" |
| 418 | - Benutzen des Gucklochs in der Tuer mit dem Befehl "spion" |
| 419 | - Mitteilung ueber angesammelte 'typo'-Meldungen seit dem letzten Betreten |
| 420 | - "uebersicht" zeigt zusaetzlich die Leute auf der erlaube-Liste |
| 421 | |
| 422 | |
| 423 | 5d. Die Truhe |
| 424 | ------------- |
| 425 | |
| 426 | Die Truhe kann unendlich viele Gegenstaende aufnehmen. |
| 427 | Aendern lassen sich Geschlecht, Name, Adjektive (aus diesen dreien wird die |
| 428 | Kurzbeschreibung zusammengesetzt), IDs, Langbeschreibung und Material. |
| 429 | Die ID "\t\ruhe" ist IMMER gesetzt. |
| 430 | Die Truhe laesst sich innerhalb des Hauses frei verschieben. In dem Raum, |
| 431 | in dem sie steht, ist die Property H_CHEST auf 1 gesetzt. |
| 432 | Typomeldungen der Truhe gehen in das Reportfile des Hausbesitzers. |
| 433 | |
| 434 | Problem: Ab und zu geben einige Spezialisten bei der Beschreibung der IDs |
| 435 | schon die Langbeschreibung ein. Danach koennen sie die Truhe nicht mehr |
| 436 | ansprechen. |
| 437 | Loesung: Von Hand eine ID setzen und die Truhe mit Save() speichern. |
| 438 | |
| 439 | Ideen: Zustand der Truhe (geoeffnet/geschlossen) beschreibbar machen und |
| 440 | optional ganz weglassen. Machbar ueber H_DOORLSTAT. In short() sind schon |
| 441 | die entsprechenden Vorkehrungen getroffen; "beschreibe truhe status" wird |
| 442 | auch schon abgefragt, aber noch nicht ausgewertet. Ausserdem muesste die |
| 443 | Kurzbeschreibung dann explizit angegeben werden. |
| 444 | |
| 445 | Oeffnen koennen die Truhe nur Leute mit Erlaubnis. Schliessen kann sie |
| 446 | jeder. Verschieben kann sie nur der Hausbesitzer. |
| 447 | |
| 448 | Die Daten der Truhe werden in _set_owner() geladen. Dieser Funktion wiederum |
| 449 | wird von dem Raum aufgerufen, in dem die Truhe steht (modules/losa::Load()). |
| 450 | |
| 451 | |
| 452 | 6. Seherbank/Hauserwerb |
| 453 | ======================= |
| 454 | |
| 455 | Die Bank steht in Drachenhort. Wesentliche Bestandteile sind drei Schalter |
| 456 | mit entsprechenden Warteschlangen. |
| 457 | |
| 458 | Der Antragsschalter - sb_antrag.c |
| 459 | Hier erhaelt man die Vertraege fuer ein Haus oder einen neuen Raum. Einen |
| 460 | Ausbauvertrag bekommt man allerdings erst dann, wenn das Haus schon steht. |
| 461 | Vertraege werden nur an Seher ausgehaendigt, die keinen PK haben. |
| 462 | |
| 463 | Der Vertrag - bausparvertrag.c |
| 464 | Erhaeltlich am Antragsschalter. |
| 465 | Der Vertrag muss auch am Antragsschalter unterschrieben werden. Die Unter- |
| 466 | schrift wird mit Blut bestaetigt, wodurch ein reduce_hit_point(50) faellig |
| 467 | wird. ;) |
| 468 | Auf ihm wird jede eingezahlte Rate vermerkt. |
| 469 | Will man doch kein Haus, kann man den Vertrag jederzeit zerreissen. Die |
| 470 | eingezahlten EP sind dann allerdings weg. |
| 471 | Nach der Unterschrift bekommt man den Master-Block ueberreicht. |
| 472 | |
| 473 | Der Master-Block - block.c |
| 474 | Der Block nimmt die aktuellen Raten auf. Dazu dient der block_shadow |
| 475 | (in /std/player/shadows/), der immer dann aktiviert wird, wenn man den |
| 476 | Block anzieht (er ist eine AT_MISC-Ruestung, schuetzt also nicht). |
| 477 | Der Shadow leitet AddExp()-Aufrufe an dem Block um. Bei mindestens |
| 478 | 30-40 EP wird alles bis auf den Mindestanteil auf den Block eingezahlt, |
| 479 | und der Mindestanteil kommt dem Spieler zugute. |
| 480 | |
| 481 | Der Einzahlungsschalter - sb_einzahlung.c |
| 482 | Ist die Master-Block voll, kann man ihn hier vorlegen. Die Rate wird dann |
| 483 | auf den Vertrag gebucht, und man bekommt einen neuen Block fuer die |
| 484 | naechste Rate (soweit man noch nicht fertig ist). |
| 485 | |
| 486 | Der Ausgabeschalter - sb_ausgabe.c |
| 487 | Hat man alle Raten eingezahlt, kann man hier nach Vorlage des Vertrags die |
| 488 | Fruechte seiner Arbeit ernten. |
| 489 | Handelte es sich um einen Hausvertrag, bekommt man ein Instanthaus ausge- |
| 490 | haendigt. |
| 491 | Handelte es sich um einen Ausbauvertrag, wird die Raumzahl des Hauses um |
| 492 | eins erhoeht (man bekommt kein Objekt in die Hand; vielmehr kann man in |
| 493 | seinem Haus jetzt einen Ausgang in den neuen Raum legen). |
| 494 | ALLERDINGS: Um Haus oder Raum auszugeben, muessen in der Zentralbank |
| 495 | mindestens 30000 Muenzen vorhanden sein (damit deckt die Seherbank die |
| 496 | Materialkosten). Solange nicht genug Geld da ist, gibts auch kein Haus. |
| 497 | Der Seher hat zwei Alternativen: a) warten, bis genug Geld da ist, oder |
| 498 | b) zum Ende der Welt reisen und das Geld in den Geldspeicher der Zentral- |
| 499 | bank werfen. |
| 500 | |
| 501 | Eine Rate umfasst 80000 EP. |
| 502 | Es gibt zwei Vertragsvarianten: sanft und schnell. |
| 503 | Bei der sanften Variante hat man 4 Stunden Zeit, um die Rate zu sammeln, bei |
| 504 | der schnellen Variante sind es 2 Stunden. |
| 505 | Diese Zeiten werden nach Online-Zeit gemessen, nicht nach RL-Zeit. :) |
| 506 | Fuer ein Haus benoetigt man bei den sanften Variante 30 Raten, bei der |
| 507 | schnellen Variante 25 Raten. |
| 508 | Fuer einen Raum sind es 12 Raten bei der sanften und 10 Raten bei der |
| 509 | schnellen Variante. |
| 510 | Ueberzieht man die Zeit, erhoeht sich die Ratenhoehe um 60% auf 128000 EP. |
| 511 | Man hat bei beiden Varianten eine Stunde Zeit, die Rate noch zu erfuellen. |
| 512 | Schafft man es nicht, verfaellt der Vertrag => alles ist weg. |
| 513 | Das Zeitlimit gilt nur fuer das Fuellen des Blocks. Wenn er erst man voll |
| 514 | ist, braucht man nicht innerhab des Limits zur Bank, um den naechsten |
| 515 | Block zu holen. |
| 516 | |
| 517 | 7. Beschreibungen |
| 518 | ================= |
| 519 | |
| 520 | Folgende Aspekte der Raumbeschreibung lassen sich veraendern: |
| 521 | |
| 522 | - Details "beschreibe detail <det>" P_DETAILS |
| 523 | - ReadDetails "beschreibe lesbares detail <det>" P_READ_DETAILS |
| 524 | - Langbeschr. "beschreibe haus/raum lang" (auch aussen) P_(INT_)LONG |
| 525 | - Kurzbeschr. "beschreibe haus/raum kurz" P_INT_SHORT |
| 526 | - Ausgaenge "ausgang <richtung> <nr>" / "sperre richtung" P_EXITS |
| 527 | - Licht "licht an/aus" P_LIGHT |
| 528 | - Befehle "beschreibe befehl <bef>" H_COMMANDS |
| 529 | |
| 530 | Details, ReadDetails und Befehle lassen sich auch kopieren, allerdings immer |
| 531 | nur innerhalb der jeweiligen Propertygruppe (es laesst sich also kein Detail |
| 532 | zu den ReadDetails kopieren). |
| 533 | |
| 534 | Ausserdem lassen sich Details, ReadDetails, Befehle und die Langbeschreibung |
| 535 | aendern. Das laeuft aehnlich wie beim Beschreiben, allerdings wird der |
| 536 | aktuell vorhandene Text als Vorgabe verwendet. |
| 537 | |
| 538 | |
| 539 | 7a. Details/ReadDetails/Lang- und Kurzbeschreibung |
| 540 | -------------------------------------------------- |
| 541 | |
| 542 | Hier passiert nicht viel mit dem eingegebenen Text. @@ werden durch ** |
| 543 | ersetzt, damit nicht aus Versehen oder beabsichtigt process_string() |
| 544 | ausgeloest wird. |
| 545 | |
| 546 | Bei der Kurzbeschreibung wird noch geprueft, ob sie laenger als 75 Zeichen |
| 547 | oder eine Zeile ist (falls ja, wird sie nicht uebernommen). |
| 548 | |
| 549 | Moegliche Erweiterungen: Rassenspezifische Details (das muss bisher ueber |
| 550 | Bfehle gemacht werden), und da AddSmells()/AddSounds() jetzt "offiziell" in |
| 551 | sind, vielleicht auch die Moeglichkeit, Gerueche und Geraeusche zu |
| 552 | beschreiben. |
| 553 | |
| 554 | 7b. Ausgaenge |
| 555 | ------------- |
| 556 | |
| 557 | Moegliche Ausgaenge sind die acht Himmelsrichtungen, "oben" und "unten". |
| 558 | Legt man einen Ausgang an, wird automatisch im Zielraum ein Ausgang in die |
| 559 | entsprechende Rueckrichtung angelegt. |
| 560 | Das Anlegen klappt nur, wenn es noch keinen Ausgang in diese Richtung gibt, |
| 561 | und im Zielraum noch keinen Ausgang in die Rueckrichtung. |
| 562 | Soll ein Ausgang in ein benachbartes Seherhaus gelegt werden, muss man dort |
| 563 | darueberhinaus auf der erlaube-Liste stehen. |
| 564 | Beim Sperren eines Ausgangs wird der entsprechende Ausgang im Zielraum |
| 565 | automatisch mit entfernt. |
| 566 | |
| 567 | Der Grund fuer dieses symmetrische Verhalten liegt darin, dass man auf diese |
| 568 | Weise keine Spieler in seinem Haus einsperren kann (Ausgang in einen Raum, |
| 569 | ohne dass es zurueck geht). |
| 570 | Um die Ausgaenge einander einfach zuordnen zu koennen, sind auch keine selbst |
| 571 | erfundenen Richtungen moeglich (koennte man allerdings implementieren, indem |
| 572 | man explizit nach der Rueckrichtung fragt). |
| 573 | |
| 574 | |
| 575 | 7c. Licht |
| 576 | --------- |
| 577 | |
| 578 | P_LIGHT wird so gesetzt, dass es im Haus mit dem momentanen Lichtlevel gerade |
| 579 | dunkel oder hell wird. Hat man also nen Gesamtlichtlevel von 20 (durch |
| 580 | genuegend Lichtkugeln o.ae.) und macht "licht aus", wird P_LIGHT auf -20 |
| 581 | gesetzt. |
| 582 | |
| 583 | |
| 584 | 7d. Befehle |
| 585 | ----------- |
| 586 | |
| 587 | Um die Auswertung zu vereinfachen, werden die Platzhalter in den Befehls- |
| 588 | texten in kuerzere Token umgewandelt (Funktion preparse()). |
| 589 | Die Auswertung erfolgt von modules/usercmd.c aus. |
| 590 | |
| 591 | In preparse() werden im wesentlichen die Faelle fuer Namen, Personal- und |
| 592 | Possessivpronomina in die Zahlen umgesetzt, die den entsprechenden |
| 593 | Funktionen (name(), QueryPronoun(), QueryPossPronoun()) uebergeben werden. |
| 594 | Ausgewertet werden sie von usercmd::ucFilter(). |
| 595 | |
| 596 | Die Auswertung rassenspezifischer Texte muss angepasst werden, wenn neue |
| 597 | Rassen ins MG kommen. Betroffen davon ist usercmd::ucText(). |
| 598 | Die rassenspezifischen Texte werden durch Platzhalter der Form @RX vonein- |
| 599 | ander getrennt, wobei X ein Buchstabe fuer die Rasse ist. |
| 600 | Bei einer neuen Rasse muesste dieser Buchstabe in der regexplode-Zeile am |
| 601 | Anfang von ucText() in den eckigen Klammern eingefuegt werden, und eine |
| 602 | entsprechende Abfrage in die switch()-Anweisung rein. |
| 603 | Und natuerlich sollte die Hilfeseite ("befehl") geupdated werden :) |
| 604 | |
| 605 | Bisher sind reine Textausgabebefehle moeglich. |
| 606 | Einige Seher haben sich weitere Moeglichkeiten gewuenscht, z.B. so etwas |
| 607 | wie SpecialDetails oder SpecialExits. Dafuer muesste man Zustaende setzen |
| 608 | und aendern koennen (Property H_VARS oder so?). Allerdings wird dadurch |
| 609 | die Beschreibung an sich wieder komplizierter. |
| 610 | |
| 611 | |
| 612 | 8. Rueckmeldungen |
| 613 | ================= |
| 614 | |
| 615 | Die Raeume, die Aussenansicht des Hauses und die Truhe haben eine Funktion |
| 616 | SmartLog(). Diese Funktion wird von /std/player/base::smart_log() aus auf- |
| 617 | gerufen und uebernimmt das Loggen der Typo-, Idee- und Fehlermeldungen. |
| 618 | Die Meldungen werden int "rep/<name>.rep" abgelegt. |
| 619 | Der Hausbesitzer wird jeweils beim Betreten des Eingangsraumes informiert, |
| 620 | wie viele Rueckmeldungen sich seit dem letzten Betreten angesammelt haben. |
| 621 | Ansehen kann er sich die Meldungen mit dem Befehl "meldungen", und mit |
| 622 | "aendere" oder "beschreibe" kann er die Typos beheben. |
| 623 | Mit "aendere meldungen" kann er die abgearbeiteten Meldungen aus seinem |
| 624 | .rep-File entfernen. |
| 625 | |
| 626 | |
| 627 | 9. Hilfeseiten |
| 628 | ============== |
| 629 | |
| 630 | Die "Arbeitsversionen" der Seiten liegen in doc/, die "offiziellen" Versionen |
| 631 | in /doc/scmd. |
| 632 | "beschreibe befehl" hat eine Extraseite ("hilfe befehl"), weil die Seite fuer |
| 633 | "beschreibe" sonst zu gross waere. |