Goetz

Der Unterschied ist enorm, Feuerfighter. Wirklich lohnenswert Aber wärst du bereit, bei deinem Haus den Effekt vorsichtiger zu dosieren? 30% von deiner aktuellen Einstellung wären meines Erachtens genug. Vielleicht noch weniger ... Im Augenblick ist der Effekt so krass, dass die eigentlich tolle Wirkung verpufft. Viele Grüße Götz

Das geht hiermit sehr bequem: Mit der oben genannten Methode kann der GK an seinem Platz bleiben: ohne Relocaten.mbp

Doch, das gibt es. Und dazu noch genau dort, wo man es benötigt: Ich habe mir erlaubt die Aufzählung zu formatieren. Das ist nicht nur nennenswert, sondern sogar besonders gut umgesetzt. Davon können EEPler nur träumen!

würde ich - V5 vorausgesetzt - durch einen Gleiskontakt ersetzen. Den kannst du besser positionieren. Und dann merkst du dir - wie von Tom schon vorgeschlagen - das auslösende Fahrzeug in einer Objektvariablen. Beim Stopp an einem Signal würde ich dieses Signal als Speicherort empfehlen, weil nur in Abhängigkeit von diesem Signal weitergefahren werden darf. Ab der verlinkten Position (47:43) siehst du in diesem Video ein Beispiel dafür, wie man es handhaben kann.

Geil!

Hallo Frank, mit Lua kannst du es so schreiben: for i, Wdh in ipairs({1, 3, 5}) do $("Kippschalter").variables["Lampen"][Wdh].state = state end ipairs nimmt Wertepaare aus einer Tabelle und weist sie den beiden Variablen links vom in zu. Traditionell heißen diese Variablen k und v für key (Schlüssel, also der Name der Zelle) und value (Wert, also der Zelleninhalt). Das MBS nennt die Variablen i (für Index) und Wdh (für Wiederholung), wenn man eine grafische EV umwandelt. Und im konkreten Beispiel spielt der Index i anschließend keine Rolle. Als Funktionsargument übergibt man an ipairs eine Tabelle. Meistens den Tabellennamen. Aber man kann auch direkt die Tabelle einfügen. Die runden Klammern gehören also zu ipairs und kennzeichnen das Funktionsargument. Die geschweiften Klammern darin deklarieren die Aufzählung als Tabelle. for ... in bewirkt, dass der Reihe nach alle Wertepaare aus der Tabelle ausgelesen und an die Variablen übergeben werden. Demo-Anlage: Liste abrufen (Lua).mbp Viele Grüße Götz __________________________________________________________________________ Nachtrag zu and und or: Timba hat es schon angedeutet: Bei and bekommst du nur den letzten, bei or den ersten Wert zurück, weil beides logische Operatoren sind. Sie haben nichts mit Aufzählungen zu tun. Gedacht sind sie für Konstrukte wie if Bedingung_1 == 17 and Bedingung_2 == 4 then Der Vergleich mit == liefert ein true (wahr) oder false (falsch) zurück. Und genau das benötigt if für seine Entscheidung, entweder true oder false. Bei and müssen alle Bedingungen erfüllt sein. Und das bedeutet: Wenn die erste Bedingung nicht erfüllt ist, dann hat sich die Sache schon erledigt. Ist das erste Ergebnis false, dann bekommt das if ein false und der Rest wird nicht mehr geprüft. Eventuelle Funktionen in den nachfolgenden Bedingungen werden nicht ausgeführt! Dasselbe gilt für alle weiteren verknüpften Verbindungen: Sobald eine Bedingung nicht erfüllt ist, bekommt das if ein false gemeldet und die Prüfung wird abgebrochen. Sind alle Bedingungen bis auf die letzte erfüllt gewesen, dann gibt Lua das Ergebnis des letzten Vergleichs ungeprüft an das if weiter. Denn jetzt hängt alles alleine von dieser Bedingung ab. Sie enthält also jetzt in jedem Fall das, was das if bekommen muss. Beim or kehren sich die Verhältnisse um, aber das Prinzip bleibt dasselbe. Diesmal reicht ja eine einzelne erfüllte Bedingung. Also wird das erste wahre Resultat direkt an das if weitergegeben. Und wenn alle vorherigen Bedingungen nicht erfüllt waren, dann gibt Lua die letzte Bedingung ungeprüft an das if weiter, denn sie enthält jetzt die richtige Antwort. Der Empfänger dieser boolschen Verknüpfungen muss nicht zwingend die if-Verzweigung sein. Man kann das Ergebnis ebenso gut an eine Variable übergeben. v = Bedingung > 42 or Bedingung < 1 Die einzelnen Operanden müssen nicht zwingend Vergleiche sein. Jede Zahl und jeder String haben in Lua den boolschen Wert true. Auch die Zahl 0 und der leere String "" Ein fehlender Wert wird in Lua durch nil repräsentiert und als false gewertet. Das erlaubt Tricks wie diesen hier a = (a or 0) + 1 Wenn a existiert, dann ist der Wert links vom or true und wird verwendet. Existiert a (noch) nicht, dann wird es durch die 0 rechts vom or ersetzt. Aus diesen Erläuterungen kannst du ableiten, warum du bei and (nur) den ersten und bei or (nur) den letzten Wert bekommst.

