Goetz

Hallo Tom, hattest du bei meinem Video den Eindruck, dass ich damit Probleme gehabt hätte? greets Götz

Vielen Dank. Das kann ich gut gebrauchen.

No, that's never a good idea. Your problem would be to keep your layout and the external data in sync. If you let your layout run for a while, all sorts of data will change and be entered into the external file. If at the end of your session you leave the MBS without saving your layout, the data in your external file no longer matches the state of your unchanged layout.

Best answer: Wait for the next update, which is coming soon. It will offer two new data types for object variables and module variables: lists and tables (difference being, that lists have consecutive numbers as cell indexes, whereas tables have named cells) It even allows for nested lists and tables in any combination. You may for instance list all your waggons by storing a table for each waggon (name, cargo, destination ...) inside your list of waggons. Alternative: (not recommended, but available now): convert your table contents into one long string and store that as text in one of your object/module variables. You'll need to write your own parser to convert it all back into a table. Do you know that you can (already) use any vehicle you know (say: the one that just triggered a contact) to ask the event manager for a list of all vehicles in the same train?

The track name is a string, containing a number. I didn't check the rest of your code properly. Sorry. your condition needs to be if voie == "6" then

Your code works just fine. But instead of printing "liste" you may want to print out the elements inside the table: voie = track.name print (voie) table.insert(liste, voie) if voie == 6 then vehicle.currentSpeed = 0 for k, v in ipairs(liste) do print("liste ", k," contains ", v) end end And to initialise your list, you may use liste = {} because all lists (actually tables) in Lua are dynamic. Besides, your Letters A to F were considered variables with the content nil. Your initial list had no elements.

Stimmt - ich verstehe wirklich nicht, was an meiner Kritik "herablassend" war. Aber ich akzeptiere, dass es (nicht nur von dir) so empfunden wird. Und ich halte mich zukünftig mit kritischen Äußerungen zurück.

Tut mir leid, SputniKK, aber so einseitig geht das nicht. Wer Lob sucht, der muss auch Kritik ertragen können. Du kannst nicht einfach nur das eine wollen und das andere verbieten. Wie Neo schon sagte, ist Kritik keine Einflussnahme. Egal, was ich zu deinem Modell auch äußere - es ändert nichts daran, dass du es ungehindert so bauen darfst, wie du möchtest. Kritikern den Mund verbieten und nur Lob hören wollen (und wie im Falle von FeuerFighter gleich mit Rückzug drohen, weil es neben all denen, die voll des Lobes waren, einen einzigen gab, der Kritik geäußert hat) haut nicht hin ...

Nein, die ist nicht die Ursache. Diese Verzögerung soll nur sicherstellen, dass bei übernommenen Anlagen die Reihenfolge von Aktionen beibehalten wird. Eine Verzögerung von 0 bewirkt, dass der nachfolgende Befehl erst im nächsten Frame (sprich: bei der Berechnung des nächsten Bildes) ausgeführt wird. In deinem Fall scheint aber trotz dieser Maßnahme genau das Problem zu entstehen, welches durch Verzögerung 0 verhindert werden soll. Bei der erneuten Prüfung deiner Bedingung für das Ereignis 1 ist die Anzahl gestarteter Züge offenbar noch nicht richtig registriert. Um nach der eigentlichen Ursache zu forschen, müsste ich aber die tatsächliche EV anschauen. Vielleicht kannst du die Aufgabe in V5 einfacher lösen? Ich habe den Verdacht, dass das Aktivieren und Deaktivieren von Ereignissen durch die Arbeitsweise der V3 bedingt war und in der V5 gar nicht mehr nötig ist.

Ich meine die Fenstereinfassungen aus hellbraunem Holz, Feuerfighter. die sind nicht modelliert sondern aus schrägem Winkel fotografiert.

Was hat es mit dem Alter zu tun, wenn ich vom linken Fensterrahmen die Innenseite sehe aber nicht vom rechten? Es sieht einfach falsch aus, wenn man Fenster einsetzt, die aus der Schräge fotografiert wurden.

