Fahrgastwege und -sitzplätze konfigurieren

Hinweis: Dieser Artikel wurde noch nicht ins Englische übersetzt!

OMSI-Version: 2.0

Überblick

Die Wege, die ein Fahrgast im Bus laufen kann und die Positionen, wo er stehen oder sitzen darf, werden in zwei Dateien festgelegt:

• passengercabin.cfg: Enthält die Sitz- und Stehplätze
• paths.cfg: Enthält die Laufwege

, welche sich (bei unseren Fahrzeugen) üblicherweise im "Model"-Verzeichnis befinden. Allerdings ist sowohl der Name als auch der Speicherort nicht festgelegt.

Wichtig ist nur, dass sie korrekt in der *.bus, *.ovh oder - bei Szenerieobjekten, die zumindest auch Sitz- und Stehplätze haben können - in der *.sco-Datei eingetragen werden:

[paths]
model\paths_eintrepper.cfg

[passengercabin]
model\passengercabin.cfg

Tipp zur Vorgehensweise

Bevor man mit der Arbeit an den Bus-Pfaden beginnt, erstellt man am Besten in Blender mit Ecken und Punkten die Sitzpositionen und Wege im Fahrzeug. Dann fertigt man davon einen Screenshot an und beschriftet die Wegpunkte mit Nummern von 0 an aufsteigend:

Nun kann man sich durch die Sitzpositionen "hangeln" und jeweils in Blender die Eckpunktkoordinaten ablesen (dafür zuvor [N] drücken) und eintragen.

Bei den Pfaden erstellt man die [pathpnt]-Einträge in der numerierten Reihenfolge, sodass man direkt aus der Zeichnung dann ablesen kann, welche Punkte mittels [pathlink] oder ggf. [pathlink_oneway]-Einträgen verbunden werden müssen.

Schlüsselwörter für die passengercabin.cfg

Die Passengercabin-Datei verfügt (neben dem DISABLED-Befehl) über folgende Schlüsselwörter:

[passpos]/[drivpos]

Definiert einen neuen Sitz- oder Stehplatz für einen Fahrgast oder für den Fahrer. Beide Schlüsselwörter verfügen über dieselben Parameter:

[passpos]
x
y
z
h
rot

x, y und z definieren die Position des Gesäßes (Sitzplatz) oder der Füße (Stehplatz).

Der Parameter h gibt an, wie hoch der Sitzplatz über dem Boden angebracht ist (was einen Einfluss auf die Beinstellung hat) oder - wenn er "0" ist - dass es sich um einen Stehplatz handelt.

Der Parameter rot gibt die Rotation in Grad an. 0 = in Fahrtrichtung sitzend, 90 = quer zur Fahrtrichtung, nach rechts schauend.

[illumination_interior]

Dieser Befehl gibt an, mit welchen (bis zu vier) Lichtquellen die vorherige durch [passpos] oder [drivpos] definierte Sitz-/Stehposition beleuchtet wird. Außerdem werden alle weiteren Positionen derart beleuchtet bis zum Auftauchen eines weiteren [illumination_interior]-Befehls. Sollen weniger als vier Lichtquellen verwendet werden, sind die restlichen Positionen auf "-1" zu setzen.

Die zur Anwendung kommenden Indizes entsprechen (nullbasiert) der Reihenfolge der "[interiorlight]"-Befehle (die die Lichtquellen definieren) in der model.cfg.

[illumination_interior]
Index einer Lichtquelle
Index einer weiteren Lichtquelle
Index einer dritten Lichtquelle
Index einer vierten Lichtquelle

[entry] / [exit]

Definiert einen neuen Ein- oder Ausgang des Fahrzeuges.

[entry] / [exit]
num

Hierzu muss kurz auf die Path.cfg-Datei vorgegriffen werden: Dort werden Pfad-Punkte definiert, die wiederum mit Pfad-Links miteinander verbunden werden. Die Pfadpunkte sind von 0 beginnend durchnumeriert.

Der Parameter num gibt nun an, welcher dieser Pfadpunkte ein Eingang oder Ausgang ist. Pfadpunkte können auch gleichzeitig Ein- und Ausstieg sein, auch wenn das momentan eventuell zu einem gewissen Durcheinander führen kann.