Hallo Frank, dein Posting hatte ich leider durch das nachfolgende von Tesla übersehen. Sorry! Ja, die gibt es. Leg nur bestimmte Bestandteile in die Liste. (Das wäre der einfachste Weg) Die Frage ist: Wie möchtest du unterscheiden, welche Dinge aus der Liste verwendet werden sollen und welche nicht? Du willst nicht alle einzeln ansprechen. Okay. Aber dann musst du doch auf andere Weise festlegen, welche Elemente betroffen sein sollen. Sag du mir, woran die Elemente erkennbar sind und ich sage dir, wie du sie in der Wiederholung identifizierst. Wenn sie z.B. ein bestimmtes Schlagwort haben, dann kann ich dir zeigen, wie du diese Elemente in der Wiederholung rausfilterst. Wenn es der Name ist, dann kann ich dir zeigen, wie du den (mittels Lua) zerlegst und nach einem bestimmten Namensteil suchst. Wenn es der Index in der Liste ist, dann zeige ich dir, wie du eine zweite Liste mit den Indexen erstellst und auf die erste anwendest. Zur dritten Version (die deiner Eingangsfrage am nächsten kommt) habe ich hier eine weitere Demoanlage für dich: Liste abrufen (Auswahl).mbp

Nein, das siehst du falsch. Pardon. Ich hatte fälschlich Ereignisverwaltung gelesen und nicht Ereignisprotokollierung Die Liste bearbeitest du (wie eine Variable) dort, wo sie steht. Im Fall von Franks Beispiel steht sie im Kippschalter. Es gibt mehrere Wege zu dieser Liste. Das Ereignisprotokoll ist einer davon (wenn dort in der rechten Spalte das Objekt steht) Ein Rechtsklick auf das Objekt mit anschließendem "Schlagwort/Variable bearbeiten" ist ein zweiter. Ein Klick auf das Symbol mit den drei waagerechten Strichen im Eigenschaftsfenster ist ein dritter. ...

Hallo Frank, hier ist zunächst eine Version in der alle (und nicht nur ausgesuchte) Elemente der Liste angesprochen werden. Sie kommt außerdem ohne eine Bedingung aus, weil einfach die Schalterstellung an die 5 Lampen übertragen wird. Damit hast du schon zwei Dinge hinzugelernt. Den Einsatz von Wiederholungen und eine Alternative zur Bedingung. Um jetzt gezielt nur einen Teil der Liste anzusprechen, müsstest du diesen Teil irgendwie vom Rest unterscheiden. Und da wäre es doch das einfachste, dass du nur diesen Teil in die Liste packst. Alternativ kannst du es natürlich auch mit einem Schlagwort in manchen Objekten hinkriegen oder anhand des Namens und per Lua ausbaldowern, wer nun umschalten darf und wer nicht. Aber warum willst du dir das Leben schwerer machen als nötig? Demo-Anlage: Liste abrufen (alle).mbp

