Hilfe bei der EV für eine Zuganzeige

[Anlagendesigner]

N'abend, also ich kann definitiv sagen, das es mit dem Export an x liegt.

Wenn ich x mit was anderem manuell befülle, wird dies an die Tabelle angehangen, nur wenn ich deinen Code nutze und x einzig mit der remove-Funktion befülle wird nichts angehängt. Das deutet für mich darauf hin, dass x keinen Inhalt hat - warum auch immer.

Werde Morgen mal schauen ob ich die Anlage exportiert bekomme, dann kannst du selbst reinschauen und nach dem Fehler sehen.

Ich werde Morgen - wenn ich dazu komme - mal das Prozedere mit einer neuen, leeren Anlage nachstellen. Nicht das am Ende nicht nur das Ereignis/Ereignisverwaltung als Unterschied ist. Die Anlage habe ich glaube ich seit V6 immer wieder in die neuen Versionen übertragen und weiterbearbeitet.

Wie kann ich dir die Anlage denn am besten zur Verfügung stellen?

[Goetz]

vor 13 Minuten schrieb Anlagendesigner:

Wie kann ich dir die Anlage denn am besten zur Verfügung stellen?

Du kannst sie

1. im Internet veröffentlichen und hier die Anlagen ID nennen
2. auf deine Festplatte exportieren und die Datei an ein Posting anfügen

Beide Optionen findest du auf der Startseite des 3D-Modellbahn Studios im Kontextmenü zur Anlage.

Viele Grüße
Götz

[EASY]

Hallo,

vor 9 Stunden schrieb Goetz:

table.remove() übergibt das, was in der Zelle stand bevor sie gelöscht wird.
Die Funktion legt den Inhalt lokal in einen Zwischenspeicher, löscht die Zelle und gibt dann den Inhalt des Zwischenspeichers aus.
Dabei ist es Lua ganz egal, welchen Typ dieser Inhalt hatte.

so ganz egal ist es lua nicht.

Ich erzeuge 2 Objekvariablen...

$("Schalter klein").variables["Werte"]={1,2,3,4,5}
$("Schalter klein").variables["Listenwerte"]={{10,11},{12,13},{14,15},{16,17},{18,19}}

"Werte" ist eine Liste mit "einfachen" Einträgen, "Listenwerte" beinhaltet Einträge die wiederum eine Liste sind.

Wenn ich nun in lua folgendes definiere...

local t1=$("Schalter klein").variables["Werte"]
local x1=table.remove(t1, 1)
table.insert(t1, x1)
$("Schalter klein").variables["Werte"]=t1

local t2=$("Schalter klein").variables["Listenwerte"]
local x2=table.remove(t2, 1)
table.insert(t2, x2)
$("Schalter klein").variables["Listenwerte"]=t2

... dann wird zwar "Werte" zyklisch getauscht, bei "Listenwerte" tritt der von @Anlagendesigner beschriebene Effekt auf, daß zwar der erste Eintrag gelöscht wird, aber nichts hinten angefügt, die Liste also immer kürzer wird. (x2 ist in diesem Fall nil).

Wenn ich folgendes definiere...

local t2=$("Schalter klein").variables["Listenwerte"]
local x2=t2[1]
table.insert(t2, x2)
table.remove(t2,1)
$("Schalter klein").variables["Listenwerte"]=t2

dann geht auch das zyklische Tauschen von "Listenwerte".

Gruß
EASY

Bearbeitet 9. Juni von EASY

[Goetz]

Vielen Dank, @EASY!   

[Anlagendesigner]

@EASYDer Unterschied besteht quasi nur darin, das du die erste Zeile erst kopierst und hinten anfügst und dann erst löschst.

Sehe ich das richtig?

[Anlagendesigner]

Muss das Schlüsselwort local beim befüllen von Variablen immer voran gestellt werden?

[Goetz]

vor 13 Minuten schrieb Anlagendesigner:

Muss das Schlüsselwort local beim befüllen von Variablen immer voran gestellt werden?

Nein, das ist nicht zwingend erforderlich.
Aber wenn man in Lua eine Variable nicht explizit als local deklariert, wird sie als globale Variable angelegt.

Deshalb ist es eine gute Praxis den Gültigkeitsbereich von Variablen, die nur innerhalb einer Funktion benötigt werden, auf diese Funktion zu beschränken.

[Eggu]

vor 2 Stunden schrieb EASY:

(x2 ist in diesem Fall nil).

in einem externen Lua Compiler/Interpreter ist x2 nicht nil, da funktioniert der Tausch wie gewünscht,

scheint also an der Lua-Implementierung zu liegen.

[Anlagendesigner]