Jeder neue [entry]/[exit]-Befehl definiert einen weiteren Ein- oder Ausgang und diese Reihe ist ebenfalls von 0 an beginnend durchnumeriert. Es gibt also die Eingänge 0, 1, 2,... und die Ausgänge 0, 1, 2, ... .

Über das Fahrzeug-Script kann nun über die vordefinierten Variablen PAX_Entry#_Open (# = Nummer des Eingangs) bzw. PAX_Exit#_Open der Öffnungszustand des jeweiligen Ein- oder Ausgangs gesetzt werden.

Es ist also wichtig, dass das Script über diese Variablen den Ein- oder Ausgangs öffnet, damit Fahrgäste durch diese Tür ein- oder aussteigen können.

Mit PAX_Entry#_Req und PAX_Exit#_Req kann die Anforderung der Fahrgäste am jeweiligen Ein- oder Ausgang abgefragt werden; sie können somit ersatzweise für den Bus-weiten alten Haltewunsch-Trigger int_haltewunsch genutzt werden, der aber weiterhin gültig bleibt.

{noticketsale}

Gibt an, dass der vorherige [entry] nicht benutzt werden darf, wenn der Fahrgast einen Fahrschein kaufen möchte. Typischerweise kommt der Befehl bei Hintertüren zum Einsatz, da die Fahrgäste nicht von der Hintertür nach vorne laufen sollen, um einen Fahrschein zu kaufen, sondern gleich vorne einsteigen sollen.

{withbutton}

Gibt an, dass für der vorherige [entry] über die Möglichkeit verfügt, dass Fahrgäste die Türöffnung von außen anfordern können, also z.B. über Außentürtaster verfügt. In diesem Fall nämlich laufen die Fahrgäste auch dann zum entsprechenden Eingang, wenn die Tür zu ist, da sie davon ausgehen, dass sie sie selbst öffnen können. Die Anforderung kann im Script mittels der Variable PAX_Entry#_Req abgefragt werden.

[stamper]

Definiert die Position des Entwerters.

[stamper]
num
x
y
z	

Erst wenn ein solcher Eintrag vorhanden ist, können Fahrgäste ihre Fahrkarten an einem Entwerter abstempeln. Es kann nur ein Entwerter pro Fahrzeug definiert werden. Der Fahrgast läuft zunächst zum Pfadpunkt num und führt dann seine seine Hand (mit der virtuellen Fahrkarte) zur Position x, y, z. Dann wird der Sound-Trigger ev_Stamper ausgelöst (woraufhin üblicherweise das Entwertergeräusche ertönt), der Fahrgast nimmt die Hand wieder weg und geht weiter.

[ticket_sale]

Definiert die Fahrschein-Verkausstelle (Zahltisch).

[ticket_sale]
num
x
y
z	

Ähnlich wie im Stamper-Eintrag wird hierüber die Verkaufsstelle für Fahrscheine definiert, wobei num wieder der Index des Pfadpunktes ist, an dem der Fahrgast den Fahrschein bestellt. Die Koordinaten geben wieder die Position an, wo der Fahrgast "hinfassen" muss, um den Fahrschein zu nehmen. Allerdings wird über diesen Eintrag nicht eingestellt, wo die Fahrkarten erscheinen, dies regelt der Eintrag [ticket_sale_money_point].

[ticket_sale_money_point] / [ticket_sale_money_point_2]

Hierüber wird der Tisch definiert, auf den die Fahrgäste das Geld zum Bezahlen und worauf der Fahrer den Fahrschein legt.

Es gibt zwei Varianten des Befehls:

[ticket_sale_money_point]
pos_x
pos_y
pos_z
var_x
var_y

oder

[ticket_sale_money_point_2]
pos_x
pos_y
pos_z
var_x
var_y
anim-parent

Hierbei geben die Koordinaten pos_x bis pos_z die Position der Münzen, Scheine und Fahrscheine an und über var_x und var_y wird noch die Ausdehnung der Fläche definiert, wie stark die Werte variieren dürfen. Wenn der Fahrgast Geld hinlegt, dann wird der Soundtrigger ev_ticketsale_givemoney ausgelöst, allerdings nur, wenn Münzen enthalten sind - Scheine machen ja kein Geräusch! ;) Wenn der Fahrer dagegen den Fahrschein durch Klick auf einen Fahrscheinblock ausgibt, dann wird der Trigger ev_ticketsale_giveticket ausgelöst, sobald der Fahrgast den Fahrschein nimmt, dann ev_ticketsale_taketicket