Das wäre eine "oda abba" Verknüpfung Oppa abba üba Obaammagau oda abba üba Untaammagau oda abba übahaupnich kommp kanna dann im Aeignisprotokoll lesen. scnr

Wow - Danke, Timba!

Da diese Objekte nicht per se in einer Tabelle stehen, kommst du auch nicht mit pairs() dran. Sie können mit der Funktion layout:getEntitiesByKeyword() alle in eine Tabelle übertragen werden. Danke für die Erinnerung, Timba!

Du hast viele Ereignisse erstellt. Aber kein benutzerdefiniertes Ereignis. Das bekommst du über das + Zeichen in der oberen linken Ecke des EV Fensters. Dort kannst du jeden Ereignistyp auswählen um dafür ein neues Ereignis zu erstellen. Unter anderem auch das benutzerdefinierte Ereignis. Dem gibst du dann einen Namen und in der Aktion kannst du es anschließend mit diesem Namen ansprechen.

Nein, der Auslöser ist kein Objekt auf der Anlage. Weder ein Schalter, noch ein Zug, ein Gleisstück, ein Kontaktpunkt oder eine Animation. Und auch kein Timer in der EV. Der Auslöser für benutzerdefinierte Ereignisse ist ein Eintrag in einem anderen Ereignis. Für ein Beispiel fehlt mir aktuell die Zeit. Brauchst du aber auch nicht. Du kommst wunderbar ohne benutzerdefinierte Ereignisse zurecht bis du irgendwann, eines Tages mal denkst: "An dieser Stelle wäre es praktisch, wenn ich aus diesem Ereignis heraus ein anderes Ereignis auslösen könnte." Und wenn dieser Wunsch aufkommt, dann ist das benutzerdefinierte Ereignis das, was du suchst.

Ja, Quackster. Haben sie alle. Jeder, der hier etwas erklärt und somit zum besseren Verständnis der EV beigetragen hat, hat dazu auch kleine Demoanlagen gebaut. Dazu gab es dann entweder Erläuterungen in schriftlicher Form oder in Form eines Videos. Dann geh bitte mal in dich und suche danach, was es ist. Denn irgendetwas macht dich gerade grantig und ungerecht. Es verstellt dir den Blick für all die Mühen, die sich einige hier schon gemacht haben um ihre Erkenntnisse mit der ganzen Gemeinschaft zu teilen. Frag dich bitte mal selbst, warum du nicht siehst bzw. nicht schätzt, was andere beitragen. Und warum du nicht akzeptieren kannst, dass es für andere genauso viel Mühe bedeutet und daher auch nicht alles perfekt ist. Warum du nur für dich in Anspruch nimmst sagen zu dürfen "besser kann ich es eben nicht". Aber an andere die Forderung stellst, sie mögen bitte alles perfekt abliefern. Warum du die Mühen anderer einfach mit einem "ist mir nicht gut genug" vom Tisch wischt. Verständnisvolle Grüße Götz

Hallo Quackster Das hatte zwei Gründe. Erstens muss man ein Werkzeug kennenlernen, bevor man es anwendet. Im konkreten Fall: Man muss Lua im Kern verstehen, bevor man Weichen damit schaltet. Zweitens wären zu dem Zeitpunkt, als die Einführung entstand noch nicht möglich gewesen, weil es das MBS mit Lua (sprich V5) noch nicht gab. Daher war der Zeitpunkt ideal, um vorbereitend denjenigen, die daran Interesse hatten, Grundlagen zu vermitteln. Konkrete Anleitungen zur grafischen EV (zuerst) und zu Lua (im Anschluss) sind geplant, haben sich aber durch äußere Umstände leider verzögert. Gruß Götz