@EASY @Goetz

Danke für die Hilfe. Mit Easy's letztem Script funktioniert das Neureihen der Tabelle mit Auslösetastern perfekt. Jetzt werde ich es mal in Verbindung mit dem Gleiskontakt und der Aktualisierung der Anzeigetafel probieren.
Damit hat sich der Export wohl auch erledigt - mach ich lieber mal wenn alles in weiter zukunft irgendwann fertig wird. Leider lasse ich mich bei der neuen Studio-Version dazu verleiten die neuen Funktionen einzuarbeiten und baue deshalb oft wieder um.

[EASY]

Hallo,

vor 2 Stunden schrieb Anlagendesigner:

Der Unterschied besteht quasi nur darin, das du die erste Zeile erst kopierst und hinten anfügst und dann erst löschst.

... die Reihenfolge hat sich bei der Eingabe ergeben, war also nicht beabsichtigt. Deine Frage hat mich allerdings neugierig gemacht und ich habe die Reihenfolge umgedreht und nun kommt meine direkte Frage an @Neo... (oder wer mir das erklären kann...)

Wenn ich zuerst einfüge und dann lösche geht es...

local t2=$("Schalter klein").variables["Listenwerte"]
local x2=t2[1]
table.insert(t2, x2)
table.remove(t2,1)
$("Schalter klein").variables["Listenwerte"]=t2

... wenn ich zuerst lösche und dann einfüge geht es nicht...

local t2=$("Schalter klein").variables["Listenwerte"]
local x2=t2[1]
table.remove(t2,1)
table.insert(t2, x2)
$("Schalter klein").variables["Listenwerte"]=t2

... dann ist x2 nach "table.remove(t2,1)" nil und es wird (logischerweise) nichts eingefügt.

Warum verliert die Variable x2 in diesem Fall ihren Wert nach table.remove(t2,1)? (wird mit x2=t2[1] nur so etwas wie eine Referenz gesetzt? )

Gruß
EASY

[Anlagendesigner]

Aus Sicht anderer Programmiersprachen ist es eigentlich logisch. Das remove bedeutet löschen, nicht ausschneiden. Was gelöscht ist kann nirgendwo mehr hingeschrieben/eingefügt werden. Die Variable X2 dürfte also nie einen Wert gehabt haben.
Das ist in jeder mir bekannten Programmiersprache so, deshalb stellte sich mir die Frage ja überhaupt.

Aber da muss sich @Neo zu äußern, wie das im Studio genau umgesetzt ist.

[EASY]

Hallo,

vor 9 Stunden schrieb Anlagendesigner:

Aus Sicht anderer Programmiersprachen ist es eigentlich logisch. Das remove bedeutet löschen, nicht ausschneiden. Was gelöscht ist kann nirgendwo mehr hingeschrieben/eingefügt werden. Die Variable X2 dürfte also nie einen Wert gehabt haben.

ich möchte diesen Thread eigentlich nicht überstrapazieren aber aus meiner Sicht ist das nicht logisch. Die Zuweisung x2=t2[1] erfolgt ja bevor t2[1] gelöscht wird.

Aus meiner Sicht ganz merkwürdig ist folgendes...
mit der Liste...

$("Schalter klein").variables["Werte"]={1,2,3,4,5}

geht folgendes in lua (der Wert von x1 bleibt auch nach table.remove(t1,1) erhalten! und table.insert(t1, x1) funktioniert)

local t1=$("Schalter klein").variables["Werte"]
local x1=t1[1]
table.remove(t1,1)
table.insert(t1, x1)
$("Schalter klein").variables["Werte"]=t1

Mit der Liste...

$("Schalter klein").variables["Listenwerte"]={{10,11},{12,13},{14,15},{16,17},{18,19}}

geht es so in lua nicht (der Wert von x2 bleibt nach table.remove(t2,1) nicht erhalten! und table.insert(t2, x2) funktioniert deshalb nicht)

local t2=$("Schalter klein").variables["Listenwerte"]
local x2=t2[1]
table.remove(t2,1)
table.insert(t2, x2)
$("Schalter klein").variables["Listenwerte"]=t2

deshalb Frage an @Neo... (oder wer mir das erklären kann...)
weshalb werden x1 und x2 unterschiedlich behandelt?

Gruß
EASY

Bearbeitet 9. Juni von EASY

[Neo]

vor 16 Minuten schrieb EASY:

weshalb werden x1 und x2 unterschiedlich behandelt?

Tabellen sind im Gegensatz zu einfachen Datentypen Referenzen auf Objekte. Bei einer Zuweisung wird die Referenz kopiert, nicht die ganze Tabelle. Wird nun mittels "table.remove" eine Tabelle gelöscht, zeigt die Referenz x2 anschließend auf ein nicht mehr vorhandenes Objekt (nil).