Sorry FeuerFighter, aber die Fenster funktionieren aufgrund der perspektivischen Verzeichnung so nicht. Man sieht das Problem gut an der schmalen Hauswand rechts im dritten Bild.

Die wird bei meinem letzten Lua-Skript automatisch erkannt. Die Variablen im Vorderteil sind mit dieser neuen EV nicht mehr erforderlich. Stattdessen wird jetzt über das auslösende Fahrzeug der ganze Zugverband abgefragt und alle Fahrzeuge in diesem Verband in eine Tabelle eingetragen.

Oh, Easy - das hast du in den falschen Hals gekriegt. Tut mir leid. Ich meinte, dass die "Hilfe zur Selbsthilfe" effektiver ist. Nicht, dass jeder selbst sehen soll, wo er sein Wissen herbekommt. .

Wenn der Abstand zwischen der letzten Station und dem BÜ so kurz ist, dass man die Schranken nicht per Kontakt schließen kann, dann würde ich machen, was die reale Bahn auch tut: Erst die Schranken schließen und dann die Ausfahrt aus dem Bahnhof freigeben (wenn die Schranken wirklich geschlossen sind.) Das Ende der Animation ist ein Ereignis, welches man nutzen kann. Das heißt, dass das Schließen (zumindest aus Richtung des Bahnhofs) überhaupt nicht durch einen eigenen Kontakt ausgelöst wird, sondern Teil der Sequenz ist, die auch die Ausfahrt aus dem Bahnhof frei gibt.

Ja, für meinen Geschmack ist sowohl die Blinkfrequenz als auch das Heben/Senken der Schlagbäume zu schnell.

Ich habe auf Twitch an ein paar kleinen Beispielen gezeigt, was man mit der EV im 3D-Modellbahn Studio V5 erreichen kann. Die "geputzte" Fassung dieser Sendung ist jetzt auf YouTube verfügbar. Ich habe mich bemüht, die EV von Grund auf zu erklären. Ich setze keinerlei Grundkenntnisse voraus, sondern erkläre im Detail, wie ich vorgehe und warum. Ich will in nächster Zeit eine zweite Sendung machen, in der ich das hier gezeigte aufgreife und weiterführe.

Aber das bleibt nicht hängen, wenn man es gesagt bekommt. Weil die Information damit beliebig ist und mit nichts verknüpft wird. Probiert man es hingegen selber aus, dann sammelt man erstens Erfahrung mit Lua im Allgemeinen und getVehicleGroup() im Speziellen. Und freut sich zweitens über das, was man herausfindet. Mit der Freude bekommt es Gewicht und mit dem Gewicht (und der aktiven Beschäftigung) findet es im Hirn Stellen, an denen es andocken kann. Assoziationen sind ein wichtiger Klebstoff für Erinnerungen. Welche Kupplung ist die vordere und welche die hintere?

Das weiß ich nicht. Und es ist nicht der einzige Fehler in diesem Zusammenhang. Wenn es nämlich kein Bremslicht gibt (weil man ein anderes Straßenbahn-Modell benutzt), steigt die EV bei der ersten Anwendung des Bremslichts aus der Routine aus, weil unter der angegebenen Adresse kein stop() Befehl gefunden wird. Ich denke nur, dass es so schon genügend Stoff für eine Lektion ist. Mir ist nicht daran gelegen das perfekte Skript für alle Fälle vorzustellen. Ich suche vielmehr nach überschaubaren Beispielen, anhand derer man die einzelnen Bausteine der EV besser begreifen kann. Man muss die Werkzeuge kennenlernen, bevor man damit etwas richtiges baut. Und zum Kennenlernen eigenen sich "Gesellenstücke" mit geringem Nutzen besser, weil man sich auf die Anwendung der Werkzeuge konzentrieren kann. Um genau solche Fragen geht es. Das Beispiel ist so klein und überschaubar gehalten, dass man es mit Leichtigkeit selbst ausprobieren kann. Nimm ein leeres Oval, setzt einen Kontakt darauf und bastle dir mit den Erkenntnissen aus meinem Beispiel deine eigene EV, die einfach nur die Namen der Fahrzeuge im Zugverband auflistet. Dann ändere deinen Zug immer wieder kunterbunt, fahre über den Kontakt und schau, was passiert.