und die scheinen mir, nach einer ersten Durchsicht von Variable "Überprüfung" wird gesetzt und Benutzerdefinierte Fahrt SB<KB das Ergebnis einer ungünstigen Taktik zu sein. Denn letztlich ist das, was passieren soll, vergleichsweise überschaubar. Ich habe mich noch nicht genügend in dein Konzept hineindenken können, um alternative Vorschläge (ohne Lua) anzubieten. Ich habe derzeit den Kopf auch noch nicht richtig frei dafür. Aber vielleicht schaffe ich es nächste Woche irgendwann, dir konkrete Verbesserungsvorschläge zu machen. Wenn du das möchtest.

Hallo Frank, darf ich dir einen Tipp geben? kannst du anders und viel schlanker strukturieren. Du rufst mit einer Vielzahl von Bedingungen jedesmal dasselbe benutzerdefinierte Ereignis auf und übergibst dabei unterschiedliche Werte. Damit muss deine EV viel zu viele Prüfungen durchlaufen, die schlicht nicht notwendig wären. Stattdessen könntest du die Werte, welche deine Entscheidungskriterien sind, an das benutzerdefinierte Ereignis übergeben. Und dort anhand dieser Werte ableiten, was zu tun ist. Die richtige Aktion zu den möglichen Kombinationen hinterlegst du dann am besten in einer Tabelle. Die ist fast immer die bessere Alternative zu mehreren verschachtelten if-Verzweigungen. Weil du beim if alle einzelnen Stationen durchlaufen musst. Einen Tabellenplatz kannst du hingegen direkt adressieren. Beispiel: Ein Signal soll auf Fahrt schalten, wenn zwei Weichen dahinter auf Gerade stehen. Bei Abzweig soll Langsamfahrt gezeigt werden. Signalstellung = { {3 , 3} , {3 , 2} } a = W1 + 1 b = W2 + 1 Stellung = Signalstellung[a][b] W1 und W2 stehen in diesem Pseudocode für die Stellungen der Weichen 1 und 2. Weil ich keine 0 gebrauchen kann, addiere ich noch eine 1 dazu. Mit der Stelle der ersten Weiche wähle ich entweder den erstenoder den zweiten Block aus. Mit der Stellung der zweiten Weiche wähle ich in dieser Gruppe entweder den ersten oder den zweiten Wert aus. Nur wenn beide Weichen die Stellung 1 haben (was durch das Hinzuaddieren von 1 dann eine 2 ergibt), lande ich im zweiten Block beim zweiten Wert. Es ist im Beispiel der einzige Fall, in dem die Stellung 2 (= Fahrt) ist. In allen anderen Fällen bekomme ich eine 3 (= Langsamfahrt). Es ist kein einziges if im Spiel. Lieben Gruß Götz

Die Kombination Beige - Purpurrot ist das Farbschema von TEE und Rheingold in den Siebzigern. Das ist längst Geschichte. Das gelb-graue Design ist die Farbgebung für Fahrzeuge der Systemtechnik und ein aktuelles Farbschema.

Das ist ein Ereignis, dass nicht durch Aktivitäten in der Anlage ("Signal schaltet", "Zug verlässt Gleis" etc.) ausgelöst wird, sondern durch eine Aktion in einem anderen Ereignis. Diese Aktion heißt Der Auslöser kommt also vom Benutzer. Das unterscheidet dieses Ereignis von den Übrigen. Im Ereignis passieren dann dieselben Dinge wie in anderen Ereignissen auch. Vielleicht hilft es, wenn du dir ganz generell die folgende Denkweise angewöhnst: Die Ereignisse sind die Auslöser für die EV. Also Signal schaltet, Variable ändert sich, Timer läuft ab und so weiter. All diese Dinge ereignen sich während des Betriebs. Egal, ob du damit etwas anstellst oder nicht. In der Ereignisverwaltung legst du dann fest, welche Aktionen als Reaktion auf solch ein Ereignis ausgeführt werden sollen. Und in diesem Sinne geht es beim benutzerdefinierten Ereignis um einen vom Benutzer initiierten Auslöser.

