Automatisch erzeugte Manpages.
Damit nicht jeder sphinx auf dem Rechner haben muss,
behalten wir bis auf weiteres die aus den .rst
erzeugten Manpoages auch im Repo.
Change-Id: Id556c0d11cf5f79659d8350952ce1c014d81ea44
diff --git a/doc/props/P_HARBOUR b/doc/props/P_HARBOUR
index c0e1048..f049847 100644
--- a/doc/props/P_HARBOUR
+++ b/doc/props/P_HARBOUR
@@ -1,66 +1,94 @@
-NAME:
- P_HARBOUR "harbour_name"
-DEFINIERT IN:
- /sys/transport.h
+P_HARBOUR
+*********
-BESCHREIBUNG:
- Array mit eindeutiger Bezeichnung des 'Hafens'
-BEMERKUNGEN:
- Diese Property wird in Raeumen gesetzt, die als Anleger fuer Transporter
- dienen sollen. Sie enthaelt ein Array aus zwei Elementen, einem String
- und einem String-Array, zum Beispiel:
+NAME
+====
- ({ "zur Sonneninsel", ({"sonneninsel"}) }) oder
- ({ "nach Titiwu", ({"titiwu"}) })
+ P_HARBOUR "harbour_name"
- Damit bekommt der Spieler bei einer Abfrage seiner Reiseroute mittels
- "reise route" eine Ausgabe wie
- 'Du reist mit dem Floss nach Titiwu' oder
- 'Du reist mit dem Wal zur Sonneninsel'.
- Das zweite Element der Property enthaelt eine Liste der IDs, mit denen
- sich der Hafen mit dem Befehl "reise nach <ID>" ansprechen laesst. Im
- Beispiel oben wuerde also "reise nach sonneninsel" und
- "reise nach titiwu" akzeptiert werden. Der erste Eintrag in dieser ID-
- Liste wird in der Ausgabe des Befehls "reise route" verwendet, sollte
- also den Anlegeort korrekt bezeichnen und nicht z.B. eine Abkuerzung
- enthalten.
- Es bietet sich an, bei bestimmten, deklinierbaren Bezeichnungen alle
- Varianten einzutragen, z.B. "verlorenes land" und zusaetzlich
- "verlorene land" und "verlorenen land", damit alle Varianten von
- "reise nach ..." funktionieren.
+DEFINIERT IN
+============
- Ist in einem Hafen diese Property nicht gesetzt, so bekommt der
- Spieler keinerlei Hinweis darauf, wohin ihn ein bestimmter Trans-
- porter befoerdert.
- Stattdessen erhaelt er die Bezeichnung 'unbekannt'.
+ /sys/transport.h
-HINWEISE:
- Wird der zweite Parameter in dieser Property, d.h. die Liste der
- Anleger-IDs, nicht korrekt gesetzt, kann das dazu fuehren, dass Spieler
- den hier anlegenden Transporter nicht benutzen koennen, weil es
- keine sinnvolle Syntax gibt, um den gewuenschten Zielhafen zu finden.
- Zu achten ist auch darauf, das der erste Eintrag unveraendert in einer
- Meldung an den Spieler ausgegeben wird, d.h. Gross-und Kleinschreibung
- sollte korrekt sein.
+BESCHREIBUNG
+============
-HISTORIE:
- Frueher war der zweite Eintrag in dieser Property ein einzelner String.
- Es existiert eine SetMethode auf dieser Property, die solche Daten in
- altem Code auf die neue Datenstruktur umbiegt. Dies fuehrt dazu, dass
- bei solchen Objekten die im geladenen Raum enthaltenen Daten nicht mit
- den Daten im File uebereinstimmen. Dies moege aber bitte niemand
- zum Anlass nehmen, in neuem Code veraltete Daten in die Property zu
- schreiben!
-
-SIEHE AUCH:
- Properties: P_NO_TRAVELING, P_TRAVEL_INFO
- Funktionen: AddRoute(L)
- Spielerbefehle: reise
- weitere Doku: /d/inseln/schiffe/HowTo
+ Array mit eindeutiger Bezeichnung des 'Hafens'
-LETZTE AENDERUNG:
+
+BEMERKUNGEN
+===========
+
+ Diese Property wird in Raeumen gesetzt, die als Anleger fuer Transporter
+ dienen sollen. Sie enthaelt ein Array aus zwei Elementen, einem String
+ und einem String-Array, zum Beispiel:
+
+ ({ "zur Sonneninsel", ({"sonneninsel"}) }) oder
+ ({ "nach Titiwu", ({"titiwu"}) })
+
+ Damit bekommt der Spieler bei einer Abfrage seiner Reiseroute mittels
+ "reise route" eine Ausgabe wie
+ 'Du reist mit dem Floss nach Titiwu' oder
+ 'Du reist mit dem Wal zur Sonneninsel'.
+
+ Das zweite Element der Property enthaelt eine Liste der IDs, mit denen
+ sich der Hafen mit dem Befehl "reise nach <ID>" ansprechen laesst. Im
+ Beispiel oben wuerde also "reise nach sonneninsel" und
+ "reise nach titiwu" akzeptiert werden. Der erste Eintrag in dieser ID-
+ Liste wird in der Ausgabe des Befehls "reise route" verwendet, sollte
+ also den Anlegeort korrekt bezeichnen und nicht z.B. eine Abkuerzung
+ enthalten.
+ Es bietet sich an, bei bestimmten, deklinierbaren Bezeichnungen alle
+ Varianten einzutragen, z.B. "verlorenes land" und zusaetzlich
+ "verlorene land" und "verlorenen land", damit alle Varianten von
+ "reise nach ..." funktionieren.
+
+ Ist in einem Hafen diese Property nicht gesetzt, so bekommt der
+ Spieler keinerlei Hinweis darauf, wohin ihn ein bestimmter Trans-
+ porter befoerdert.
+ Stattdessen erhaelt er die Bezeichnung 'unbekannt'.
+
+
+HINWEISE
+========
+
+ Wird der zweite Parameter in dieser Property, d.h. die Liste der
+ Anleger-IDs, nicht korrekt gesetzt, kann das dazu fuehren, dass Spieler
+ den hier anlegenden Transporter nicht benutzen koennen, weil es
+ keine sinnvolle Syntax gibt, um den gewuenschten Zielhafen zu finden.
+
+ Zu achten ist auch darauf, das der erste Eintrag unveraendert in einer
+ Meldung an den Spieler ausgegeben wird, d.h. Gross-und Kleinschreibung
+ sollte korrekt sein.
+
+
+HISTORIE
+========
+
+ Frueher war der zweite Eintrag in dieser Property ein einzelner String.
+ Es existiert eine SetMethode auf dieser Property, die solche Daten in
+ altem Code auf die neue Datenstruktur umbiegt. Dies fuehrt dazu, dass
+ bei solchen Objekten die im geladenen Raum enthaltenen Daten nicht mit
+ den Daten im File uebereinstimmen. Dies moege aber bitte niemand
+ zum Anlass nehmen, in neuem Code veraltete Daten in die Property zu
+ schreiben!
+
+
+SIEHE AUCH
+==========
+
+ Properties: P_NO_TRAVELING, P_TRAVEL_INFO
+ Funktionen: AddRoute(L)
+ Spielerbefehle: reise
+ weitere Doku: /d/inseln/schiffe/HowTo
+
+
+LETZTE AENDERUNG
+================
+
2015-Jan-18, Arathorn