Mir fehlte der richtige Funktionsaufruf um zu einem auslösenden Fahrzeug in Lua den kompletten Zugverband zu erhalten. Deshalb hatte ich den Umweg in Kauf genommen, Mittel- und Hinterteil in Objekt-Variablen im Vorderteil zu speichern. Vielleicht war das auch für den Anfang ganz gut so, weil nachvollziehbar. Aber inzwischen habe ich Neo um den nötigen Tipp gebeten. Die Funktion heißt layout:getVehiclesGroup(Fahrzeug_im_Zugverband) Richtiger: In der Tabelle layout steht eine Funktion getVehiclesGroup(), der man beim Aufruf ein Element aus dem Zugverband übergeben muss. Man bekommt eine Liste aller Objekte zurück, die den Zugverband ergeben. Bitte achtet auf den Doppelpunkt zwischen layout und getVehiclesGroup() damit die Funktion Zugriff auf die Tabelle aller Elemente der Anlage hat. Damit kann man auf die Variablen im Vorderteil verzichten. Vorteil: Es besteht kein Unterschied mehr zwischen Einzel- und Doppeltraktionen. Hier ist eine neue Beispielanlage, in der ich diese Liste nutze. Das enthaltene Skript sieht so aus: local Blinker = {} local Tueren = {} local Zug = layout:getVehicleGroup(vehicle) for k, Waggon in ipairs(Zug) do if Waggon.animations["Blinker rechts"] then table.insert(Blinker, Waggon.animations["Blinker rechts"]) end if Waggon.animations["Tür rechts vorne"] then table.insert(Tueren, Waggon.animations["Tür rechts vorne"]) end if Waggon.animations["Tür rechts hinten"] then table.insert(Tueren, Waggon.animations["Tür rechts hinten"]) end end local Bremslicht = Zug[#Zug].animations["Bremslicht hinten"] if not deferredCall then vehicle.deceleration = 2 vehicle.acceleration = 3 vehicle.targetSpeed = 0 Bremslicht:stop(1) defer(3, "Blinker an") elseif deferredCall == "Blinker an" then for k, Blink in ipairs(Blinker) do Blink:play(0, 1) end defer(4, "Tür auf") elseif deferredCall == "Tür auf" then for k, Tuer in ipairs(Tueren) do Tuer:play(0, 1) end defer(7, "Tür zu") elseif deferredCall == "Tür zu" then for k, Tuer in ipairs(Tueren) do Tuer:play(1, -1) end defer(2, "Abfahrt") elseif deferredCall == "Abfahrt" then vehicle.targetSpeed = 50 Bremslicht:stop(0) defer(1.5, "Blinker aus") elseif deferredCall == "Blinker aus" then for k, Blink in ipairs(Blinker) do Blink:stop(0) end end Ich habe mich entschlossen, zunächst die Adressen der Blinker und Türen des auslösenden Zuges in lokalen Tabellen zu sammeln. Das hat meines Erachtens den Vorteil, dass ich anschließend diese Tabelle in einem Rutsch ansprechen kann. In Zeile 3 fordere ich die Fahrzeugliste zum auslösenden vehicle an. In den Zeilen 5 bis 15 prüfe ich, welches der Fahrzeuge überhaupt einen "Blinker rechts", eine "Tür rechts vorne" oder eine "Tür rechts hinten" hat. Alle Blinker und Türen, die ich dabei finde, übertrage ich in zwei lokale Tabellen "Blinker" und "Tueren" Ab Zeile 19 passiert dann weiter nichts neues im Vergleich zur ersten Version. Ich bediene mich jetzt nur aus den oben angelegten Tabellen und nicht mehr aus Variablen im Vorderteil. Zeile 17 ist noch eine kleine Besonderheit. Mit Zug[#Zug] bekomme ich das letzte Element der Tabelle. Denn #Zug ist die Anzahl der Elemente in der Tabelle Zug. Und weil Lua Tabellen mit 1 beginnen, ist die Anzahl zugleich auch der Index des letzten Elements. Das bedeutet: Mit dem Konstrukt in der Zeile 17 merke ich mir die Adresse des Bremslichts im letzten Waggon. Beispielanlage mit obigem Skript: StraBa Tabellen 01.mbp

Das wird wieder ein Minimax Modul, auf das ich mich riesig freue! Das Bahnhofsgebäude ist eine Wonne.

Genau. Mit einem Komma werden in Lua mehrere Parameter oder mehrere Tabellenelemente voneinander getrennt. Das Dezimaltrennzeichen ist - wie im Amerikanischen üblich - der Punkt. Meines Wissens gilt das für alle Programmiersprachen. Das erfordert aber ein anderes Prinzip. Mit dem deferredCall geht das nicht! Ich möchte als Nächstes lieber zeigen, wie man Signale in die Steuerung mit einbindet. Doppeltraktionen hebe ich mir bis zur Freigabe der Listen und Tabellen auf. Das wird damit deutlich einfacher!

Ich kenne sie als D-Bahn und bin damit täglich zur Schule gefahren. Damals hatte die noch ein Speiseabteil in der Mitte. Und damals hieß die Station in Huckingen noch Huckingen und war ebenerdig.

Vielleicht hilft dir dabei folgendes: Vergiss mal für einen Augenblick, dass Pausenzeiten im Spiel sind. Betrachte zunächst nur, dass diese Funktion sich selbst aufruft und in einer Verzweigung den Parameter prüft, den sie beim Aufruf mitbringt: function Beispiel(Parameter) if not Parameter then -- gleichbedeutend mit: if Parameter == nil or Parameter == false then print("erster Aufruf. Parameter war leer oder false") Beispiel("Eins") elseif Parameter == "Eins" then print("neuer Aufruf. Im Argument stand: ", Parameter) Beispiel("Zwo") elseif Parameter == "Zwo" then print("neuer Aufruf. Im Argument stand: ", Parameter) Beispiel("Dings") elseif Parameter == "Dings" then print("letzter Aufruf. Im Argument stand: ", Parameter) end end Beispiel() -- Beim ersten Aufruf ohne Parameter Der einzige Unterschied zwischen meinem Beispiel und dem defferredCall ist, dass als weiterer Parameter eine Zeit (in Sekunden) übergeben wird und das MBS den nächsten Aufruf erst dann ausführt, wenn diese Zeit abgelaufen ist.

Exzellent, Hans Das ist völlig in Ordnung. Ich würde sagen, dass du es verstanden hast. Ich weiß nur nicht, ob du dem Bremslicht eine eigene Verzögerung gegeben hast, weil du das gerne so wolltest? Oder ob du nicht wusstest, dass du das Bremslicht mit in einen anderen, vorhandenen Abschnitt einbauen könntest. Auf jeden Fall hast du aber bewiesen, dass du auch das Prinzip des deferredCall richtig verstanden hast. Im Gegenteil Das finde ich sogar sehr gut, weil so die Dinge zusammenbleiben, die zusammen gehören. Die Idee mit der Nachtzeit ist übrigens klasse. So sieht man viel besser, wann Bremslicht oder Blinker an- bzw. ausgehen. Nur eine Kleinigkeit. Da es nur ein Bremslicht gibt, kannst du auf die Tabelle verzichten und der Achse einfach einen Namen geben: local Bremslicht = vehicle.variables["Hinterteil"].animations["Bremslicht hinten"] -- .... Bremslicht:play(0, 1) -- .... Bremslicht:stop(0) -- .... Ich freue mich riesig über deine Version der Testanlage Götz