Eggu

Das ist eher eine Prinzipienfrage. Es sollte einfach in gewohnter Weise funktionieren wie bei anderen ähnlichen Aktionen auch, da es offenbar keinen techn. Grund für die Einschränkung gibt. Prinzip der minimalen Verwunderung. Kann man im nächsten Update ja bestimmt ergänzen. Ich habe eine Baustelle/Abriss-Stelle erstellt mit 2 Container-Plätzen für Abraum (Müllcontainer 5 m³), Container werden von Bagger und Radlader befüllt und dann von verschiedenen "Absetz"-Kippern abgeholt, geleert und wieder zurück gestellt. Deswegen habe ich keinen fixen Kran, sondern brauche das auslösende Fahrzeug, nicht wirklich ungewöhnlich so ein Szenario. Danke und Gruß, Eggu

Danke, aber ich will keinen speziellen Kran auswählen, sondern den "auslösenden" Kran. Aber in diesem Fall kann ich als Auslösen nur "Gleiskontakt" auswählen, nicht aber "Fahrzeug", so wie das z.B. beim Setzen der Geschwindigkeit möglich ist. Anmerkung: Es geht hier nicht um einen feststehenden Kran, sondern um ein Fahrzeug mit Kranaufbau (z.B. Absetzkipper)

Vl. schon bekannt. Bei o.g. Action, falls innerhalb eines Gleiskontakt-Events aufgerufen, kann man als Auslöser nur Gleiskontakt angeben, nicht aber Fahrzeug. (Nach Umwandlung in eine Skript-Zeile kann man contact durch vehicle ersetzen, und das funktioniert dann auch erwartungsgemäß). --> Bitte "Fahrzeug" ergänzen

11 sec mit AMD Ryzen 7 3700X 8-Core , SSD, 32 GB RAM

Verwendest Du Depots ? Dann kommt das von denen.

vLok = vmax * Richtungsvektor

Ok, danke für die Erläuterung. Ich hatte inzwischen ja auf Hochfront umgeschaltet, aber mein Fehler war noch, dass ich das eingleisige rechte Tunnelsegment zu weit über die Weichensektion gezogen hatte, mit der zweigleisigen Variante an dieser Stelle klappt es dann, sehr schön. Gruß Eggu

Trassenbrett (Spline) als Lückenfüller. Habe mal ein Trassenbrett (Spline) an die abzweigende Kurve angepasst und texturiert (und entsprechend angehoben), um die obere Lücke beim Übergang von 2 auf 1 gleisig zu überdecken. Weiß nicht, ob das die angedachte Lösung ist, funktioniert aber recht gut. Gruß Eggu

Unterschiedliche Höhe der 2-gleisigen (7,912 m) und 1-gleisigen (7,048 m) Tunnel-Segmente. Die Segmente sollten doch die gleiche Höhe haben, sonst werden Abzweige/Übergänge unnötig schwierig zu gestalten. Oder gehören die Segmente gar nicht zur gleichen System-Serie ? 09FD7D71-CF5D-4391-8ECA-FD684DEA7EDC (Tunnelröhre 1-gleisig) 1F7E7549-8C95-4573-A07E-6BFE17C8BFB1 (Tunnelröhre 2-gleisig) und Tunnelröhre 1-gleisig mit Rußbelag und Tunnelbogen

Ja, ist vergleichbar Gruß Eggu

Ja, wenn man einen gleichmäßigen Fahrbetrieb möchte, ist die aktuelle Lösung gut geeignet. Wenn man verhindern möchte, dass z.B. ein Traktor einem schnellen Sportwagen hinterher rast, wäre die Tempomat-Lsg. besser. Erforderliche Rechenleistung halte ich für vertretbar, eine zusätzliche Variable und eine Min.-Bildung: target-Speed = min(Vordermann-Speed, eigene-Wunsch-Speed). Aber ist ja nur ein Wunsch-Feature, dafür ist diese Rubrik ja da. Gruß Eggu

Achso, ja, Windschatten-Verfolgung

Automatische Verzögerung/Beschleunigung lassen ein Fzg. dem Vordermann folgen (in gewissen Grenzen), natürlicher wäre aber eine Art Abstandstempomat, d.h. eine Regelung, die sich an der eigenen (ursprünglichen) Ziel-Geschw. orientiert. Jetzt ist es z.B. so, dass ich autom. abbremse, wenn ich drohe dem Vordermann aufzufahren, ok. Wenn der dann aber wieder beschleunigt, so folge ich, aber auch über meine ursprüngliche Geschw. hinaus (so meine Beobachtung). Besser wäre es, die ursprüngliche Geschw. (vor dem Abbremsen) einzuregeln. Gruß Eggu

Danke, gut.

