Goetz

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

Wirklich sinnvoll ist das nicht, Tom. "Horses for courses" Die Schlagworte gruppieren Auslöser, damit man für mehrere Elemente die selben Aktionen definieren kann. Wenn also ein Auslöser triggert, weil er einem bestimmten Schlagwort zugewiesen ist, dann hat er dieses Schlagwort. Bedingungen und Optionen speicherst du in Variablen. Das ist der gleiche Aufwand, funktioniert aber besser weil Variablen für den von dir angedachten Zweck ausgelegt sind.

Nein, das steht da bei jeder Mehrfachauswahl. Weil ein "und" unsinnig wäre. Es reicht ja stets, wenn das auslösende Ereignis bei einem der aufgezählten Elemente eintritt.

Aaaahhh - das kann sein.

Ja, gibt es - sie deckt keins der Ergebnisse aus Methode 1 ab. Drum verwende ich beide und lass jedes Mal den Zufall entscheiden, ob ich die Funktion Tausch[1]() oder Tausch[2]() benutze.

Übrigens hast du vier Kontakte mit dem Namen "Gleiskontakt Schranke auf", verwendest aber nur einen davon in deiner EV. Die Namensgleichheit genügt nicht, um alle Kontakte auszuwerten. Denn wie weiter oben schon gesagt, nutzt die EV nicht den angezeigten Namen, sondern die (unsichtbare) Objekt-Referenz. Entweder wählst du alle vier Kontakte einzeln aus (was ja dank Mehrfachauswahl jetzt geht) oder du gibst allen ein gemeinsames Schlagwort. Was immer dir leichter von der Hand geht.

Das ist richtig.

Ein weiterer Punkt: Du brauchst auch zum Schließen nur einen Kontakt für Blinklicht und Schlagbaum. In der EV zählst du dann die Blinklicht-Variable sofort rauf und die Schlagbaum-Variable mit z.B: 3 Sekunden Verzögerung.

Ja, selbstverständlich. Ich brauche gar keine Entschuldigung von dir. Ich wollte dich nur darauf aufmerksam machen, dass wir nicht sehen was du siehst. Zur Schranke selbst: Wenn du - ganz allgemein - einer geöffneten Schranke den Befehl zum Öffnen gibst, dann spielt sie im MBS immer die ganze Animation vom Start (geschlossene Schranke) bis zum Ende ab. Warum dieser falsche Befehl erfolgt, kann ich noch nicht genau sagen. Aber es könnte mit der ungünstigen Positionierung der Kontakte zum Öffnen zu tun haben. Du hast die weit weg geschoben und löst sie beim Betreten aus. Besser wäre, du würdest sie mitten auf den BÜ schieben und beim Verlassen auslösen. Dann brauchst du auch nur einen für jedes Gleis und kannst ihn für beide Richtungen nutzen. Natürlich soll die Schranke nicht sofort öffnen, wenn das Zugende die Mitte des BÜ passiert hat. Deshalb setzt du gleich zu Beginn der Ereignisses ein "Ausführung verzögern" mit 2 Sekunden Dauer. Jetzt beobachte ich mal weiter, was da noch passiert ... Das ist in der V5 EV zunächst einmal egal. Denn die referenziert die Objekte. Die Namen werden nur zur Orientierung angezeigt. (Unter bestimmten Umständen spielen die Namen eine Rolle. Aber in deinem Fall nicht.)

Das ist toll Ralf. Und wenn du die Content-ID B167FAC6-FB10-4A19-92E5-260FFFB360BB hier noch einmal dazu geschrieben hättest, dann hätte ich nicht erst den Thread zur Anlage suchen und mich an den Namen "Dream City" erinnern müssen. Der dann als Suchbegriff aber auch nicht half, weil die Anlage gar nicht so heißt, sondern "Traumstadt". Das weiß ich aber erst, seit ich in besagtem Thread endlich auf der allerersten Seite obige Content-ID gefunden habe. Bitte - schick doch diejenigen, die dir gerne helfen wollen, nicht auf solch eine Schnitzeljagd. Und jetzt schau ich mal, was ich bei der Schrankenschaltung entdecke.

Oh, das freut mich. Dann ist meine Erklärung doch nicht so wirr, wie ich jetzt (ehrlich) befürchtet hatte. Danke für die Rückmeldung. Du musst dich da aber für nichts genieren. Es war nicht unbedingt erkennbar, dass ich in der Beispielanlage das zuvor beschriebene Prinzip auch angewendet hatte.

Erkläre ich im Posting darüber. Zumindest habe ich es versucht. Ist nicht ganz leicht in Worte zu fassen. Wenn ich wieder mehr Zeit habe, dann versuche ich vielleicht mal es im Rahmen einer Twitch Sendung zu erklären. Mir würde es sehr helfen, wenn du dir vorab mein Posting durchlesen und dann sagen könntest, an welcher Stelle du den Faden verlierst.

Stimmt, Tom.. Danke

Der Hauptgrund ist, dass Variablen verschiedenen Typs unterschiedlich viel Speicherplatz benötigen. Und ein Programm muss den Platz für dese Daten reservieren. Dabei geht es nicht nur um die Gesamtmenge an Platz, die zur Verfügung steht. (Davon haben wir alle heute reichlich.) Sondern auch darum, das ich den Ort des nächsten Speicherplatzes nur dann bestimmen kann, wenn ich weiß wo der vorherige endet. Ein weiterer Grund ist der, dass Daten unterschiedlichen Typs verschieden miteinander verbunden werden. Du kannst beispielsweise Zahlen addieren, wohingegen du Texte aneinander reihst. Und die boolschen Werte true und false kannst du mit "and", "or" und weiteren boolschen Operatoren verknüpfen. Drum brauchst du für unterschiedliche Zwecke auch unterschiedliche Typen. Booleans nimmst du für an und aus, wahr und falsch. Also für Bedingungen. Zahlen nimmst du, wenn du sie mathematisch verändern willst. Texte nimmst du, wenn du sie irgendwo anzeigen willst. Und dann, wenn du Texte geliefert bekommst. Fahrzeugnamen sind zum Beispiel Texte.

Aber dann muss die Abfahrt des Zuges auch nicht an das Erreichen der Ausgangsposition gekoppelt sein. Ist es ja in der Realität auch nicht. Der Lokführer füllt noch ein paar Papiere aus, macht den Deckel auf seine Thermoskanne, wischt den Becher aus, bevor er ihn auf diesen Deckel stülpt, sammelt auf dem Smartphone die letzten drei Coins, die er sich mit einem "kostenlosen Onlinespiel" verdient hat, meldet dann über Funk, dass er bereit ist und kriegt von der Leitung die Erlaubnis zur Weiterfahrt. Das dauert alles in allem 10 Sekunden, egal ob der Kran schon früher die Startposition erreicht hat oder nicht. Mit anderen Worten. Es wirkt lebendiger und glaubwürdiger, wenn nicht eins das nächste auslöst, sondern beide unabhängig (und vielleicht auch zeitlich etwas überlappend) stattfinden. Und mit dem neuen "Aktion verzögern" kannst du die Abfahrt des Zuges ganz fantastisch etwas hinauszögern, ohne Klimmzüge in der EV zu machen. Im Filmschnitt ist der schlimmste Anfängerfehler der, dass Aktion an Aktion an Aktion geschnitten wird. Das wird steif und ergibt niemals eine flüssige Geschichte.