Der neu eingeführte "anim-parent"-Parameter erlaubt die Animation der Geld-Position. Hierfür wird beim zugehörigen, animierten Mesh mit dem Befehl [mesh_ident] ein Name zugewiesen, der als "anim-parent" angegeben wird.

[ticket_sale_change_point] / [ticket_sale_change_point_2]

Auf gleiche Weise wie der Eintrag [ticket_sale_money_point] definiert dieser Eintrag den Punkt (bzw. die Fläche), wo das Rückgeld ausgegeben wird.

Auch hier gibt es zwei Varianten:

[ticket_sale_change_point]
pos_x
pos_y
pos_z
var_x
var_y

oder

[ticket_sale_change_point_2]
pos_x
pos_y
pos_z
var_x
var_y
anim-parent

Auch hier hat "anim-parent" dieselbe Funktion wie beim Befehl [ticket_sale_money_point_2].

[linkToNextVeh]/[linkToPrevVeh]

Bei Gelenkbussen gibt dieser Befehl an, welcher Pfadpunkt für den Übergang zum vorderen ("Next") bzw. hinteren ("Prev") Fahrzeugteil genutzt werden soll:

[linkToNextVeh]
Pfadpunktindex

Schlüsselwörter für die paths.cfg

Die Paths-Datei verfügt über folgende Schlüsselwörter:

[stepsoundpack]

Dieser Befehl definiert ein neues Schritt-Sound-Paket.

[stepsoundpack]
num
filename1.wav
filename2.wav
...

Damit unterschiedliche Bereiche oder gewissermaßen Bodenbeläge unterschiedlich klingen, aber dennoch die Schritte einen abwechslungsreichen Klang auch innerhalb der jeweiligen Bereiche haben, können verschiedene Schritt-Sound-Pakete definiert werden. Jeder Eintrag definiert ein neues Paket, sie werden automatisch bei Null beginnend durchgezählt. num gibt an, wieviele Einzelschrittsounds definiert werden sollen, darauf folgt dann die Reihe der Wave-Dateien, welche sich im Verzeichnis Omsi\Sounds\Passengers befinden müssen. (Dort kann natürlich auch ein Unterverzeichnis eingerichtet werden und dann mit unterverzeichnis\filename1.wav vermerkt werden.)

Die Stepsoundpacks müssen vor dem ersten [pathlink]/[pathlink_oneway]-Eintrag definiert werden.

[pathpnt]

[pathpnt]
x
y
z

Dieser Eintrag definiert einen neuen Pfadpunkt. Die Pfadpunkte werden bei Null beginnend automatisch in der Reihenfolge der Einträge durchnumeriert.

[pathlink]

Dieser Eintrag definiert eine Verbindung zweier Pfadpunkte:

[pathlink]
Pfadpunkt-Index 1
Pfadpunkt-Index 2

[pathlink_oneway]

Dieser Befehl wird genauso wie [pathlink] definiert, aber erzeugt einen "Einbahnstraßen"-Pfad. Die Fahrgäste können nur vom ersteingetragenen zum zweiteingetragenen Pfadpunkt laufen.

[next_roomheight]

Dieser Befehl setzt für alle folgenden [pathlink]- und [pathlink_oneway]-Befehle bis zum nächsten Auftauchen dieses Befehls die Raumhöhe auf den Wert height (in Metern), sodass verhindert wird, dass die Fahrgäste mit ihrem Kopf durch die Decke stoßen.

[next_roomheight]
height

[next_stepsound]

Dieser Befehl setzt für alle folgenden [pathlink]- und [pathlink_oneway]-Befehle bis zum nächsten Auftauchen dieses Befehls das zu verwendende Schritt-Soundpaket. Wenn die Fahrgäste über Pfadverbindungen laufen, die ab hier definiert werden, wird der Schrittsound aus dem gewählten Schritt-Soundpaket ausgewählt.

[next_stepsound]
index_stepsoundpack