(09.08.2012 19:46)mb schrieb:  Wenn man aber stattdessen nach "signals on bridges" (d.e. "Signale auf Brücken") guglt dann bekommt man zu ~90% Treffer die genau die Aussage von Gleisdreieck stützen.

Also da fehlen mir ja echt die Worte...

Das ist genauso rekursiv wie, wenn eine Zeitung eine (falsche) Information von Wikipedia abschreibt, und Wikipedia das dann als "zuverlässige" Quelle für die Richtigkeit der Information gelten läßt.

Also nochmal zum Mitschreiben:
Mal abgesehen von dem Fakt, daß "laute Minderheiten" noch lange keine Mehrheit darstellen...

Es gibt Spielvarianten A und B. Feature X ist für A relativ gut nutzbar, aber für B nur sehr eingeschränkt. Und du willst jetzt für die "Ungültigkeit" von B als "Beweis" anführen, daß die Leute Feature X nur für A nutzen, aber nicht für B?

(09.08.2012 20:00)Streckenläufer schrieb:  Da U-Bahnen (fast Weltweit) hauptsächlich in Tunnel fahren wäre hier ein Spielaufbau mit Signalen Wünschenswert.

Das gleiche gilt dann aber auch für Weichen, Bahnhöfe, etc.

Zitat:sind davon keine Programmfetzen übrig geblieben?

nein, da diese Entwicklung nach dem Release von TTD stattgefunden hat, ist der geänderte Code nicht magisch in die alten Versionen zurückgeflossen. Nebenbei funktionieren Brücken in OpenTTD mittlerweile völlig anders. Selbst wenn jemand durch "Reverse Enginneering" herausfinden würde, wie das in RollerCoaster Tycoon umgesetzt ist, wäre das vermutlich nicht auf OpenTTD anpaßbar, da kann man es auch gleich unabhängig neu implementieren.

Zitat:Mein Gedanke ist, Signale an Gleise zu "Binden" egal wo diese Gleise sich befinden (siehe Modifikation RollerCoaster). Das scheint ja zu funktionieren sonst könnte ich Signale in der ganzen Landschaft aufstellen.

Das ist eine schöne Vorstellung, ist aber aus technischer Sicht nicht zu gebrauchen.

Mal ein paar technische Details:
Die Karte besteht in OpenTTD hauptsächlich aus dem so genannten "Map Array". Das sind zu jedem der bis zu 4 Mio Felder jeweils 40 Bit, die speichern, was für ein Feldtyp es ist (Leer, Schiene, Straße, Haus, Bahnhof, etc.), und abhängig davon, wie das Feld beschaffen ist (Leer -> kann Bäume oder Unebenheiten haben; Schiene -> kann Gleise in 6 verschiedene Richtungen, sowie Signale haben, ...).

Brücken hingegen sind in OpenTTD nicht direkt gespeichert, sondern nur in den Brückenköpfen. Zwischendrin hängt der Zug also "in der Luft", daß darunter ein Gleis gezeichnet ist, ist nur ein grafischer Effekt, das Gleis ist nicht wirklich vorhanden. Aus diesem Grund kann man dort keine Signale setzen, da man das nirgenswo hinspeichern kann. In das Feld unter der Brücke jedenfalls nicht, da dort ja Straßen oder Wasser sein könnte, die keine Möglichkeit haben, Signale zu speichern (die Bits werden dort u.U. anderweitig benutzt), aber selbst wenn da Gleise wären, könnten ja Signale in der gleichen Richtung platziert sein.

Nun wirds kompliziert, denn es gibt jetzt verschiedene Varianten, wie man das Problem lösen/umgehen kann. Der "Signals on Bridges Hack" nimmt hier eine "Abkürzung", und zwar mißbraucht er die Brückenköpfe, um dort ein Bit "Hat Signale" (und noch eins für die Richtung) zu speichern. Die Signale in der Mitte der Brücke sind dann genauso grafische Illusionen wie das Gleis, der Zug schwebt immernoch in der Luft. Eine andere wäre, außerhalb der Karte (in einem so genannten "Pool" (= dynamisches Array)) das Layout der Brücke zu speichern, dann würde der Zug also beim Betreten der Brücke die Karte verlassen, auf die separate Brückenkarte wechseln, und wieder zurück. Oder man könnte die Karte in "Schichten" einteilen, dann würde der Zug beim bergauf/bergab fahren (oder ähnliche Mechanismen) die Schicht wechseln. In beiden Fällen hätte man prinzipiell die Möglichkeit, alle Sachen genauso zu machen wie auf der normalen Karte (Weichen, Signale, Bahnübergänge, Bahnhöfe, ...), wäre also wesentlich flexibler als der "Hack".

An der ersten Variante hat sich vor ein paar Jahren mal Belugas versucht (mit der Einschränkung, daß die Züge die Signale nicht beachten), für die zweite Variante gibt es ein halbfertiges Projekt von Michi_CC und Celestar, welches aber größere Performanceprobleme hat.