Modulbauweise für Ampelschaltungen

  • Für den Fall, dass Grundfunktionen derzeit fehlen, wäre jetzt der richtige Zeitpunkt diese einzubringen, damit diese nicht im Gesamtkonzept untergehen. ;)

    Da hätte ich auch noch ein paar. Zum einen: Man kann zwar mit mehreren Triggern eine Anforderung auslösen, aber nicht mit einem Trigger mehrere Anforderungen. Das fehlt mir sehr, an der Stelle gefiel mir das Konzept von Omsi besser.


    Weiterhin wäre es auch an mancher Stelle schön, wenn man aktive Anforderungen von der Schaltung wieder löschen lassen könnte. Wenn sich das Grundkonzept allerdings noch weiter ändert, dann wird das vielleicht überflüssig. Mal schauen. Aktuell benötigte ich so eine Funktion aber häufiger mal.


    Ich würde mir auch wünschen, dass man Ampelschaltungen nicht nur im Editor mit dem Phasenfenster dort erstellen kann, sondern dass man komplexere Schaltungen auch selbst ganz frei als Skript schreiben und dann übers CT importieren könnte. Bitte bitte bitte. So schön und übersichtlich das Phasenfenster auch ist, wenn die Kreuzung ein wenig größer oder die Schaltung etwas komplexer wird, dann kommt man ziemlich zügig an die Grenzen des Editors oder aber der Aufwand wird unverhältnismäßig groß.


  • Ein sicheres und einfach umzusetzendes System für Eingleisige Strecken-Abschnitte, sowie Gleisverschlingungen wäre natürlich auch Wünschenswert und mit ein paar mehr Zusatzfunktionen, dann ja auch leichter umzusetzen. ^^

  • Die Überarbeitung der Ampelschaltungen finde ich auch wichtig, ganz glücklich macht sie mich nicht.


    Bei großen Kreuzungen habe ich zum Teil Abbiegespuren für Straßenbahnen sodass ich die Trigger nach Richtung trennen kann, ein anderes System ist dass mit einem optischen Symbol dem Fahrer Bescheid gebe dass in 10 Sekunden eine Anforderung ausgelöst werden kann, der Trigger liegt dabei etwa drei Meter hinter einer Haltestelle an einer Kreuzung. Das Symbol erscheint, die Türen werden geschlossen und nun wird über den Trigger gefahren, die Anforderung ausgelöst und direkt genutzt. So kann ich zwischen jede Phase eine Anforderung setzten ohne dass diese automatisch genutzt wird.

    Dies ist jedoch auch nur in Ausnahmefällen möglich, eine Erleichterung wäre sicherlich eine Gesamtüberarbeitung.


    Achja, mir persönlich fehlt bei der Erstellung der Phasen ein Blinken, das muss ich derzeit aufwendig manuell erstellen, ein Rhythmus von 0,5 Sekunden wäre ein guter Wert.

  • Ein sicheres und einfach umzusetzendes System für Eingleisige Strecken-Abschnitte, sowie Gleisverschlingungen wäre natürlich auch Wünschenswert und mit ein paar mehr Zusatzfunktionen, dann ja auch leichter umzusetzen. ^^

    Da sind momentan tatsächlich die Fahrstraßen die Bessere Wahl. Vor allem sind sie im MP viel zuverlässiger! Das lässt sich wunderbar mit den Signalen umsetzen, die im Standardcontent dabei sind ;)

  • Stoppe für x Sekunden" ist eine schicke Idee, muss ich mir auf jeden Fall notieren!

    mal so ganz doof in die runde geworfen..... kann man dazu noch eine art Zeitschaltung für z.B. eine Nachtschaltung einfügen die nach der Uhrzeit eine Anforderung setzt und so die Nachtschaltung aktiviert.... so muss man das nicht so doof wie in OMSI lösen muss wo einfach nur ein KI Bus unter der karte ein Kontakt auslöst?????

  • Aber nicht überall wird das mit solchen Signalen geregelt, häufig wird das per normaler Ampelsteuerung gemacht. Für Signale ist manchmal ja nicht einmal Platz

    die Ampelschaltung ist aber normalerweise dan mit einem Signalsystem gekoppelt und nicht mit einer normalen Ampelschaltung gekoppelt

  • Was ich persönlich als zusätzliche Funktion spannend fände, wäre die Möglichkeit, wenn in einer Phase x z.b. Hauptstraße hat für 20 sek. grün, eine Ampel für eine Abbiegespur, die die parallel fahrende Straßenbahn kreuzt, nach überfahren des Triggers (durch die StraB) nicht nur zu einem bestimmten Zeitpunkt anspringt, sondern "gleitend" in der Phase x anspringt. Sprich, egal ob der Trigger nach 5 sek. oder 15 sek. getriggert wird und somit die Triggerschaltung, StraB hat fahrt, Abbieger hat für y sek. rot, "eingeschoben" wird.


    Danke schon mal für Rückmeldungen eurerseits, ob ihr sowas ebenfalls als hilfreich/ sinnvoll erachten würdet :)

    Cheers

  • Achja, mir persönlich fehlt bei der Erstellung der Phasen ein Blinken, das muss ich derzeit aufwendig manuell erstellen, ein Rhythmus von 0,5 Sekunden wäre ein guter Wert.

    Bitte nicht so! Das geht spätestens im MP komplett in die Hose. Für gelbes Blinken gibt es ja eine eigene Phase! Ansonsten muss das in die Ampeloptik reingescriptet werden.


    Aber bitte nicht mit ständig wechselnden Ampelphasen realisieren!

  • Achja, mir persönlich fehlt bei der Erstellung der Phasen ein Blinken, das muss ich derzeit aufwendig manuell erstellen, ein Rhythmus von 0,5 Sekunden wäre ein guter Wert.

    Zu diesem Thema gibt es auch bereits schon einen anderen Thread und für Ampeln, die grün blinken sollen auch etwas im Workshop zum Download. ;)

    Mit freundlichen Grüßen

    Fasus

    ___

    - :lotus: - User seit Start der Early Access

    - Erfahren im Umgang mit dem :MapEditor:

  • Nach langer Zeit habe ich mir mal eben die Mühe gemacht, die von Tramster1210 gedachte Modul-Idee zu verbildlichen, weil ich mir nicht sicher war, ob genau dieser Gedanke in Gänze verständlich gemacht wurde. Ich habe versucht, es so einfach wie möglich zu machen.


    Als Beispiel dient eine eigentlich recht einfache Kreuzung, die für die Schaltung an sich leider pro Effizienz nicht mehr so simpel ist/sein kann.

    Die ganze Ampelphase wäre im Prinzip eine Endlosschleife, die sich je nach Anforderung(en) die Module zurecht sucht. Im oberen Bereich des Bildes ist ein beispielhafter Ablauf dargestellt.

  • Bedenke aber, dass für Fußgänzerampeln eine längere Räumzeit als für Autos angesetzt wird. Also müsste man diese - je nach Länge des Überweges - schon früher auf Rot schalten als die Autos gelb bekommen. Denn Rot wirkt für den Fußgänger wenn er den Überweg quasi in der letzten Sekunde Grün noch betreten hat ja nicht stoppend, sondern die Zeiten sind so bemessen, dass das Überqueren der Kreuzung mit "normaler" Geschwindigkeit noch abgeschlossen werden kann.

  • Es gibt aber auch Spezialkreuzungen wo das nicht umgesetzt wird, jedenfalls sind da die Überquerungszeiten für einen normal fitten Menschen schon nicht möglich, wenn sie gerade auf grün gesprungen ist. Als wir dort mit meiner Oma rübergegangen sind war es meistens schon vor der Hälfte des Überquerens wieder rot, sodass wir hoffen mussten dass Autos etc gnädig sind und auf uns warten...

  • Natürlich brauchen Fußgänger eine längere Räumzeit, allerdings bin ich bei der Kreuzung von einer Straßenbreite von 7,5 Meter ausgegangen. Das heißt bei einer Geschwindigkeit von 1,2 m/s für die Fußgänger sind 7 Sekunden tatsächlich gerade so ausreichend, nicht freundlich, aber möglich. Außerdem ist es ja eh nur ein Beispiel gewesen. ;)

  • Hallöchen Marcel,

    mir kam in den letzten Tagen im Bezug auf die Modulbeweise noch eine ergänzende Idee. Und zwar ein "Entweder/Oder"-Prinzip für die Module. Diesbezüglich habe ich auch direkt ein simples Beispiel parat:


    Eine Straßenbahnampel schaltet parallel zu der Autophase. Ist keine Straßenbahn da, dann haben die Fußgänger grün. Fordert sich jedoch eine Tram an, dann bekommt sie parallel zu den Autos F1 und die Fußgänger haben rot.


    Bei dem "Entweder/Oder"-Prinzip wäre es auch hilfreich, wenn zwischen mehreren (mehr als 2) Modulen entschieden werden kann, Bsp:


    Fall 1: Keine Tram und kein Fußgänger fordert an => die Ampel im Hintergrund bleibt für die Kfz auf grün und die Tram bekommt keine Phase

    Fall 2: Eine Tram und kein Fußgänger fordert an => die Ampel im Hintergrund bleibt für die Kfz auf grün und die Tram bekommt eine Phase

    Fall 3: Keine Tram und ein Fußgänger fordert an => die Ampel im Hintergrund schaltet für die Kfz auf rot und die Tram bekommt keine Phase

    Fall 4: Eine Tram und ein Fußgänger fordert an => die Ampel im Hintergrund schaltet für die Kfz auf rot und die Tram bekommt eine Phase


    Diesbezüglich wäre jeder Fall ein solches Modul. Ich würde mir diesbezüglich wünschen, dass LOTUS je nach vorhandenen Anforderungen zwischen den verschiedenen Fällen unterscheiden kann.


    Ich weiß, dass mir diese Idee relativ spät kommt.

    Wäre es dennoch möglich, dass dies auch noch mit umgesetzt werden kann?


    Ich würde mich zumindest echt über die Umsetzung dieses Prinzips freuen (damit lässt sich unter Umständen der ein oder andere Autostau vermeiden).


    Liebe Grüße

    Tramster1210

  • Hallöchen Marcel,


    mir kamen heute Nacht schon wieder zwei Ideen/Gedanken, die vielleicht für dieses Thema auch ganz nützlich sein könnten.


    Gedanke 1 "Springe zu" (kann in den jeweiligen Modulen fest verbaut werden):
    Man verbaut eine Anforderung, die i.d.R. übersprungen wird. Wird nun jedoch die Anforderung getriggert, dann kann es sein, dass der Übergang zwischen dem Anforderungsteil und dem Hauptprogramm nicht immer übereinstimmt (z. Bsp. weil eine Ampel kurz etwas zeigt, was sie nicht soll). Nun kann es sein, dass der Übergang zu einem späteren/früheren Zeitpunkt im Programm dafür ideal ist (z. Bsp. am Ende einer Phase). Das "Springe zu" würde dann immer beim Erreichen dieses Zeitpunkts zu einem definierten Punkt springen (z. Bsp. am Ende des Anforderungsteils zum Ende der Phase).
    Derzeit könnte man dafür eine Anforderung verbauen, die quasi nie getriggert wird und dadurch das Springen ermöglicht.
    Warum rege ich das als extra Punkt an? Viele Anforderungen machen ein Ampelprogramm schnell unübersichtlich und erhöhen z. Bsp. die Fehlerwahrscheinlichkeit bei Triggern, die richtige Anforderung auszuwählen. Da das "Springe zu" permanent ist, kann ich mir vorstellen, dass dieses nicht bei den Triggern aufgelistet wird. Des Weiteren sollte dieses "Springe zu" in einer anderen Farbe hervorgehoben werden, damit man direkt erkennen kann, dass es sich hierbei um ein "Springe zu" handelt (und nicht um eine Anforderung). Dadurch wird die Übersichtlichkeit bei der Gestaltung von Ampelprogrammen erhöht und Fehler im Programm können schneller identifiziert werden.



    Gedanke 2 "Entweder/Oder auf mehreren Ebenen":

    Mein zweiter Gedanke fasst mein angeregtes "Entweder/Oder" auf. Diebezüglich würde ich mir wünschen, dass man das "Entweder/Oder" auf mehrere Ebenen konfigurieren könnte.

    Kleines Gedankenspiel zum besseren Verständnis: Eine Tram bekommt mit den KFZ zusammen F1 (wenn eine Tram sich anfordert), andernfalls hat die Tram dauerhaft F0. Nun müsste die Tram sich bereits vor dem Grünwerden der KFZ den Auslöser triggern, da sie sonst ihre Phase verpasst. Das "Entweder/Oder" auf mehreren Ebenen könnte diesem entgegenwirken:

    Ebene 0 (Kurz bevor die KFZ grün bekommen): Entweder die Tram fordert sich an (F1), oder sie fordert sich nicht an (bleibt F0).

    Ebene 1 (nach einer gewissen Zeit, z. Bsp, 5s, Bedingung ist hierbei: "Tram hat sich nicht angefordert"): Entweder die Tram fordert sich an (F1), oder sie fordert sich nicht an (bleibt F0).

    Dasselbe kann bis zum Ende der Phase je nach Belieben durchgeführt werden (können z. Bsp. auch nur 2 Ebenen sein).
    Vorteil dieser mehreren Ebenen stellt also das "Nichtverpassen" von Tram-Phasen dar, wenn eine Tram-Phase prinzipiell möglich ist.


    Beispiel an einer Köpenicker Kreuzung:

    Die Ampel ist hier für die KFZ schon etwas länger grün, die Tram bekommt trotzdem zeitnah F1.

    Oder hier auch gut zu sehen. Allerdings ist hier auf der anderen Seite eine Tram, die die Schaltung auch beeinflussen könnte. Man sieht jedoch auch in diesem Video relativ gut, was ich darstellen möchte.



    Ich weiß, dass mir diese Ergänzung wieder relativ spät kommt. Konntest du dennoch verstehen was ich mit meinen zwei Gedanken meine?

    Und wäre es noch möglich, dass diese auch noch bei der Umsetzung mit berücksichtigt werden können? (Ich hoffe, dass es dafür noch nicht zu spät ist).


    Ich würde mich zumindest echt über die Umsetzung von meinen zwei Gedanken freuen.


    Liebe Grüße

    Tramster1210

    Hier könnte Ihre Werbung stehen!

    5 Mal editiert, zuletzt von Tramster1210 () aus folgendem Grund: sprachliche Korrektur (jetzt ist auch mal gut) haha

  • Neu erstellte Beiträge unterliegen der Moderation und werden erst sichtbar, wenn sie durch einen Moderator geprüft und freigeschaltet wurden.

    Die letzte Antwort auf dieses Thema liegt mehr als 60 Tage zurück. Das Thema ist womöglich bereits veraltet. Bitte erstellen Sie ggf. ein neues Thema.

    Maximale Anzahl an Dateianhängen: 5
    Maximale Dateigröße: 500 kB
    Erlaubte Dateiendungen: bmp, cfg, ini, jpeg, jpg, lct, ldl, llg, lob, log, lpmtl, lptmt, ltx, pas, pdf, png, railtrack, rar, txt, veh, wav