Du (doch) nicht. Aber andere Menschen tun das. Und war es nicht erst vor ein paar Tagen, dass jemand sich für das MBS interessierte und vorab hier ein oder zwei Fragen dazu gestellt hatte?

Das wäre eine ziemlich sichere Methode, Neuzugänge zu verhindern. Kaum einer möchte Mitglied in einem Club werden, den er von außen nicht einsehen kann.

Hallo Timba, alternativ kann man das Monstergleis, welches ja seinen Bestimmungsort schon gefunden hat, auch mittels Heftzwecke anpinnen. Dann ist es nur noch per Doppelklick oder Modellliste auswählbar, lässt sich in diesem Fall aber bequem "am Stück" handhaben. Gruß Götz

Oh, tut mir leid Michael. Ich kann ehrlich nicht sagen, warum ich deinen Namen verwechselt habe.

Die Befehle selbst erzeugen keine neuen Kopien. Bei Bahnland ist die Tabelle, die er als Ziel für table.insert angegeben hat, eine Kopie. Ob das bei dir ebenso der Fall ist muss ich mir anschauen. Und synchronisiert wird per se gar nichts. Weder in Lua, noch in anderen Sprachen. Entweder verbirgt sich hinter zwei Namen dieselbe Adresse oder nicht. Die Sache ist deshalb ein wenig "tricky", weil man genau hinschauen muss, wo was übergeben wird. In Lua läuft es so ab: Liste_1 = {"John", "Paul", "George", "Ringo"} Liste_2 = Liste_1 -- Kopie oder Weitergabe der Adresse? s = table.concat(Liste_2, "\n") -- alle Texte der Tabelle in einen String print("Liste 2\n"..s.."\n") -- sieht aus wie Liste_1 table.insert(Liste_1, 1, "Stewart") s = table.concat(Liste_1, "\n") -- alle Texte der Tabelle in einen String print("Liste 1:\n"..s.."\n") -- Liste 1 hat einen neuen Namen dazu bekommen s = table.concat(Liste_2, "\n") -- alle Texte der Tabelle in einen String print("Liste 2:\n"..s.."\n") -- Liste 2 ebenfalls, weil nur die Adresse übergeben wurde. Es ist dieselbe Tabelle! -- Das heißt: umgekehrt wirkt sich eine Änderung in Liste_2 auch auf Liste_1 aus. table.insert(Liste_2, 1, "The Beatles") s = table.concat(Liste_1, "\n") -- alle Texte der Tabelle in einen String print("Liste 1:\n"..s.."\n") -- Liste 1 hat einen neuen Namen dazu bekommen Selbst dann, wenn man eine globale Tabelle als Funktionsargument übergibt, bleibt es dieselbe Adresse: Liste_1 = {"John", "Paul", "George", "Ringo"} function Test(Liste_2) table.insert(Liste_2, 1, "The Beatles") local s = table.concat(Liste_2, "\n") print("Liste 2:\n"..s.."\n") end Test(Liste_1) s = table.concat(Liste_1, "\n") print("Liste 1:\n"..s.."\n") In diesem Punkt ist Lua wirklich eigenartig. Eine Variable wäre als Funktionsargument lokal definiert. Sie könnte sogar den selben Namen haben, wie die globale Variable und würde dennoch nichts mit ihr zu tun haben. Eine lokale Änderung hätte keine globale Auswirkung. Aber bei der Tabelle wird nur die Adresse an den lokalen Träger übergeben. Und die weist auf dieselbe Tabelle. Aber in der EV von MBS passiert mehr als nur Lua. Die Übergabe von einem Ort (Objekt, Modul etc.) zum anderen wird nicht von Lua erledigt. Sonst gäbe es keine adressierbaren Objekte. Die kennt Lua nämlich so nicht. Dahinter steckt Neos Cleverness! Und bei der Übergabe einer Tabelle in der EV wird diese Tabelle kopiert. Deshalb ist es ratsam, nur das Objekt zu übergeben, welches die Tabelle beherbergt. Denn wenn ich das Objekt (und die darin enthaltene Tabelle) anspreche, dann ist es das Original.