(08.08.2012 22:04)Sallarsahr schrieb:  ..... (Pfadsignal hinter der Brücke habe ich noch kein Fehlverhalten gesehen)

außer vlt. hier: http://www.tt-ms.de/forum/showthread.php?tid=5910 ?

(08.08.2012 16:06)Eddi schrieb:  

(08.08.2012 14:18)Gleisdreieck schrieb:  einfach vor und hinter die Brücke ein normales Signal setz[en]

Das ist genau das schlimmste Argument von allen. Ich möchte doch genau deshalb ein Signal auf die Brücke setzen, weil ich dahinter eine Kreuzung bauen möchte. Ohne "Signale auf Brücken" kann ich wenigstens direkt hinter die Brücke ein Pfadsignal setzen, jetzt muß ich da ein normales Signal hinsetzen, und dann ein Pfadsignal direkt dahinter? Das ist eine astreine Verschlechterung. Und deswegen ist und bleibt der Patch für mich unbenutzbar.

Welch ein Unsinn! "Signale auf Brücken" setzt man doch nicht für diesen Zweck ein, sondern weil man auf langen Brücken oder Tunneln nicht warten will, bis der ganze Zuge am anderen Ende ist. Der normale Zugabstand soll beibehalten werden, das ist das Ziel und nicht eine Kreuzung direkt hinter eine Brücke.

(09.08.2012 14:55)Gleisdreieck schrieb:  Welch ein Unsinn! "Signale auf Brücken" setzt man doch nicht für diesen Zweck ein.

Weil es nur genau einen Stil gibt, nachdem man das Spiel spielen kann, oder wie?!? Google mal bitte nach "Egoismus".

(09.08.2012 18:24)Eddi schrieb:  

(09.08.2012 14:55)Gleisdreieck schrieb:  Welch ein Unsinn! "Signale auf Brücken" setzt man doch nicht für diesen Zweck ein, sondern weil man auf langen Brücken oder Tunneln nicht warten will, bis der ganze Zuge am anderen Ende ist. [...]

Weil es nur genau einen Stil gibt, nachdem man das Spiel spielen kann, oder wie?!? Google mal bitte nach "Egoismus".

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.

Gruß
Michael

Hallo Jungs,

es sollte hier nicht Ausarten, der Sinn für mich wäre wie in der Realität, dass Züge in Tunneln in einem Blockabstand fahren können. Da U-Bahnen (fast Weltweit) hauptsächlich in Tunnel fahren wäre hier ein Spielaufbau mit Signalen Wünschenswert.

Ich Spiele mit Nutracks (Subway City Construction) hierfür wäre es Ideal.

Hallo Eddi,

Ich habe auf der Hauptseite unter Backgrounds das Bild gesehen (Modifizierte Achterbahn mit Signalen) das Chris Sawyer als er Tycoon 2 Programmierte und dann auf RollerCoaster Umstieg Programmierte. Hier sehe ich in der Modifikation das er Signale auf (Brücken oder Stege) Programmiert hat, sind davon keine Programmfetzen übrig geblieben?

Du schreibst ja selber "Es handelt sich dabei um "Implementierungsdetails", die der Machbarkeit des Features grundsätzlich nicht widersprechen."

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.

Aber wenn es wirklich zu kompliziert ist, steht dieses Thema natürlich hinten dran.