Es handelt sich hierbei aber um ein MBS-spezifisches Verhalten, denn die Tabellen, die in Variablen gespeichert werden, sind keine echten Lua-Tabellen. Während echte Lua-Tabellen referenzgezählt werden und solange existieren, bis keine Referenz mehr auf die Tabelle zeigt, sind Tabellen innerhalb von Studio-Variablen ganz normale Objekte, die solange existieren, bis sie jemand löscht (so wie 3D-Modelle z.B.). Diese "Studio-Tabellen" emulieren das Verhalten von Lua-Tabellen (Indexzugriffe, Iteratoren, #-Operator usw.), nicht aber die Referenzzählung, wodurch solche Effekte auftreten können.

Viele Grüße,

Neo

[Anlagendesigner]

So, jetzt bräuchte ich aber noch mal Hilfe zum ursprünglichen Thema.

Ich befülle ja meine Anzeigeelemente aus der Liste die ich als Objektvariable an den Gleiskontakt gehängt habe. Das funktioniert auch so wie es soll, solange ich den Gleiskontakt bzw. die Variable per Objekt fest auswähle (wie hier im Screenshot).

Jetzt möchte ich das Ganze aber gerne generisch bauen um die gesamte Anlage mit einer Funktion bedienen zu können. Darum habe ich ja auch die Objektnamen der Anzeigeelemente ebenfalls als Variable (Typ Objekt) an den Gleiskontakt gehangen. So brauche ich - nach meiner Logik - nur die Variablenwerte des jeweiligen Gleiskontaktes (dieser wird per Schlagwort ausgelöst) zu ändern, nachdem ich ihn an eine andere Haltestelle kopiert habe. Leider funktioniert das Befüllen mit der grafischen EV nicht wie ich es mir gedacht habe (siehe Screenshot). Es wird nichts übertragen.

Ich verweise zuerst auf ein Listenobjekt, dann auf ein inneres Listenobjekt und anschließend uf eine erweiterte Variable um an den Auslöser zu kommen.

Wo ist der Fehler?

 

GEFUNDEN:
Man sollte in den Variablen auch die richtigen Objekte hinteregen.

Bearbeitet 10. Juni von Anlagendesigner

[Anlagendesigner]

Allerdings habe ich direkt das nächste Problem gefunden.

Innerhalb des Scripts wird natürlich auch ein festes objekt/Variable verwiesen.
Kann man in einem Script auf einen generischen Auslöser wie einen Gleiskontakt verlinken?

Also statt:

local t = $("Gleiskontakt Kaserne (Zuganzeige)").variables["Abfahrzeiten"]
local x = t[1]
table.insert(t, x)
table.remove(t,1)
$("Gleiskontakt Kaserne (Zuganzeige)").variables["Abfahrzeiten"] = t

eher so etwas:

local t = $([variabler Gleiskontakt]).variables["Abfahrzeiten"]
local x = t[1]
table.insert(t, x)
table.remove(t,1)
$([variabler Gleiskontakt]).variables["Abfahrzeiten"] = t

Ebenfalls erledigt:

Es muss heißen:

local t = contact.variables["Abfahrzeiten"]
local x = t[1]
table.insert(t, x)
table.remove(t,1)
contact.variables["Abfahrzeiten"] = t

Damit wird die Liste/Tabelle die dem jeweiligen Gleiskontakt zugeordnet ist hochgeschoben und die Anzeige aktualisiert ohne eine andere Zuganzeige zu ändern. Einzige Fehlerquelle ist jetzt noch, dass die EV-Funktion exakt zeitgleich von zwei unterschiedlichen Gleiskontakten ausgelöst wird. Ich denke aber das ist eher zu vernachlässigen da bei den heutigen Rechengeschwindigkeiten höscht unwahrscheinlich.

Bearbeitet 10. Juni von Anlagendesigner

[Goetz]

vor einer Stunde schrieb Anlagendesigner:

exakt zeitgleich ...

gibt es in Lua nicht.
Auch wenn die Ereignisse zur selben Zeit eintreten, werden sie sequentiell in der EV verarbeitet.

Da musst du dir also keine Sorge machen.

[Anlagendesigner]

Na dann perfekt. Wenig Code für eine ganze Anlage.

Jetzt fehlt nur noch das Türen öffnen und schließen, Lichtwechsel etc. beim Halt

Und dann kann ich mir die Bushaltrestelle und die S-Bahn-Halterstelle in der ganzen anlage durchkopieren.