.. auch bekannt unter "Prozess/Thread-Synchronisation, Leser/Schreiber-Problem, Semaphore, ...): Können sich Events gegenseitig unterbrechen ? Oder werden die in eine Warteschlange eingereiht und nacheinander abgearbeitet ? Wenn ich eine gemeinsame Variable (z.B. einen Zähler) in einem Event hochzähle und im anderen runter, kann es zu Problemen kommen, wenn sich diese Schreib- bzw. Leseaktionen gegenseitig unterbrechen (da dies normalerweise nicht atomar geschieht, sondern auf ASM Ebene mehrere Befehle umschließt --> Daten-Konsistenz nicht gewährleistet). Deshalb braucht man hierfür Synchronisierungsmechanismen (Stichwort: test&set Befehl), oder man implementiert die Event-Abarbeitung eben unterbrechungsfrei (ähnlich Interrupt-Sperre auf Assembler-Ebene). --> Quell schwer zu findender Bugs gerade in Echtzeitsystemen. Wie ist das im Modellbahn-Studio gelöst ? Gruß Eggu

Ok, verstehe, eigentlich schade, sehr nützliches Tool. Gruß Eggu

Danke für das Video, schöne Musik. Aber da ist ja noch einiges an Handarbeit nötig, wobei das Tool das sicher auch automatisch könnte, mit einer kleinen Erweiterung. Ich habe als schnellen Workaround die Einzelspur gedoppelt, verschoben, und an die Doppelspur-Enden angefügt, die Überlappungen fallen nicht auf, (allerdings dann mit durchgezogenen Linien), anbei ein Bild mit dem Prinzip.

Steht so in dem von mir oben verlinkten Beitrag (bis einschl. V4)

Angeregt durch das Tutorial ... lesen-komplexer-ereignisdefinitionen-im-lua-format möchte ich anregen diesen Gesamt-LUA Export wieder zu implementieren. Für eine Gesamtübersicht über die EV, insbesondere bei der Fehlersuche, fehlt mir eine globale Ansicht (inkl. Suchen, Suchen/Ersetzen). Gruß Eggu

Das Tool fkt. auch für Straßen, aber nur für einspurige (am Rampen-Tool getestet), gibt es ein Workaround für mehrspurige Straßen ? Man kann die Teile der erzeugten einspurigen Rampe per "Bearbeiten-Ersetzen" durch mehrspurige Straßensegmente ersetzen, diese haben dann aber trotzdem nur eine Spur. Gruß Eggu

Wenn ich im Online-Katalog suche (z.B. "Maschinist") werden die Elemente gefunden, und zwar wenn ich dies tue auf oberstem Level "Online-Katalog", auf nächst tieferem "Entdecken", aber nicht auf "Menschen und Tiere", dann erst wieder auf "Menschen", wo dann auch (bei mir 2) Elemente angesiedelt sind. D.h. die Suche umschließt auch alle Sub-Ebenen, wenn ich auf Online-Katalog oder Entdecken beginne, tiefer dann aber nicht mehr. Soll das so sein ? Eine Such-History (Aufklappfeld) wäre auch hilfreich. Gruß Eggu

Ich möchte noch einen Punkt ergänzen, der hier ev. gemeint ist, und mit dem letzten Update gelöst wurde: Wenn per EV eine Fahrstraße angefordert wird, die gerade noch geschaltet und belegt ist (sichtbar am Schloss-Symbol), kann diese Anforderung verloren gehen, wenn nicht auch das "Vormerk-Bit" gesetzt ist, siehe Bild. Gruß Eggu

Danke, ok, dann warte ich auf die integrierte "Verkehrsregelung". Gruß Eggu

Möchte hier auch bestätigen, dass es wohl ein Problem gibt bezügl. "Fzg. vergisst target kurz nach Zuweisung wieder (sporadisch, aber gehäuft)". Experimentiere mit der Konzeptidee von Neo bezügl. "problematische Abzweigung", habe 3 Näherungkontakte mit gleicher EV dahinter, aber nur ein an einem Kontakt tritt gehäuft das Target-Vergessen auf. Werde versuchen, das genauer zu analysieren, scheint mir aber ein Bug zu sein. Gruß Eggu

Danke, aber logisch ist es trotzdem nicht, es blockiert sich ja nicht wirklich gegenseitig. Ich "experimentiere" gerade mit der Konzeptidee von Neo bezügl. "problematische Abzweigung", und da werden nebst Zielen auch Fahrstraßen zur Absicherung benutzt (kennst Du, hat ein Like von Dir). 6777-problematische-abzweigung--Neos-Konzeptidee Unschön hierbei war ja in diesem Fall, dass eine Fahrstr. erst dann als belegt gilt, wenn die Lok/Fzg komplett den Start-Kontakt passiert hatte. (Um lange Fzg. korrekt zu berücksichtigen, musste man den Näherungskontakt weit genug vor der Kreuzung platzieren, aber dann wurde gerade für kurze Fzg. unnötig früh der Abschnitt als belegt markiert). Wenn man aber zusätzlich die Fahrstr. anfordert (per EV), gilt sie gleich beim Betreten als belegt. Das ist der Hintergrund. (Dieser Ansatz ist aber auch nicht ideal, gerade wenn mehrere Fzg. dicht hintereinander anrücken und "anfordern" und "freigeben") Gruß Eggu