Goetz

Genau darum geht es! Das ist deshalb vorteilhaft, weil sich diese Dinge erfahrungsgemäß des Öfteren ändern. Beispielsweise kommen weitere Funktionen hinzu, die ebenfalls ausgeführt werden sollen wenn ein Signal schaltet. Mit dem benutzerdefinierten Ereignis muss man es nur einmal an zentraler Stelle ändern. Die Parameter beim Auslösen des benutzerdefinierten Ereignisses habe ich einfach in die vorgesehenen Felder eingetragen. Die Felder werden deshalb bei der Aktion angeboten, weil ich die Variablen im benutzerdefinierten Ereignis erzeugt habe. Die EV "sagt": Du willst das benutzerdefinierte Ereignis für die hell/dunkel-Schaltung auslösen? Dann benötige ich von dir bitte die folgenden drei Informationen. Der Aufwand ist bei deiner und meiner Vorgehensweise mehr oder weniger identisch. Aber das Beispiel eignet sich gut, um den Umgang mit benutzerdefinierten Ereignissen zu üben. Damit man es nicht gerade dann lernen muss, wenn man es unbedingt benötigt.

Hier ist ein Beispiel zu meinem Vorschlag, ein benutzerdefiniertes Ereignis für die hell/dunkel Schaltung aller Vorsignalwiederholer an den Hauptsignalmasten zu verwenden. Das benutzerdefinierte Ereignis erledigt die eigentliche Umschaltung. Die ist ja in allen Fällen identisch. Für diesen Zweck werden beim Aufruf des Ereignisses drei Argumente mitgegeben: Die Stellung des Hauptsignals das Vorsignal-Objekt mit sichtbarem Signalbild das dunkle Vorsignal-Objekt Für jedes Hauptsignal reagiert die EV dann, wenn das Signal umschaltet. Die Aktion ist der Aufruf des benutzerdefinierten Ereignisses mit Übergabe der Signalstellung des auslösenden Hauptsignals und der beiden am selben Mast befindlichen Vorsignale. Ich habe eine kleine Demo angehängt, die das Ganze in Aktion zeigt. Testanlage Vorsignal Dunkelschaltung.mbp

Ja, ich denke das wäre sinnvoll. Vielleicht kann man sogar noch einen Schritt weitergehen und ein "benutzerdefiniertes Ereignis" erstellen. Also ein einziges Ereignis, dass alle Signale nutzen können um jeweils ihre Vorsignale hell/dunkel zu schalten. Denn die Aktion ist ja für alle identisch, nur die Parameter (sprich: die Objekte) ändern sich.

Mist - wieder kein Bier dabei Stehen drei Düsseldorfer am Tresen. Der erste bestellt ein Pils, der zweite ein Weizen, der dritte einen Orangensaft. Fragen ihn die ersten zwei: "Was ist denn mit dir los?" Antwortet er: "Na, wenn ihr kein Bier trinkt, dann will ich auch keins."

Das glaube ich dir gerne, Brummi. Okay, das kann ich, soweit mein Wissen in dieser Hinsicht reicht, nachvollziehen.

Okay, das ist machbar, aber irgendwie krumm. Da würde ich mir ein Update der Vorsignale mit der Erweiterung um eine zusätzliche Signalstellung "dunkel" wünschen.

No, not quite. But the timers, event variables and the event script come first. Below that you may sort your modules (folders) and events in any order. are placeholders that you declare. Give them any name you want. When you call the generic event, you can pass on any data (e.g. the triggering vehicle) to those placeholders. That way, your generic event has access to that object or data and may change its values. The error message is exactly what it says: Your timer script doesn't know what vehicle you're talking about. There's "nil" vehicle stored in the variable "vehicle". When an event is triggered by a vehicle, the triggering vehicle is automatically transferred to the variable "vehicle". But it (as all variables) is a local one, not known to other events. If this wasn't the case, you couldn't have different vehicles triggering different events at different locations. The expiration of your timer is not triggered by a vehicle. So the variable "vehicle" doesn't exist here. You'll need to store the vehicle elsewhere and then access that storage (i.e. variable) in your timer function. Having said that, a timer is not your best choice for a delayed vehicle command anyway. V5 offers a much better alternative: Simply insert a delay command before the action. The EV will take care of the rest and you don't have to bother with reacting to a timer expiring.

