MG Mud User | 88f1247 | 2016-06-24 23:31:02 +0200 | [diff] [blame^] | 1 | NAME: |
| 2 | P_HARBOUR "harbour_name" |
| 3 | |
| 4 | DEFINIERT IN: |
| 5 | /sys/transport.h |
| 6 | |
| 7 | BESCHREIBUNG: |
| 8 | Array mit eindeutiger Bezeichnung des 'Hafens' |
| 9 | |
| 10 | BEMERKUNGEN: |
| 11 | Diese Property wird in Raeumen gesetzt, die als Anleger fuer Transporter |
| 12 | dienen sollen. Sie enthaelt ein Array aus zwei Elementen, einem String |
| 13 | und einem String-Array, zum Beispiel: |
| 14 | |
| 15 | ({ "zur Sonneninsel", ({"sonneninsel"}) }) oder |
| 16 | ({ "nach Titiwu", ({"titiwu"}) }) |
| 17 | |
| 18 | Damit bekommt der Spieler bei einer Abfrage seiner Reiseroute mittels |
| 19 | "reise route" eine Ausgabe wie |
| 20 | 'Du reist mit dem Floss nach Titiwu' oder |
| 21 | 'Du reist mit dem Wal zur Sonneninsel'. |
| 22 | |
| 23 | Das zweite Element der Property enthaelt eine Liste der IDs, mit denen |
| 24 | sich der Hafen mit dem Befehl "reise nach <ID>" ansprechen laesst. Im |
| 25 | Beispiel oben wuerde also "reise nach sonneninsel" und |
| 26 | "reise nach titiwu" akzeptiert werden. Der erste Eintrag in dieser ID- |
| 27 | Liste wird in der Ausgabe des Befehls "reise route" verwendet, sollte |
| 28 | also den Anlegeort korrekt bezeichnen und nicht z.B. eine Abkuerzung |
| 29 | enthalten. |
| 30 | Es bietet sich an, bei bestimmten, deklinierbaren Bezeichnungen alle |
| 31 | Varianten einzutragen, z.B. "verlorenes land" und zusaetzlich |
| 32 | "verlorene land" und "verlorenen land", damit alle Varianten von |
| 33 | "reise nach ..." funktionieren. |
| 34 | |
| 35 | Ist in einem Hafen diese Property nicht gesetzt, so bekommt der |
| 36 | Spieler keinerlei Hinweis darauf, wohin ihn ein bestimmter Trans- |
| 37 | porter befoerdert. |
| 38 | Stattdessen erhaelt er die Bezeichnung 'unbekannt'. |
| 39 | |
| 40 | HINWEISE: |
| 41 | Wird der zweite Parameter in dieser Property, d.h. die Liste der |
| 42 | Anleger-IDs, nicht korrekt gesetzt, kann das dazu fuehren, dass Spieler |
| 43 | den hier anlegenden Transporter nicht benutzen koennen, weil es |
| 44 | keine sinnvolle Syntax gibt, um den gewuenschten Zielhafen zu finden. |
| 45 | |
| 46 | Zu achten ist auch darauf, das der erste Eintrag unveraendert in einer |
| 47 | Meldung an den Spieler ausgegeben wird, d.h. Gross-und Kleinschreibung |
| 48 | sollte korrekt sein. |
| 49 | |
| 50 | HISTORIE: |
| 51 | Frueher war der zweite Eintrag in dieser Property ein einzelner String. |
| 52 | Es existiert eine SetMethode auf dieser Property, die solche Daten in |
| 53 | altem Code auf die neue Datenstruktur umbiegt. Dies fuehrt dazu, dass |
| 54 | bei solchen Objekten die im geladenen Raum enthaltenen Daten nicht mit |
| 55 | den Daten im File uebereinstimmen. Dies moege aber bitte niemand |
| 56 | zum Anlass nehmen, in neuem Code veraltete Daten in die Property zu |
| 57 | schreiben! |
| 58 | |
| 59 | SIEHE AUCH: |
| 60 | Properties: P_NO_TRAVELING, P_TRAVEL_INFO |
| 61 | Funktionen: AddRoute(L) |
| 62 | Spielerbefehle: reise |
| 63 | weitere Doku: /d/inseln/schiffe/HowTo |
| 64 | |
| 65 | LETZTE AENDERUNG: |
| 66 | 2015-Jan-18, Arathorn |