Andy Geschrieben 11. September 2019 Geschrieben 11. September 2019 (bearbeitet) Wenn Du jetzt noch bei 1. vom Typ Name auf Typ Objekt umschaltest, reduziert sich der Ausdruck auf: $("Lokschuppen").variables["FZG"].variables["Garage"] und ist schneller, weil er nicht suchen muß, sondern direkt mit der Objektreferenz arbeiten kann. Vermeide den Typ Name, wenn der Typ Objekt möglich ist. 'Name' ist für V4-Kompatibilität, würde ich sagen. Gruß Andy p.s.: wenn Du auf Objekt umstellst, merke Dir was da vorher gestanden hat, mußt Du dann nämlich neu auswählen, das ist der einzige Haken an der Sache. Die Zuweisung an die OV mußt Du natürlich auch umstellen, wenn es keine Konstante ist. Bearbeitet 11. September 2019 von Andy
Timba Geschrieben 11. September 2019 Autor Geschrieben 11. September 2019 vor einer Stunde schrieb Andy: Wenn Du jetzt noch bei 1. vom Typ Name auf Typ Objekt umschaltest, reduziert sich der Ausdruck auf: $("Lokschuppen").variables["FZG"].variables["Garage"] Nee, mit der Syntax hatte ich es ja versucht. Da kommt nix. Muss falsch sein. Bei $("Lokschuppen").variables["FZG"] kommt der Name der Lok, das klappt. Aber wenn ich .variables["Garage"] anhänge kommt nix. Es müsste aber die Zahl "10" als Ergebnis kommen. Mit diesem Entity-Gedöns klappt es.
Andy Geschrieben 11. September 2019 Geschrieben 11. September 2019 Ich will Dich nicht schon wieder verwirren. Wenn's Dir so gefällt, lass es so. Aber ich hatte ja auch noch ein "Wenn Du.." vornedran geschrieben. Ohne das geht's nicht, das ist klar. Die OV haben Typen: Boolean, Zahl, Text, Name und auch Objekt. Dort müßte die Änderung stattfinden. Ich bin überzeugt, das findest Du früher oder später auch selbst raus. Gewinne beim derzeitigen Wissen erstmal an Stabilität, der Rest kommt dann schon. Alles gut. Gruß Andy
Timba Geschrieben 11. September 2019 Autor Geschrieben 11. September 2019 vor 4 Minuten schrieb Andy: Gewinne beim derzeitigen Wissen erstmal an Stabilität, der Rest kommt dann schon. Du, Andy, ich bin schon Rentner, so viel Zeit ist da nicht mehr.
Andy Geschrieben 11. September 2019 Geschrieben 11. September 2019 (bearbeitet) Wir Hunde wollen ewig leben! Es ist nicht so, dass wir nicht mehr spielen, wenn wir alt werden, vielmehr werden wir alt, wenn wir nicht mehr spielen! (Zitat von .... weißnimmer) Bearbeitet 11. September 2019 von Andy
Timba Geschrieben 11. September 2019 Autor Geschrieben 11. September 2019 Ich glaube, ich bin dir Sache auf der Spur, was du mir durch die Blume sagen wolltest. Also, ich habe jetzt beim Objekt "Lokschuppen" die Objektvariable FZG von Name auf Objekt umgestellt. Dann war sie leer. Nun muss sie wohl neu zugewiesen werden, also lasse ich mit abgeändertem Befehl die Lok nochmal reinfahren und gucke was passiert.
Andy Geschrieben 11. September 2019 Geschrieben 11. September 2019 vor 1 Minute schrieb Timba: und gucke was passiert. Zuweisungszeile auch ändern, sonst schaltet er wieder auf Typ Name um und schreibt er den Namen rein!
Timba Geschrieben 11. September 2019 Autor Geschrieben 11. September 2019 vor 1 Minute schrieb Andy: Zuweisungszeile auch ändern Jepp, das war mir klar. Ich habe schon ein bisschen programmiert, nur nicht mit Lua. Aber ein paar grundsätzliche Dinge sind in jeder Sprache fast gleich.
Timba Geschrieben 11. September 2019 Autor Geschrieben 11. September 2019 Eine Frage hätte ich noch an die Lua-Experten bezüglich Ausführungsverzögerungen. Warum steht im Code (wenn er Verzögerungen beinhaltet) zu Beginn ein "if not deferredCall then"? Warum reicht ein einfaches "defer(x sec)" an der Stelle wo die Verzögerung sein soll nicht? Ist das zwingend notwendig damit der Code lauffähig ist oder einfach nur eine Sicherheit, falls der Code fehlerhaft sein sollte? Irgendwie konnte ich bisher nicht den Sinn dahinter entschlüsseln.
Andy Geschrieben 11. September 2019 Geschrieben 11. September 2019 Ein Programm kann nicht stehenbleiben, Timba. Wenn es in defer(x sec) nur eine Schleife laufen würde, bis die Zeit um ist, würden alle anderen Dinge nicht behandelt werden können. So setzt defer(x sec) stattdessen (vermutlich in einer Liste) einen Eintrag, dass es nach dieser Zeit wieder in dieses Ereignis zurückkehren soll, diesmal aber mit 'deferredCall' negiert, sodaß der andere Programmpart ausgeführt wird.
Timba Geschrieben 12. September 2019 Autor Geschrieben 12. September 2019 Ok. Nächste Frage (sagt Bescheid, wenn mein Kontingent an Fragen aufgebraucht ist ) : Ich habe in dem Tutorial von Goetz gelesen, dass Variablen bis auf wenige Ausnahmen grundsätzlich global sind, wenn keine anderslautende Vereinbarung getroffen wurde. Global heißt nach meinem Verständnis, dass sie für die gesamte Laufzeit und in allen Routinen gilt. Wenn ich nun eine Sammlung Daten, oder Tabelle heißt es wohl, in der Form von >Quatsch = {"eins", "zwei", "drei"}< in einem Ereignis deklariere, wird sie ja bei jedem Aufruf neu generiert, was völlig unnötig ist, weil sie ja global ist. Wird die in einem anderen Bereich deklariert und wenn ja, wo?
Goetz Geschrieben 12. September 2019 Geschrieben 12. September 2019 (bearbeitet) vor 47 Minuten schrieb Timba: Wird die in einem anderen Bereich deklariert und wenn ja, wo? Du kannst direkt unter "Ereignisse" ein einzelnes Skript anlegen. Dieses Skript wird einmalig beim Start der Ereignisverwaltung (für gewöhnlich der Anlagenstart) abgearbeitet und nicht, wie anderswo, durch ein von dir bestimmtes Ereignis ausgelöst. Das wäre ein möglicher Platz für eine Tabelle. Dasselbe gilt noch einmal für alle Module in der EV. Jedes Modul kann ebenfalls ein eigenes Basisskript bekommen. Diese Skripte fügst du mit dem + in der oberen linken Ecke zur EV hinzu. Dort, wo du auch die EV Module erzeugst. Bearbeitet 12. September 2019 von Goetz Screenshot eingefügt
Timba Geschrieben 12. September 2019 Autor Geschrieben 12. September 2019 Der Befehl "layout:getVehiclesOnTrack(Schiene)" erzeugt laut Dokumentation eine Liste mit allen Fahrzeugen auf dieser Schiene. Gehe ich recht in der Annahme, dass diese Fahrzeuge als Objekte in der Liste stehen? Wenn ich also eine Objektvariable vom Typ Objekt definiert habe, sollte etwas in dieser Form liste = layout:getVehiclesOnTrack(Schiene) Lokschuppen.FZG = liste[1] zu einem richtigen Ergebnis führen. Oder falsch? (Das Zeug macht süchtig )
Timba Geschrieben 12. September 2019 Autor Geschrieben 12. September 2019 Jepp, funzt. Sorry für die viele Fragerei. Bin gerade total geflasht von den Möglichkeiten, die Lua bietet. Versuche gerade die Steuerung für meinen Lokschuppen umzuschreiben. Ich habe einen Schuppen mit 15 Plätzen und versteckt entsprechend 15 Schalter. Bei Betätigung eines Schalters fährt die entsprechende Lok aus dem Schuppen inkl. Tor auf und zu, Drehscheibe, etc. Mit V4 hatte ich quasi für jeden Schalter eine eigene Reihe Ereiignisse definiert, ging ja nicht viel anders. Jetzt will ich das zusammenfassen, dass das von einer einzigen Routine gesteuert wird, Die Einfahrt in den Lokschuppen habe ich schon fertig. Die Ausfahrt kriege ich auch noch hin.
Timba Geschrieben 12. September 2019 Autor Geschrieben 12. September 2019 Um die Struktur der Scripte mit Ausführungsverzögerung noch besser zu verstehen und zu verinnerlichen habe ich mir ein Blabla-Beispiel generiert und angesehen: Offenbar ist der zweite Parameter der defer-Anweisung eine Art Sprungmarke, die das Programm zu der richtigen deferredCall-Anweisung führt. Wenn man hier bei der zweiten defer-Anweisung einen Fehler macht und die Sprungmarke der ersten Verzögerung, also statt "Verzögerung (2)" nur "Verzögerung" eingibt, dann könnte ich mir vorstellen, dass man sich dabei eine fette Endlosschleife einhandelt, der man nur noch mit Steckerziehen beikommen kann. Ist das so? Hat das schon mal einer ausprobiert?
Andy Geschrieben 12. September 2019 Geschrieben 12. September 2019 Ausprobieren. Wäre es ein Lua-Skript, würde es abgebrochen, wenn es zu lange dauert. Das sollte bei normalen EV-Dingen eigentlich dann auch der Fall sein. Wenn es so ist, würde es im EP in der Tat stoppen. Ohne EP könnte es sein, dass es unauffällig weiterläuft. Wird halt nicht alles ausgeführt. Aber an 'Leer' würde ich den Wert nicht geben, da kannst Du's nicht checken.
Neo Geschrieben 12. September 2019 Geschrieben 12. September 2019 Hallo, vor 2 Stunden schrieb Timba: dann könnte ich mir vorstellen, dass man sich dabei eine fette Endlosschleife einhandelt, der man nur noch mit Steckerziehen beikommen kann. Ist das so? Endlosschleife ja, Steckerziehen nein. Ein defer-Aufruf, der sich immer wieder selber aufruft, ist am Ende ein Timer, der auch endlos läuft. Selbst eine Verzögerung von 0 Sekunden führt dazu, dass das Ereignis erst im nächsten Frame ausgeführt wird. Genug Zeit also, um die Anlage weiter zu bearbeiten. Viele Grüße, Neo
Timba Geschrieben 12. September 2019 Autor Geschrieben 12. September 2019 vor 1 Stunde schrieb Andy: Aber an 'Leer' würde ich den Wert nicht geben Hatte ich nicht vor. Wie gesagt hatte ich mir nur ein Blabla-Ding gebastelt um mir die Struktur bei mehr als einer Verzögerung anzuschauen und da war ich zu faul, alle Angaben auszufüllen. Als Anschauungsmaterial reicht es ja auch ohne Werte, nicht wahr. vor 8 Minuten schrieb Neo: Ein defer-Aufruf, der sich immer wieder selber aufruft, ist am Ende ein Timer, der auch endlos läuft. Selbst eine Verzögerung von 0 Sekunden führt dazu, dass das Ereignis erst im nächsten Frame ausgeführt wird. Genug Zeit also, um die Anlage weiter zu bearbeiten. Ok, sehr beruhigend. Ich hatte früher hin und wieder das Pech, versehentlich eine Endlosschleife zu programmieren und je nachdem gab es manchmal nicht mal die Möglichkeit eines Escapes. Da ging wirklich nur Steckerziehen. Immerhin habe ich mir damals angewöhnt, vor jedem Testlauf abzuspeichern, denn sonst ist alles im Nirwana.
Timba Geschrieben 12. September 2019 Autor Geschrieben 12. September 2019 Mal was zum Lachen: Da werde ich fast verrückt hier weil der Scheißdreck von Lua-Script nicht mehr funktioniert, baue die Befehle um, und nochmal, und nochmal, tobe, schreie, springe herum, schaue schon mal bei Amazon was ein stabiles Hanfseil wohl kostet, und nach einer Dreiviertelstunde, kurz bevor ich meinem kläglichen Dasein ein Ende setzen wollte, fällt mir ein, mal zu prüfen, ob die Simulation auf "Halten" steht, weil Animationen ja im Haltezustand nicht funktionieren. Maaaaaaaaaaaaaann!! Ich glaube, ich mach mal Pause und schütt mir nen Malt ein zum Runterkommen.
Tesla Geschrieben 12. September 2019 Geschrieben 12. September 2019 vor 40 Minuten schrieb Timba: mal zu prüfen, ob die Simulation auf "Halten" steht, Hihi, oder wie es mir passiert ist: ich betätige einen Schalter (bzw will ihn betätigen) und nichts passiert... MBS ist tot will nicht mehr mit mir agieren... nicht einmal die EV geht auf. Bis ich dann nach einiger Zeit (gefühlte 2 Zigaretten lang) feststelle, daß die EV auf dem 2. Monitor verdeckt durch ein anderes Fenster geöffnet war. Mahlzeit!!! Gruß, Michael
Wüstenfuchs Geschrieben 13. September 2019 Geschrieben 13. September 2019 Am 12.9.2019 um 14:01 schrieb m.weber: Bis ich dann nach einiger Zeit (gefühlte 2 Zigaretten lang) feststelle, daß die EV auf dem 2. Monitor verdeckt durch ein anderes Fenster geöffnet war. Mahlzeit!!! Dann bin ich ja nicht der einzigste den das passiert ist. Auch Super ist´s wenn mann eine gefühlte Ewigkeit darauf wartet, dass es auf der Anlage Nacht wird und nichts passiert. Da mann für die Bearbeitung der Anlage die Simulationszeit gestoppt hatte. HG Wüstenfuchs
Empfohlene Beiträge
Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren
Du musst ein Benutzerkonto besitzen, um einen Kommentar verfassen zu können
Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen.
Neues Benutzerkonto erstellenAnmelden
Du hast bereits ein Benutzerkonto? Melde dich hier an.
Jetzt anmelden