Goetz

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.

Das deckt sich zumindest mit meiner Vermutung.

Klick einfach aufs Profilbild eines Users, Claudia. Dann siehst du eine Auflistung all seiner Beiträge hier. Und mit einem Klick auf den blau hervorgehobenen Namen im Posting klappt es auch. Nachtrag: Auf meinem Profilbild siehst du auch, wo ich gerade bin. Ich hocke auf dem Fußboden und spiele

Ich denke nicht, dass du einen Denkfehler machst, sondern dass Lua sich hier unorthodox verhält. Vielleicht liegt es daran, dass die erste Lücke sozusagen vor der Tabelle liegt. Die Lücken liegen in Lua nicht sortiert vor. Deshalb hast du keine Kontrolle darüber, welche Lücke Lua wann wählt. Beispiel = {"Eins"} Beispiel[4] = "Vier" Beispiel[5] = "Fünf" Beispiel[9] = "Neun" table.insert(Beispiel, "Zwei") table.insert(Beispiel, "Drei") table.insert(Beispiel, "Sechs") table.insert(Beispiel, "Sieben") table.insert(Beispiel, "Acht") table.insert(Beispiel, "Zehn") for i = 1, 10 do print(("%2d - %s"):format(i, Beispiel[i])) end Das Wort "Zehn" ist an Position 11 eingefügt worden und deshalb in der Auflistung gar nicht zu sehen.

Der aufwändige Mechanismus zum Tauschen der Werte muss in Lua eigentlich nicht sein. Denn Lua erlaubt diese Schreibweisen: a, b = b, a a, b, c, d, e = b, c, d, e, a Aber beim Versuch das so zu vereinfachen bin ich vorhin gescheitert. Drum habe ich den Tauschmechanismus erst einmal ganz klassisch geschrieben.

Es hat mir doch keine Ruhe gelassen Das ist mein Vorschlag für das Skript: Wuerfel = {$("Quader_1"), $("Quader_2"), $("Quader_3"), $("Quader_4"), $("Quader_5")} Tausch = { [1] = function(w1, w2, w3, w4, w5) local temp = w1.transformation.position w1.transformation.position = w2.transformation.position w2.transformation.position = w3.transformation.position w3.transformation.position = w4.transformation.position w4.transformation.position = w5.transformation.position w5.transformation.position = temp end, [2] = function(w1, w2, w3, w4, w5) local temp = w1.transformation.position w1.transformation.position = w2.transformation.position w2.transformation.position = temp temp = w3.transformation.position w3.transformation.position = w4.transformation.position w4.transformation.position = w5.transformation.position w5.transformation.position = temp end } function neueAufgabe() for i = #Wuerfel, 2, -1 do table.insert(Wuerfel,table.remove(Wuerfel, math.random(i))) end Tausch[math.random(2)](Wuerfel[1], Wuerfel[2], Wuerfel[3], Wuerfel[4], Wuerfel[5]) end Die Würfel dürfen eine beliebige Startposition haben. Sie tauschen immer nur ihre Plätze. Drückt man den blauen Knopf (rechts), dann wird bei Stellung 1 die Funktion neueAufgabe() aufgerufen. Nach einer kurzen Verzögerung wird der Knopf wieder in Stellung 0 zurückgesetzt. Die Beispielanlage habe ich angehängt. Viel Spaß damit Götz TimeSaver Shuffle 01.mbp

