Phrontistes

"in der EV" gibt es bei mir ständig Änderungen. Ich verstehe Neo so, dass nach jeder Änderung in der EV die gesamte EV (samt Skript) neu kompiliert wird. Dann ist das main script keine Lösung.

Hallo @Neo, OK, wenn ich darüber nachdenke, kann es nicht anders sein, sonst herrschte Chaos . Ich hatte halt beobachtet, dass manchmal nach dem Laden der Anlage ein Auto auf einem der beiden Kontakte steht und sich nicht bewegt und hatte mir (unsinnig) zusammengereimt, dass es an der Verzögerung liegt. Aber ein Start-Event wäre trotzdem schön. Ich habe z.B. auch diesen (lt. Goetz überflüssigen) Code auf einem Schalter, der sein muss, bis Du das (lt. Goetz bereits behobene) Problem beseitigt hast und den ich auch in einen Start-Event legen würde, so es einen gäbe. local t = layout:getEntitiesByKeyword("Signal with TC") for i, Iter in ipairs(t) do local pos = Iter.transformation.position pos["z"] = pos["z"] + 10 Iter.transformation.position = pos pos["z"] = pos["z"] - 10 Iter.transformation.position = pos end print(#t .. " Signalpositionen repariert") Beste Grüße Phrontistes

Hallo @Neo, Danke für die Rückmeldung. Das ist natürlich keine Lösung. Genau dieses Problem hat mich veranlasst, über einen Start-event nachzudenken: Autos werden von einem Kontakt auf 0 gebremst und tröpfchenweise entlassen (Speed jeweils currentSpeed): Während der Verzögerung wird die Anlage gespeichert. Ein Auto steht auf dem Kontakt. Defer ist natürlich nicht gespeichert. Also muss ich nach dem Laden das erste Auto anschubsen: Das geht natürlich mit einem Schalter, aber automatisch nach dem Laden oder starten wäre halt schöner. Beste Grüße Phrontistes

Hallo @Spurwechsel, Hallo @streit_ross, das ist nett. Aber was soll ich sonst machen? Obwohl ich seit einem Jahr nicht mit ihm rede und (bis vorhin) auf nichts direkt eingehe, was er schreibt, zerredet er systematisch jeden Beitrag von mir und sogar jeden Thread, den ich erstelle. Da kann ich mich doch nur zurückziehen. Beste Grüße Phrontistes

So, das war es jetzt für mich in diesem Forum. Künftig werde ich meine Feature-Wünsche Neo per E-Mail schicken. Und ich habe ihn gebeten, mein Forumprofil zu löschen.

Die nächste völlig aus der Luft gegriffene Behauptung. Woher willst Du wissen, was ich lese und was nicht?

Sehr witzig. Nachdem Du Dich andauernd öffentlich darüber beschwerst, dass ich nicht mit Dir rede: Willst Du, dass ich öffentlich begründe, weshalb? Oder wozu soll das sonst gut sein?

Hallo @Hawkeye, einfach? Auf jeden Fall sehr originell! Und vielen Dank, dass Du es akzeptierst, wenn der Threadersteller einen Thread schließt. Das machen leider nicht alle. Und Danke für Deine schöne Zusammenfassung meines Feature-Wunsches: Genau das hätte ich gerne von @Neo. Dass man state nur mit Lua auswerten kann, ist m.E. ausreichend, d..h. Neo müsste sonst nichts weiter ändern. Beste Grüße Phrontistes

Hallo @Neo, gibt es eine Möglichkeit, einen (user-defined) event so zu definieren, dass er ohne weiteres Zutun einmal ausgeführt wird, nachdem die Anlage neu geladen wurde und erstmals gestartet wird? Beste Grüße Phrontistes

Hallo @Neo, als Threadersteller würde ich diese Debatte gerne beenden und nicht länger über einen workaround diskutieren, den ich selbst weiß. Aus meiner Sicht als Programmierer sieht es so aus: Derzeit setze ich im BÜ die Variable "Count do not open" nur deshalb vor der Anweisung "route.active = true" eins hoch, weil ich nicht weiß, ob "route.active = true" zum state 1, 2 oder 3 führt und ich das im Ereignis "Route is activated/deactivated" zwar prüfen kann, aber eben nur, wenn das Ereignis stattfindet und es findet nicht statt, wenn der state auf 1 oder 2 wechselt. Würde ich den Wechsel auf 1 oder 2 als Ereignis mitbekommen, würde ich bei state = 1 or 2 "Count do not open" eins hochzählen und bei state = 3 (wie bisher, das bekomme ich ja mit) "Count close". Es ginge also eleganter, wenn ich zum richtigen Zeitpunkt (Wechsel auf 1 oder 2) an eine Information käme, von der ich genau weiß, dass sie dem Programm bekannt ist. Nach meinem modifizierten Vorschlag müsstest Du wohl nur eine Einschränkung beim Ereignis "Route is activated/deactivated" beseitigen, damit es nicht nur bei state = 0 / 3 auslöst, sondern immer, wenn state sich ändert. Beste Grüße Phrontistes

Hallo @Sintbert, Weist Du, was Neo mit "Kontaktpunkt" meint? Ich rätsle noch immer . Beste Grüße Phrontistes

Vermeide das, weil es zu Problemen führen kann. Das ist nur ein Vorschlag. Den Namen kannst Du frei ändern. vehicle steht immer dann zur Verfügung, wenn das Ereignis es liefert. Das ist logischerweise bei diesen Ereignissen der Fall: Das ist wieder ein anderes Problem, weil der gleiche Zug im Laufe des Tages Richtung und Zugnummer (die wiederum mit der Wagennummer nichts zu tun hat) ändert. Wenn Du das abbilden willst, musst Du Fahrpläne programmieren und abarbeiten, was sich aber mit beißt. Beste Grüße Phrontistes

Hallo @EASY, Danke für die schnelle Antwort. Ich hatte schon befürchtet, dass es nicht geht. Aber es gibt ja den beschriebenen workaround, der kaum auffällt. Beste Grüße Phrontistes

Hallo @Neo, Welche Kontaktpunkte? Ich baue meine BÜs selbst aus Straßen, Schienen, Schranken (51F92FDE-3CE1-4EDB-B666-4BF64C3F8305), Ampeln (und im weiteren Sinne BÜ-Überwachungssignalen) usw. Und ich möchte selbst bestimmen, wann - auch bei mehrgleisigen BÜs - die Ampeln umspringen und wann die Schranken in welchem Tempo geöffnet und geschlossen werden - und wann die BÜ-Überwachungssignale auf "frei" schalten, nämlich nur wenn die Schranken geschlossen sind, weshalb sie bei mir nicht Teil der MBS-FS sind. Beste Grüße Phrontistes

Hallo @Anlagendesigner, der Gedanke von @BahnLand ist naheliegend, denn einen Objektnamen hat Deine Lok immer, während eine änderbare Beschriftung nur wenige Modelle haben - und das dann womöglich auch noch unter verschiedenen Bezeichnungen. Die Erbauer sind da immer ziemlich kreativ. Das geht sogar graphisch: Beste Grüße Phrontistes

Hallo @Klartexter, Neo löst das dadurch, dass eine Fahrstraße nicht aktiviert werden kann, wenn sich im zu sichernden Abschnitt noch ein Zug befindet. Beste Grüße Phrontistes Nachtrag: Wenn man ausschließlich mit Fahrstraßen arbeitet und weder von Hand herumfährt noch Signale oder Weichen von Hand stellt, arbeitet Neos FS-Steuerung zuverlässig so, dass es keine Unfälle gibt.

Wo steht die bei Dir?

Hallo @Anlagendesigner, Ja bzw. mit Lua $("Objekt").labels["Labelname"].text = "" Nachtrag: Auslesen und Bearbeiten nur mit Lua. -- auslesen - aber wozu? txt = $("Objekt").labels["Labelname"].text -- neuen Text zuweisen txt = "Neue Beschriftung" -- und reinschreiben $("Objekt").labels["Labelname"].text = txt Beste Grüße Phrontistes

Hallo @EASY, ich möchte Dich nochmals auf Deinen Tacho BE45BE0D-FE41-4309-BCAC-5DD05E17D553 ansprechen, den ich bisweilen missbrauche, um die Geschwindigkeit eines Fahrzeuges zu beobachten. Problem: Verbindet man den Tacho mit einem fahrenden Zug, gewinnt der Tacho - sowohl bei der Geschwindigkeit, wie bei der Fahrtrichtung. Das kann man zwar umgehen, indem man die Geschwindigkeit des Fahrzeuges rabiat auf 0 setzt, den Tacho verbindet und dann genauso rabiat dem Fahrzeug die ursprüngliche Geschwindigkeit wieder gibt. Beim eingebauten Controlwindow ist es anders herum, da gewinnt der Zug. Ginge "Zug gewinnt" auch für Deinen Tacho (optional oder auch immer)? Beste Grüße Phrontistes

Hallo @Sintbert, nein, es würde nach meinem Vorschlag keine unvorhergesehenen Probleme geben. Zwar würde der event "Route is activated/deactivated" in manchen Fällen mehrfach ausgelöst, nämlich falls die action "$("FS-Name").active = true" nicht sofort zum Erfolg (.state = 3 / .active = true) führt, sonst ändert sich aber nichts, wenn man im event "Route is activated/deactivated" weiterhin nur auf .active prüft. Die Prüfung auf .state (mit Lua) wäre "nur" eine neue Möglichkeit. Ich will auch keine neuen Elemente verbauen (und @Neo wird sie auch nicht konstruieren wollen, wenn es einfacher geht), sondern mich (nicht vorbildgerecht, das weiß ich ja) an Neos Fahrstraßenlogik anhängen. Ich müsste nur ein paar wenige Zeilen Code zusätzlich schreiben und schon würde das bei allen Bahnübergängen funktionieren, denn mein Code ist nicht-redundant und hat keine direkten Objektbezüge. Dein Vorschlag läuft hinaus, eine vorbildgerechte Fahrstraßensteuerung zu ermöglichen. Das ginge jetzt schon, wenn man etwas trickst und im Fahrweg eine unsichtbare Weiche einbaut, die Ablenkung ins Nirvana schickt und sie in diesem Zustand sperrt. Dann beißt sich Neos Fahrstraßenlogik so lange die Zähne aus (verharrt in .state = 2), bis man die Weiche auf gerade stellt und er sie sperren kann. Probiert habe ich es nicht, weil es mir zu aufwendig ist, es müsste aber gehen. Beste Grüße Phrontistes Nachtrag: Falls Neo diesem Vorschlag folgen sollte, könnte man für eine vorbildgerechte Fahrstraßensteuerung im Zusammenhang mit dem BÜ auch ein Signal (z.B. das BÜ-Überwachungssignal) sperren statt eine unsichtbare Weiche einzubauen.

Halo @Neo, einfacher in der Umsetzung: Du löst den vorhandenen event "Route is activated/deactivated" immer aus, wenn sich route.state ändert (und nicht nur wie bisher, wenn er 0 oder 3 wird). Die vorhandene Bedingung "if route.active" lässt Du wie sie ist. Dann ändert sich für den "Normaluser" nichts. Man kann dann aber (mit Lua) route.state auch dann behandeln, wenn er 1 oder 2 ist geworden ist. Konkreter Nutzen wäre, dass ich dann bei meiner BÜ-Steuerung (für n BÜs mit jeweils o Gleisen und p Fahrstraßen, die drüberführen und bei der ich die close- und open-requests auszähle) zusätzlich noch darauf reagieren könnte, dass der Zähler zwar auf 0 steht, in Kürze aber wieder auf 1 springen wird. Konsequenz: Ich öffne den BÜ nicht ,weil öffnen und gleich wieder schließen blöd aussieht und weil es außerdem wegen der Öffnungs- und Schließzeiten knapp werden kann. Vorbildgerecht wäre eigentlich, die FS erst zu aktivieren, wenn alles BÜs, die zu decken sind, geschlossen sind. Aber es ist halt einfacher, sich an Deine geniale Fahrstraßenlogik anzuhängen. Beste Grüße Phrontistes

Hallo @Neo, im Hinblick auf diese Diskussion und weil ich schon es schon seit einer Weile vermisse (z.B. um schon bei der Anforderung einer Fahrstraße zu verhindern, dass ein für einen anderen Zug bereits geschlossener Bahnübergang in Bahnhofsnähe geöffnet wird) rege ich an, das Ereignis "Fahrstraßenstatus hat sich geändert" einzuführen. Beste Grüße Phrontistes

Hallo @BahnLand, nur der Vollständigkeit halber und um auf Ausgangsproblem von @Bummelzug zurückzukommen: was dazu führt, dass auch eventuelle Reservierungen dieser Fahrstraße gelöscht werden. Wäre das manuelle Deaktivieren vielleicht auch bei Deiner Anlage überflüssig, wenn die Fahrstraße am Mittekontakt endet, wie von Wolfgang @prinz vorgeschlagen? Ich überblicke nicht, ob das unbeabsichtigte Nebeneffekte hätte. Beste Grüße Phrontistes

So ist Code besser lesbar: --[[-------------------------------------------------------lua skript Timer läuft ab die strecke "l" zwischen zwei lok-positionen x1,y1 x2,y2 über den Pythagoras Wurzel(x²+y²) ermitteln, das ist hinreichend genau und verfälscht nur in den kurven minimal die höhe "z" über die länge "l" ergibt die steigung in prozent --]] if i==nil then i=0 end; i=i+1 -- alive counter local z= math.abs($("Messlok-1").transformation.position.z - $("Messlok-2").transformation.position.z) local x= math.abs($("Messlok-1").transformation.position.x - $("Messlok-2").transformation.position.x) local y= math.abs($("Messlok-1").transformation.position.y - $("Messlok-2").transformation.position.y) l= math.sqrt(x*x+y*y) print(i,"x= "..x,"z= "..z,"%= "..z/(l/100),"1%= "..(l/100)) -- ende lua skript----------------------------------------------------

Hallo @Bummelzug, mit einem der in ein Stumpfgleis fährt, mittig anhält und wieder zurückfährt hatte ich mir so lange einen abgebrochen, bis ich kurzerhand eine boolsche Variable eingeführt habe, aus der Folgezug ersehen kann, ob das Gleis besetzt ist oder nicht. Vielleicht kann man das mit Fahrstraßen ja hinbekommen (eher nicht bei mittigem Anhalten), aber diese Versuche habe ich abgebrochen, nachdem das mit der Variablen gut funktioniert. Beste Grüße Phrontistes