Addi schrieb:

mb schrieb:Die Signalisierung in OTTD ist im Vergleich zu TTDPatch aber nun mal recht sparsam. Und die strikte Trennung zwischen "waypoints" und "stations" ist eine Altlast auf die zwar anscheinend einige OTTD-Entwickler mächtig stolz sind, die aber viele Spieler ablehnen.

Ich hab Wegpunkte schon oft und auch sinnvoll eingesetzt. Ich weiss ehrlich gesagt nicht, was du gegen die hast...

Du missverstehst mich.

Ich habe nichts gegen "waypoints". Warum sollte ich? Ich habe nicht nur dieses, erstmals in TTDPatch verwirklichte, Konzept zusammen mit Josef entwickelt, sondern auch die ersten Grafiken dafür gezeichnet und die erste newgrf herausgegeben die "waypoints" enthielt (NewStations). Deine Vermutung geht insofern fehl.


Ich habe allerdings etwas gegen das Konzept der "waypoints" wie es in OTTD implementiert ist.

Dazu muss man aber zwei Problemkreise auseinander halten:

1. "waypoints" ./. "stations"

Beides gehört in dieselbe Kategorie (Bahnhöfe, Bahnhofsbauten, ...), warum sollte man also für beides eigene Einträge im Hauptmenü haben wie in OTTD? In TTDPatch zB ist ein "Wegpunkt" ein Bahnhof, allerdings mit dem besonderen Verhalten, dass Züge dort weder halten noch laden/entladen können. Dies wird dort durch die "station class" (hier WAYP) festgelegt. Es sind nun sehr leicht weitere "Spezial"-Bahnhöfe vorstellbar, zB "Betriebswerk" (DPOT) wo Loks (beim Durchfahren) gewartet werden[*], oder "Güterbahnhöfe" (mit anderem Verhalten als Passagierbahnhöfe). Das Konzept ist also flexibel erweiterbar ohne eine notwendige Änderung der Hauptmenüstruktur oder der unterliegenden Kategorisierung.

Daher erfolgt in TTDPatch die Auswahl des Bahnhofstyps generell über das Bahnhofsauswahlmenü.

In OTTD geschieht die Bahnhofsauswahl ebenfalls über das Bahnhofsauswahlmenü, mit der (seltsamen) Ausnahme der dort so benannten "Wegpunkte". Wenn die OTTD-Entwickler konsequent sind, dann müssten sie auch in Zukunft o.e. Spezialverhalten anderer Bahnhofstypen in eigenen Einträgen im Hauptmenü statt im Bahnhofsauswahlmenü unterbringen. Viel Spass dabei.

Der Grund für dieses Verhalten in OTTD liegt mW daran dass dort "stations" und "waypoints" in voneinander getrennten Strukturen (pools) verwaltet werden. Deshalb kann man in OTTD auch an einer Boje nicht laden (Bojen gehören zum "waypoint pool"), und ist gezwungen mitten im Meer Land für ein Dock aufzuschütten damit man Fisch an Bord nehmen kann, etc.

MMn wäre OTTD gut beraten die verschiedenen Bhfstypen zu vereinigen. Da dieses "waypoint-Feature" aber schon sehr alt ist (daher sprach ich von "Altlast") wird sich diesbzgl wohl nichts mehr ändern. (S.a. den nächsten Abschnitt.)

Addi schrieb:Mit ctrl beim bauen kann man Wegpunkte miteinander verbinden.

Seit der Überarbeitung des "station pool" codes. Umso unverständlicher warum man nicht gleich den konsequenten Schritt getan hat auch die Oberfläche zu vereinheitlichen und so die willkürliche und sinnlose Trennung von beidem für den Benutzer aufzuheben.

[*] In TTDPatch vorgesehen aber lediglich in einer uralten Testversion implementiert.


2. "waypoints" ./. "restricted signals"

Es ist wesentlich unökonomischer, unrealistischer und hässlicher überall dort einen "Wegpunkt" setzen zu müssen (also ein "Stellwerk" zu bauen) wo es der Bau eines Signals tun würde.

Da dieses Feature (restricted signalling) in OTTD generell fehlt hat es in der Vergangenheit verschiedene Versuche gegeben dort etwas ähnliches zu implementieren, zB diese farbigen Streckenmarker, oder der Einbau der Restriktionen in die "waypoints".

MMn ein verfehlter Ansatz. Warum sollte ein Signalfeature in einem Bahnhof ("waypoint") eingebaut werden? Mal ganz abgesehen davon dass man dann im Gleisvorfeld überall "waypoints" (Gebäudegrafiken) herumstehen hat statt der dort normalerweise anzutreffenden Signale? Und abgesehen davon dass das TTDPatch-Konzept wesentlich über die bisher für OTTD diskutierten einfachen Durchfahrtsbeschränkungen hinausgeht:

In TTDPatch ist es zB auch möglich den Zustand eines Signals vom Zustand eines bestimmten anderen Signals abhängig zu machen, und dergleichen wäre ja bei einer Implementierung über "waypoints" nicht sinnvoll machbar, es sei denn diese würden ebenfalls Signalbegriffe visualisieren. Aber warum dann nicht gleich Signale verwenden? Das wäre sinnvoller, schöner und vorbildgerechter.


Ah! "Vorbildgerecht" ist ja einfach wunderbar! Das werde ich Zukunft bei jeder dieser unsäglichen "Realismus-Diskussionen" benutzen.

Gruß
Michael