(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.

Hallo Eddi,

Danke für die Sachliche und klare Darstellung

Eddi schrieb:

mb schrieb:

Eddi schrieb:

Gleisdreieck schrieb:Welch ein Unsinn! "Signale auf Brücken" setzt man doch nicht für diesen Zweck ein, sondern weil man auf langen Brücken oder Tunneln nicht warten will, bis der ganze Zuge am anderen Ende ist. [...]

Weil es nur genau einen Stil gibt, nachdem man das Spiel spielen kann, oder wie?!? Google mal bitte nach "Egoismus".

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...

Schön wär´s.

Eddi schrieb:[...] 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?

So lange ich die Entwicklung von TTDPatch und OTTD verfolge, gibt es diesen ständig wiederholten Wunsch nach "Signalen auf Brücken" (bzw in Tunneln). Aus dem einzigen Grund, auf langen Brücken (oder in langen Tunneln) mehrere Züge hintereinander fahren lassen zu können, und so die Kapazität der Strecke zu erhöhen.

MaW: den "Blockabstand" zu verringern. Und was gäbe es da für ein besser geeignetes Mittel als Blocksignale auf Brücken bzw in Tunneln plazieren zu können?

Deine Fixierung auf pfadbasierte Signale in Ehren, aber diesen ursprünglichen Wunsch dahingehend interpretieren zu wollen, es käme darauf an, Kreuzungen direkt nach Brücken (oder nach Tunneln) plazieren zu wollen, ist diesbzgl ziemlich sonderbar, aber zumindest von untergeordneter Relevanz.

Gruß
Michael

(09.08.2012 18:24)Eddi schrieb:  

(09.08.2012 14:55)Gleisdreieck schrieb:  Welch ein Unsinn! "Signale auf Brücken" setzt man doch nicht für diesen Zweck ein.

Weil es nur genau einen Stil gibt, nachdem man das Spiel spielen kann, oder wie?!? Google mal bitte nach "Egoismus".

Ach wie schön, daß Du es bemerkt hast. Wie hattest Du doch gleich geschrieben:


Das ist genau das schlimmste Argument von allen. Ich möchte doch genau deshalb ein Signal auf die Brücke setzen, weil ich dahinter eine Kreuzung bauen möchte. Ohne "Signale auf Brücken" kann ich wenigstens direkt hinter die Brücke ein Pfadsignal setzen, jetzt muß ich da ein normales Signal hinsetzen, und dann ein Pfadsignal direkt dahinter? Das ist eine astreine Verschlechterung. Und deswegen ist und bleibt der Patch für mich unbenutzbar.

(09.08.2012 23:03)Gleisdreieck schrieb:  Ach wie schön, daß Du es bemerkt hast.

Achte mal bitte auf die feinen Details (Hervorhebung von mir)

Zitat:Und deswegen ist und bleibt der Patch für mich unbenutzbar.

Zitat:"Signale auf Brücken" setzt man doch nicht für diesen Zweck ein

Das eine ist eine (zulässige) Schilderung einer Sichtweise, und das andere eine (unzulässige) Verallgemeinerung. Und jetzt rate mal, welches welches ist.

[immer noch on-topic]

Eddi schrieb:

Zitat:"Signale auf Brücken" setzt man doch nicht für diesen Zweck ein

Das [...] [ist] eine (unzulässige) Verallgemeinerung.

Nein, das ist eine (unzulässige) Verkürzung seiner ursprünglichen Aussage:

Gleisdreieck schrieb:"Signale auf Brücken" setzt man doch nicht für diesen Zweck ein, sondern weil man auf langen Brücken oder Tunneln nicht warten will, bis der ganze Zuge am anderen Ende ist.

Gruß
Michael

Ach ihr lieben Streithähne. Stellt euch vor, es gibt Nutzer wie mich, die beide Varianten brauchen. Ich nutze Brücken ja eigentlich nur dann, wenn man etwas überqueren muss, was sich nicht durch einen Bahndamm überqueren lässt, ohne andere Verkehrswege zu blockieren. Vornehmlich Gewässer, da es keine Tunnel für Schiffe gibt.
(Siehe Spielstand in http://www.tt-ms.de/forum/showthread.php?tid=5442 )

Das Problem ist, dass sich nach einer solchen Brücke im Prinzip alles befinden kann, eine Kreuzung, offene Strecke oder sogar direkt ein Bahnhof, je nachdem wie die Karte landschaftlich beschaffen ist und wie man aus Platzgründen bauen muss. Ärgerlicher als das Aushebeln der Pfadsignal-Automatik ist für mich aber in der Tat die Verzerrung der Blockgrößen durch Brücken, d.h. die Zugfolge wird unterbrochen und es kommt zu Staus und unnötigen Zeitverzögerungen. Aus dem Grund unterbreche ich auch alle paar Felder die Tunnel oder Brücken, um ein Pfadsignal einzubauen. Ich benutze der Einfachheit halber nämlich ausschließlich Pfadsignale. Blocksignale habe ich alle entfernt und durch Pfadsignale ersetzt.

@ Eddi
Warum kann man eigentlich keine Brücken über Bahnhöfe bauen? Nach deiner Erklärung, dass nur die Koordinaten der Brückenköpfe gespeichert werden, dürfte der Untergrund ja egal sein. Trotzdem kann ich keinen Bahnhof überbrücken sondern muss die Brücken immer übers Gleisvorfeld legen, was die Sache unübersichtlich macht.

u.A. bestimmt auch deshalb, weil es nicht darstellbar wäre.

Das stimmt übrigens nicht ganz. Zwischen den Brückenköpfen wird gespeichert, ob eine Brücke existiert (1 Bit pro Brückenrichtung). Von einigen Feldern wie Industrien werden diese 2 Bits zweckentfremdet, dort wird also niemals eine Brücke erlaubt sein. Bei Bahnhöfen sollten diese Bits allerdings noch frei sein. Hier ist das übliche Gegenargument genauso wie bei kreuzenden Brücken, daß nicht sichergestellt werden kann, daß das untere Bauwerk kleiner ist als die Brücke, was grafische Überlappungen hervorrufen könnte. Das wäre alles lösbar, bisher hat sich aber keiner die Mühe gemacht.

(07.10.2012 19:38)Eddi schrieb:  Bei Bahnhöfen sollten diese Bits allerdings noch frei sein. Hier ist das übliche Gegenargument genauso wie bei kreuzenden Brücken, daß nicht sichergestellt werden kann, daß das untere Bauwerk kleiner ist als die Brücke, was grafische Überlappungen hervorrufen könnte.

Der Spieler kann dann ja "vor Ort" entscheiden, ob er eine Brücke über den offensichtlich zu großen Bahnhof bauen will, oder doch lieber nicht.

Eddi schrieb:Bei Bahnhöfen sollten diese Bits allerdings noch frei sein. Hier ist das übliche Gegenargument genauso wie bei kreuzenden Brücken, daß nicht sichergestellt werden kann, daß das untere Bauwerk kleiner ist als die Brücke, was grafische Überlappungen hervorrufen könnte. Das wäre alles lösbar, bisher hat sich aber keiner die Mühe gemacht.

Ja. Bei "objects" wurde diese Möglichkeit von Anfang an vorgesehen: prop16 (building height).

Damit kann der Bahnhofs-Set entscheiden ob über gewisse Bhfs-Elemente Brücken zulässig sein sollen. Wäre eine Bereicherung.

Gruß
Michael