Goetz

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.

Keine Variable, sondern die ganze Tabelle. Mit bekommst du: Aber diese Tabelle ist eine Kopie. Und alles, was du hier in "FzListe" speicherst, landet in dieser Kopie und nicht in der ursprünglichen Tabelle. Zu deinen neuen Fragen muss ich erst einmal schauen, was da im Einzelnen passiert ...

Hallo BahnLand, die Argumente FzListe bzw. FzTabelle enthalten in den Ereignissen für die Kontakte 1 und 2 eine Kopie deiner Tabellen aus den Kontaktpunkten. Diese Kopie wird mit dem Inhalt der temporären Liste "namen" befüllt, aber nicht das Original. Damit versickert FzListe bzw. FzTabelle im Lua Code und wird an niemanden im MBS weitergereicht. Du erkennst das daran, dass das Ereignis "Objekt Variable wird gesetzt" nicht getriggert wird. Im Kontakt 3 übergibst du nur den Kontakt selbst als Argument und sprichst dann im Code direkt die Tabelle in diesem Objekt an. Damit erreichen die Daten das gewünschte Ziel. Viele Grüße Götz

Hallo Axel, du hast zwar schon viele Vorschläge zur Verbesserung bekommen, aber noch keine vollständige Antwort auf diese Frage. Du hast mehrere Ereignisse mit dem selben Auslöser "Ein Zug/Fahrzeug betritt Gleis/Straße Block 16" Wenn also ein Auto dieses Gleisstück betritt, dann werden alle Aktionslisten ausgeführt, die diesen Auslöser haben. Und weil die sowieso alle ausgeführt werden, kannst du auch sämtliche Befehle in ein einziges Ereignis schreiben statt sie auf mehrere zu verteilen. Das reduziert die Rechenlast. Das nur zum besseren Verständnis der Zusammenhänge. Lösungsvorschläge für deine konkrete Anwendung hast du ja schon Götz.

Hallo Martin, hinter deinen folgenden beiden Aussagen verbirgt sich ein grundsätzliches Missverständnis. Das würde ich gerne aufklären, weil das in sehr vielen Fällen zu falschen Denkansätzen führen kann. Außerdem ist dieses Missverständnis ein Klassiker und passiert vielen. Es ist nicht zu langsam, sondern im Gegenteil zu schnell. Nein, so ist es eben nicht. In deinem Beispiel mit der Lackdose führst du den dritten Schritt erst dann aus, wenn die zweite Aktion abgeschlossen ist. Aber in der EV passiert etwas anderes. Die EV gibt dem Zug nur den Befehl "Beschleunige" und führt dann sofort den nächsten Schritt aus. Sie wartet nicht ab, bis der Zug beschleunigt hat. Du würdest mit der EV keine Farbe auf die Wand kriegen, weil du gleich nach dem Befehl "Verstreich die Farbe" den Deckel wieder schließen würdest. Es bliebe nicht einmal die Zeit, den Pinsel in die Dose einzutauchen. Noch etwas präziser: Wenn der Maler den Befehl wahrgenommen hat, dann sieht er schon wieder eine geschlossene Dose. Ich hoffe, das hilft dir weiter Götz

kann niemand hier einbringen, weil sie gegen solche Maßnahmen geschützt sind. Einzige Ausnahme wäre der Konstrukteur des EEP-Modells selbst. Der hat die Konstruktionsdaten und könnte sie somit auch anderweitig einsetzen.

Da ich das Bild gerade fertig habe (und es vielleicht anderen hilft, Bedingungen besser zu verstehen) ...: Ich wüsste übrigens kein Ereignis, in dem deine Vorgehensweise funktionieren würde. Das Einzige, was eine wiederholte Prüfung der Bedingung zur Folge hätte, wäre das Ereignis "Timer ist abgelaufen". Und in solch einem Ereignis wäre deine Bedingung nie erfüllt.

Es gibt ein Ereignis, dass jedesmal, wenn es eintritt, deine Aktionsliste einmal triggert. In dem Augenblick, wenn ein Zug deinen Kontakt betritt, wird die zugeordnete Aktionsliste genau einmal abgearbeitet. Bedingungen in dieser Liste sind dann jeweils "entweder/oder" Entscheidungen. Aber der Ablauf nimmt nur einen Weg. Entweder diesen oder jenen. Wird der Kontakt erneut betreten, dann wird die Aktionsliste ein weiteres Mal abgespult. Das Bedingungen ein entweder/oder bedeuten ist keine Besonderheit der EV. Das findest du genau so in jeder Programmiersprache.

Nein, das ist nicht unlogisch. Jede Bedingung wird nur einmal geprüft. Bedingungen sind kein "Dauerbrenner", der bei jeder Änderung erneut reagiert. Du musst lernen, Bedingungen und Ereignisse zu unterscheiden.

In Anlehnung an den Text in der Titelsequenz: "... ein Modell zu bauen, dass nie ein Mensch zuvor gebraucht hat"

Das ist einfacher als dein Konstrukt