@ralf3 Hier zeigt sich ein kleines Problem bezüglich der Vorsignale für die Mastmontage im MBS. Sie lassen sich leider nicht dunkel schalten. Das wäre aber zwingend nötig, denn wie man in deinem Video gut erkennen kann, hat man sonst am selben Mast zwei widersprüchliche Signale: Einmal "Halt" und einmal "Fahrt". Deshalb wird die Vorsignal-Anzeige bei der realen Bahn dunkel (= aus) geschaltet, wenn das Hauptsignal am selben Mast "Halt" zeigt. Ein eigenständiges Vorsignal irgendwo auf halbem Wege zwischen Ausfahr- und Blocksignal wäre vom Ausfahrsignal unabhängig und müsste daher nicht dunkel geschaltet werden. Aber nett aussehen tut es. Auch deshalb, weil das Umfeld gut ausgestaltet ist.

Yes, it is. But what you suggest is two triggering events and not two conditions. You may also have two events triggering the same action. But the method differs, depending on the two events being either of the same type or different ones. If they are of the same type, simply select multiple elements as triggering objects: However if you want two events of different types to trigger the same action, you want to set up a generic event … … and execute this in your two different events: Please, let me know if you'd prefer screenshots with captions in English and I'll gladly exchange them.

@Reinhard möglicherweise hatte er diesen Anhänger zum Vorbild

Aaahh - jetzt ... Es handelt sich um zwei Timer mit sehr ähnlichen Namen. "CheckD1" und "CheckD1west". Ich hatte übrigens keine Zweifel, dass es läuft. Ich fand es nur zu umständlich (weil ich es für einen Timer hielt.) Und natürlich hatte ich verstanden, dass es dir nicht um die konkrete EV ging, sondern um grundsätzliche optische Verbesserungen. Du kannst übrigens auch beide Timer in einer Mehrfachbedingung auswerten. Das ist besser, als diese gestaffelten Bedingungen.

Hallo @metallix Der Aufbau deiner EV ist unnötig umständlich. Du brauchst keinen zweiten Check, ob der Timer nicht läuft. Alles, was dort drin steht, kannst du in den unteren Kasten von "Timer is running" packen, denn wenn diese Bedingung nicht erfüllt ist, dann läuft der Timer nicht.

Darf ich dazu einen Tipp beisteuern? Wenn man das Schaltgleis mit der rechten Maustaste anklickt, dann kann man aus dem Kontextmenü "Zug/Fahrzeug betritt ein Gleis" auswählen. Das öffnet die EV und trägt gleich ein Ereignis samt dem richtigen Auslöser ein. Das erspart die Suche nach dem passenden Ereignis und dem zugehörigen Auslöser. Der Auslöser wurde durch den Rechtsklick darauf definiert und die unter "neu" angebotenen Ereignisse sind nur solche, die zu diesem Auslöser passen. @streit_ross Bitte, verstehe meinen Hinweis als Ergänzung und nicht als Kritik an deiner Anleitung.

Hast du dir die Beispielanlage noch nicht angeschaut? Du hattest dem Posting doch sogar ein "gefällt mir" spendiert. Da passiert genau das. Du schaltest den Kippschalter und ein Dutzend Märklin Knöpfe schaltet um.

@ralf3 Im Video siehst du noch einen weiteren Aspekt, den ich für mehr Realismus ebenso wichtig fände. Bei Halbschranken schließen zuerst nur die Hälften, die den Autoverkehr stoppen. Also die in Fahrtrichtung gesehen rechten Schranken. Die anderen Hälften - sozusagen die Ausfahrten aus dem BÜ - bleiben viel länger geöffnet, damit kein Auto im BÜ eingeschlossen wird. Beim Öffnen des BÜ gehen dann alle vier Schranken zugleich hoch, weil hier kein Vorteil darin läge, die Schlagbäume gestaffelt zu öffnen. Das kannst du sehr leicht in deiner EV anpassen, da du sowieso schon Verzögerungen drin hast. Du muss nur zwei von vier Werten ändern (und eventuell die Kontakte noch ein wenig weiter vor ziehen.)

Wow! Das ist grandios, Neo.

Ja, es braucht Lua (bitte, schreib nicht LUA. Das mögen die Erfinder dieser Sprache nicht, weil es hässlich aussieht. Lua ist keine Abkürzung, sondern ein Name.) Aber die wenigen Lua-Zeilen, die es benötigt, sind leicht zu verstehen und schneller geschrieben als man es in einer herkömmlichen EV zusammenstöppeln könnte. Vielleicht ein Anreiz, mal ein wenig damit zu experimentieren?