Jetzt habe ich (endlich) die richtige Idee dazu gehabt. Mal schauen, ob ich es in verständliche Worte fassen kann, weil ich noch nicht die Ruhe habe es wirklich umzusetzen. Unser Enkelsohn meinte: "Schieb alle eins weiter. Dann hat jeder Klotz eine andere Position. So mach ich das immer." Für einen Neunjährigen fand ich das clever. Aber es wäre natürlich unbefriedigend, weil zu vorhersehbar und nicht zufällig genug. Deshalb hatte ich seinen Vorschlag gleich wieder verworfen. Zu Unrecht, wie ich gerade erkannte. Denn wenn man zuerst die fünf Würfel (mit ihren aktuellen Positionen!) in eine beliebige Reihenfolge bringt und dann den Ringtausch durchführt, dann kann jedes legitime Ergebnis herauskommen und garantiert kein Klotz an seinem Platz verbleiben. Nächste Woche probiere ich es gerne selbst aus. Aber wenn mir jemand zuvor kommen möchte: Nur zu. Ich würde mich freuen. Götz Korrektur: Auch wenn ich die Würfel vorab in eine beliebige Reihenfolge bringe und dann den Ringtausch durchführe, können nicht alle erdenklichen Lösungen entstehen. Denn bei diesem Ansatz können zwei Würfel nie ihre Plätze tauschen (was aber legitim wäre.) … Mist!!! Erweiterung der Methode: Im Prinzip kann es nur zwei Muster beim Positionswechsel geben. Entweder A: ein Ringtausch von 5 Positionen. Oder B: ein Ringtausch für drei Würfel und die verbleibenden zwei tauschen miteinander. Bitte dabei im Hinterkopf behalten, dass zuvor die Reihenfolge der Würfel zufällig geändert wurde. Die Tauschpartner sind also zufällig, aber die Positionsdaten werden anschließend nach einem der beiden genannten Muster weitergereicht. Alle legalen Ergebnisse stimmen mit einem der beiden Muster überein. Und die beiden Varianten verteilen sich (vermutlich) 50:50 auf die möglichen Ergebnisse. Wenn man also zufällig Muster A oder B auswählt und die Positionen der beliebig sortierten Würfel diesem Muster folgend weitergibt, dann müssten doch alle legitimen Ergebnisse dieselbe Chance haben und die nicht legitimen (mit Würfen am alten Platz) ausgeschlossen sein.

Ist das wirklich ein Schloss? (engl. lock) Oder ein Eintrag in einer Liste? (engl. log) Oder ist die Lokomotive gemeint? (deutsche Kurzform: Lok) Ich tippe auf log, denn das passt am besten zu einem Eintrag, der z.B. den Zugnamen enthalten kann. (siehe Logbuch) Sorry - Zwischenfrage hat sich erledigt. Der erste, der sich einträgt, belegt die Variable und verriegelt dadurch etwas. Deshalb "lock".

Your second version should work if you alter my code a little bit. Your first list produced an error because in Lua you may not leave a field empty. Your third list failed because in Lua an empty string is considered true (and equally a 0 is considered true too) I built the previous example according to your request and it only checked for a switch 3 value when one for switch 2 was present. Here's the fix, where every switch is checked individually: Pos = { T1 = {0, nil, 1}, T2 = {1, 0}, T3 = {1, 1, 0} T4 = {nil, 1, nil, nil, 0, 1} } trajet = vehicle.variables["Trajet"] if Pos[trajet][1] then $("SW1").state = Pos[trajet][1] end if Pos[trajet][2] then $("SW2").state = Pos[trajet][2] end if Pos[trajet][3] then $("SW3").state = Pos[trajet][3] end if Pos[trajet][4] then $("SW4").state = Pos[trajet][4] end if Pos[trajet][5] then $("SW5").state = Pos[trajet][5] end if Pos[trajet][6] then $("SW6").state = Pos[trajet][6] end Better build this in a loop. To do so, you need the switch objects in a table too: Pos = { T1 = {0, nil, 1}, T2 = {1, 0}, T3 = {1, 1, 0} T4 = {nil, 1, nil, nil, 0, 1} } SwitchList = {$("SW1"), $("SW2"), $("SW3"), $("SW4"), $("SW5"), $("SW6")} trajet = vehicle.variables["Trajet"] for k, v in pairs(SwitchList) do if Pos[trajet][k] then v.state = Pos[trajet][k] end end Please note that you must enter the switch objects into your list by typing the Dollar-Sign and then picking the item from the object list. The names are only a reminder and do not function as a reference! Hence you cannot copy the complete switch table from my example. My entire construct is not an ideal solution. I did my best to stay close to your attempt. My observation is that people learn best when they can build on what they already know.

Hello André see if this works, please Pos = { T1 = {0} T2 = {1, 0} T3 = {1, 1, 0} } trajet = vehicle.variables["Trajet"] $("SW1").state = Pos[trajet][1] if Pos[trajet][2] then $("SW2").state = Pos[trajet][2] if Pos[trajet][3] then $("SW3").state = Pos[trajet][3] end end greets Goetz

und die bringt großartige Resultate hervor.

Versuch mal die Anlage in V4 zu exportieren und dann diese .mbp in V5 zu laden ... Geht das?