@ralf3, @BahnLand Ich hatte heute früh ein kleines Tutorial erstellt, welches genau dieses Thema behandelt: Auswahl per Schlagwort Man kann alle Objekte, welche ein bestimmtes Schlagwort enthalten, in einer Tabelle zusammenfassen. Und dann als Reaktion auf ein Ereignis mit allen Objekten dieser Tabelle etwas anstellen.

Warum nicht?

Du wirst in der Realität kaum Weichen finden, die mitten im BÜ liegen. Weil du dort die Weichenzungen "einbetonieren" würdest. Anders sieht es bei der Straßenbahn aus. Deren Gleis liegt oft über weite Strecken im Straßenasphalt. Und somit natürlich auch die Weichen. Und wenn etwas in Asphalt eingebettet ist, dann benötigst du die Rille um den Platz für den Radkranz sicher frei zu halten. Beispielbild

Dank Neo habe ich dazu jetzt einen Vorschlag. Mittels Lua kann man alle Elemente, die ein bestimmtes Schlagwort (engl: keyword) haben, als Tabelle bekommen. Der Funktion dazu heißt: layout:getEntitiesByKeyword() und sie benötigt als Argument das Schlagwort. Da das Wort ein String ist, muss es den Lua Regeln folgend in Anführungsstrichen stehen. Die Funktion liefert eine Tabelle zurück. In der angehängten Beispielanlage habe ich 12 Schalter abwechselnd mit dem Schlagwort "ungerade" und "gerade" versehen. Mit den folgenden zwei Zeilen Lua gebe ich diesen beiden Gruppen die Namen GruppeA und GruppeB GruppeA = layout:getEntitiesByKeyword("ungerade") GruppeB = layout:getEntitiesByKeyword("gerade") Wird der Kippschalter betätigt, dann wird ein kleines Skript aufgerufen. Die Stellung 0 des Kippschalters dient dabei als Bedingung. Ist sie erfüllt, dann sieht das Skript so aus: local an, aus = 1, 0 for k, v in ipairs(GruppeA) do v.state = an end for k, v in ipairs(GruppeB) do v.state = aus end in ipairs liefert für die for-Schleife nacheinander alle Elemente der Tabelle, die in den Klammern genannt wird. Das Element steht in der Variablen v, der Index des Elements in k. Ich verwende im Beispiel nur v. Den Index benötige ich nicht. Ist die Bedingung "Kippschalter Stellung = 0" nicht erfüllt, dann wird ein nahezu identisches Skript ausgeführt. Nur die Zuweisung von "an" und "aus" ist vertauscht. Die Stellung des Kippschalters als Bedingung und die daraus resultierenden zwei nahezu identischen Skripte wären nicht nötig. Das kann man noch einfacher gestalten. Ich dachte nur, dass die Zusammenhänge so vielleicht deutlicher werden. Aus demselben Grund habe ich auch die Stellungen 0 und 1 sowie die Tabellen, welche layout:getEntitiesByKeyword() liefert, mit Namen versehen. Viel Spaß beim Ausprobieren Götz Auswahl per Schlagwort 01.mbp

Oh Mann - das ist ja genau das, was Tom gesucht hat. Danke

Versteh bitte, dass das aktuell die V5 Testphase ist. Du darfst die Diskussionen zu den verschiedenen Aspekten nicht mit einer Anleitung zur neuen EV verwechseln. Da geht es zur Zeit drunter und drüber. Erste Erfahrungen und Tipps werden ausgetauscht, Fragen beantwortet, Lösungen gesucht und auch geschaut, ob noch etwas korrigiert werden muss. Wir müssen ja selbst erst einmal herausfinden, wie das alles funktioniert. Lass uns mal die nötige Routine kriegen, dann können wir anschließend auch allgemeinverständlich erklären, wie man welche Aufgaben in der neuen EV am besten angeht. Bis dahin kannst du (auch mit der V5 des MBS) weitermachen wie bisher. Und Lua musst du nicht lernen. Man kommt auch in der neuen EV ganz ohne diese Skriptsprache zurecht. Dank Lua bekommst du jetzt Anlagen wie die, welche Roter Brummer gerade anbietet. Und so profitierst du auch von dieser Erweiterung im MBS. Das ist der eigentliche Vorteil dieser Neuerung.

Use the main script. In the event manager, click the + sign and instead of adding an event or a modul, add a script. You can have one main script per layout and that may hold your table and other constants. And no, a table cannot be an object variable. Not yet, anyway. But Neo is considering this option.

Verstehe. Ich denke mal darüber nach, wie das am besten geht.