Verschachtelte variablen in V5

[Goetz]

vor 49 Minuten schrieb fzonk:

Benutzerdefinierten Ereignissen bleibt gleich aber die Parameterwerte ändern sich

kopiere dein benutzerdefiniertes Ereignis in den schmalen Bereich zwischen dem schwarzen Trennstrich und dem unteren gelben Balken. Der einfachste Weg ist (meines Erachtens) das Ereignis an den neuen Platz zu ziehen und dabei die Strg-Taste gedrückt zu halten.

Jetzt hast du eine Kopie im Abschnitt "Bedingung nicht erfüllt" und kannst hier die Parameter ändern.

Hilft das oder habe ich deine Frage missverstanden?

[fzonk]

Hallo @Goetz

Dies ist leider nicht die Lösung meines Problems, die Bedingung die du da siehst muss für alle weiteren Aktionen wahr sein. In der Aktion die du da siehst steckt auch noch eine Bedingung (siehe anderes Bild) und diese soll ausschlaggebend sein. Wenn diese wahr ist sind die Aktionen bereits vorhanden, nun möchte ich aber weiter damit arbeiten wenn diese Bedingung falsch wäre. Quasi Bedingung aus Benutzerdefiniertes Ereignis ist falsch.

Gruß Frank

Bearbeitet 18. Juli 2019 von fzonk

[Goetz]

Hallo @fzonk

dann tut es mir leid, dass ich deinem Konzept nicht recht folgen konnte.

[Neo]

Hallo Frank,

du könntest doch z.B. dein benutzerdefiniertes Ereignis immer zweimal aufrufen, einmal mit Parameter-Set 1 und einmal mit Parameter-Set 2, weil wenn ich dich richtig verstanden habe, gibt es nur den Entweder-Oder-Fall. Wobei richtig sauber ist das nicht, weil du dann Annahmen über die internen Abläufe des benutzerdefinierten Ereignisses von Außen machen musst. Eventuell wäre es besser, wenn du dein Konzept etwas anpasst.

Viele Grüße,

Neo

[fzonk]

Hallo @Neo und @Goetz

Ich habe nun das Ereignis wieder etwas aufgeschlüsselt und die Bedingungen und Aktionen getrennt. Vielleicht ist dieses Bild aufschlussreicher was mein Ziel ist.

Aktuell habe ich keine andere Lösung gefunden, schade ist dass ich nicht (nach meinem Wissenstand) die Bedingung und die Aktionen in einem Benutzerdefinierten Ereignis lassen konnte, denn die Inhalte der Bedingung kommen gleichzeitig in einer Aktion vor (Prüfe ob eine bestimmte Objektvariable einen Wert von 0 hat, wenn ja setze bei dieser Variable einen Wert von 1 (hätte man auch mit einer Boolescher Wert umsetzen können) und führe weitere Aktionen aus, wenn die Objektvariable nicht den Wert 0 hat dann prüfe die nächste Objektvariable).

Gruß Frank

 

Bearbeitet 18. Juli 2019 von fzonk

[Goetz]

vor 10 Stunden schrieb fzonk:

schade ist dass ich nicht (nach meinem Wissenstand) die Bedingung und die Aktionen in einem Benutzerdefinierten Ereignis lassen konnte

Doch, das kannst du ganz bestimmt.

Hast du schon entdeckt, dass benutzerdefinierte Ereignisse eigene Variablen bekommen können? Einfach oben auf (keine Parameter) klicken und dann die Parameter-Liste bauen. Anschließend kannst du beim Aufruf des Ereignisses diese selbst definierten Parameter mit Werten befüllen. Und im Ereignis kannst du diese Werte als Bedingung oder anderweitig weiter verarbeiten.

[fzonk]

vor 1 Stunde schrieb Goetz:

Doch, das kannst du ganz bestimmt.

Hast du schon entdeckt, dass benutzerdefinierte Ereignisse eigene Variablen bekommen können? Einfach oben auf (keine Parameter) klicken und dann die Parameter-Liste bauen. Anschließend kannst du beim Aufruf des Ereignisses diese selbst definierten Parameter mit Werten befüllen. Und im Ereignis kannst du diese Werte als Bedingung oder anderweitig weiter verarbeiten.

Hallo Goetz,

mein Ziel (Anliegen) ist wahrscheinlich ohne ein Muster schwer nachzuvollziehen, daher werde ich heute Abend, spätestens morgen ein Muster erstellen. Mit den Variablen als Parameter ist bekannt, auch dass diese in Bedingungen eingearbeitet werden können, hatte ich bereits aber dann bin ich nicht weiter gekommen wenn die Bedingung falsch sind, daher habe ich die Bedingung und die Aktionen wieder getrennt. Wie gesagt ich werde eine Musteranlage erstellen, dann könnt ihr besser nachvollziehen was meine Gedankengänge sind.

bis dahin...

Gruß Frank

[fzonk]

Hallo @Neo, @Goetz und Alle anderen

Ich habe eine kleine Musteranlage gebaut, damit ihr euch direkt ein Bild meiner Gedankengänge / Problem mit Benutzerdefinierten Ereignissen machen könnt.

Eine kleine Erklärung, Ziel ist es dass sich ein Zug beim einfahren in einen Bahnhof selbständig ein freies Gleis sucht und dieses anfährt (der Weichenweg zu diesem Gleis gestellt wird), gleichzeitig soll dieses Gleis für alle weiteren Züge gesperrt werden. Bei diesem Beispiel gibt es nur eine Lok, die stellvertretend für mehrere Züge ist. Zur Simulation ob ein Gleis belegt oder frei ist habe ich die Lampen (können nach Belieben geschalten werden) auf die jeweiligen Gleisabschnitte gesetzt (rot=belegt, grün=frei). Der jeweilige Gleisabschnitt wird bei Zuweisung automatisch als Belegt gesetzt, es erfolgt nach Verlassen des Gleisabschnittes aber in dieser Beispielanlage kein automatische Freigabe, dies muss manuell durch umschalten der entsprechenden Lampe geschehen. In der EV gibt es mehrere Ereignismodule (Ordner). Das Ereignismodul „Sonstige“ sollte außer Acht gelassen werden, in diesem sind nur ein paar Grundlagen für den Ablauf / die Steuerung. Des Weiteren gibt es 3 Varianten Ereignismodule. Aktuell ist Variante1 aktiv und Variante 2 und 3 deaktiviert. Bitte immer nur eine Variante Aktiv setzen und die übrigen beiden Varianten deaktivieren.

Variante1 (funktioniert fehlerfrei)

In dieser habe ich den kompletten Ablauf der Ereignisfolge mit jedem einzelnen Schritt programmiert, bei dieser Variante ist die Grundlogik auch am besten nachvollziehbar. Diese ist:

1.       überprüfe ob Gleis1 frei ist

2.       wenn Gleis1 frei ist, setzte für weitere Züge das Gleis als Besetzt und schalte den Weichenweg zu Gleis1 (Ereignis Ende)

3.       wenn Gleis1 NICHT frei ist überprüfe ob Gleis2 frei ist

4.       wenn Gleis2 frei ist, setzte für weitere Züge das Gleis als Besetzt und schalte den Weichenweg zu Gleis2 (Ereignis Ende)

5.       wenn Gleis2 NICHT frei ist überprüfe ob Gleis3 frei ist

6.       wenn Gleis3 frei ist, setzte für weitere Züge das Gleis als Besetzt und schalte den Weichenweg zu Gleis (Ereignis Ende)

Man könnte noch mehr Bedingungen und Aktionen einbauen, aber für dieses Muster habe ich darauf verzichtet.

Variante2 (funktioniert fehlerfrei)

Da Variante1 sehr aufwendig ist jede Bedingung und Aktion für sich zu erstellen und der Ablauf für jedes Gleis immer wieder der Selbe ist (Blöcke die sich wiederholen) habe ich mir die Parameter herausgesucht die sich von Block zu Block ändern, es sind bei diesem Beispiel nur 3 Parameter (das Gleis was angesteuert werden soll, Stellung der Weiche1 und Stellung der Weiche2). Diese 3 habe ich als Parameter in einem Benutzerdefinierten Ereignis angelegt. Des Weiteren habe ich die Aktionen eines Blockes angelegt.

Als zweites Ereignis habe ich nun nur noch die jeweilige Bedingung und dann das jeweilige Benutzerdefinierte Ereignis nach demselben Schema wie in Variante1 zusammengestellt, diese Variante ist um einiges schneller (auf Masse gesehen) zu erstellen, da nur noch die sich ändernden Parameter eintragen muss.

Variante3 (funktioniert nur für ein Gleis)

Nun gibt es bei den Benutzerdefinierten Ereignissen nicht nur die Möglichkeit Aktionen zu hinterlegen sondern auch Bedingungen.

Die Bedingungen die verwendet wurden enthalten keine anderen Parameter als auch die Aktionen aus Variante2. Daher habe ich nun die Bedingung mit in das Benutzerdefinierte Ereignis gepackt.

In einem weiteren Ereignis (wie auch in Variante2) habe ich nun die Benutzerdefinierte Aktion mit den jeweiligen Parametern angelegt. Die Bedingung, so wie die Aktionen, wird von der EV ordnungsgemäß abgearbeitet, ABER an der Stelle komm ich nicht weiter. Da die Bedingung ja nun in einem Ereignis mit eingebaut habe ich nicht die Möglichkeit weiter zu arbeiten wenn die integrierte Bedingung nicht erfüllt ist ODER DOCH???

So nun habe ich ganz viel Text geschrieben, ich hoffe ihr konntet dem ganzen Folgen. Für alle anderen ist es vielleicht eine Anregung wie sie eine Steuerung erstellen können unter V5.

Gruß Frank

Benutzerdefinierte Aktion.mbp

[Goetz]

vor 49 Minuten schrieb fzonk:

Da die Bedingung ja nun in einem Ereignis mit eingebaut habe ich nicht die Möglichkeit weiter zu arbeiten wenn die integrierte Bedingung nicht erfüllt ist

Okay, an der Stelle verstehe ich dein Problem.

Eigentlich müsstest du bei der Variante 3 eine Liste der zu prüfenden Gleise mitgeben. Und das geht derzeit nur, wenn man von der grafischen Repräsentation auf die direkte Darstellung des Lua Skripts umschaltet.

Also musst du es etwas anders angehen, damit auch die grafische Variante funktioniert:

Gib nur die drei zu prüfenden Ziele als drei Parameter mit. Mehr nicht. Und hinterlege den Weg zu den Zielen (spricht: die Weichenstellungen) in den Zielobjekten (nach Geschmack die Gleise, Ausfahrsignale, roten Knöpfe etc.) . Jetzt kannst du in der benutzerdefinierten Aktion erstens nacheinander prüfen, ob ein Ziel frei ist. Und wenn es frei ist, dann pickst du dir aus diesem Ziel die Weichenstellungen (Die du passend benannten Variablen hinterlegt hast. Darüber hinaus musst du für das Ziel 1 gar keine Weichenstellung für Weiche 2 hinterlegen (weil die nicht relevant ist.) Stattdessen prüfst du im benutzerdefinierten Ereignis für jede Weiche, ob überhaupt ein Wert vorliegt und schaltest sie nur dann um, wenn das der Fall ist.

Wenn ich die Zeit gleich noch finde, dann bau ich dir das mal.

[Goetz]

@fzonk

Schau mal bitte, ob dir diese groben Beispiele weiterhelfen:

benutzerdefinierte Aktion - drei Alternativen.mbp

Bearbeitet 19. Juli 2019 von Goetz

[Neo]

Hallo Frank,

danke für das anschauliche Beispiel.

vor 1 Stunde schrieb Goetz:

Gib nur die drei zu prüfenden Ziele als drei Parameter mit. Mehr nicht.

Ich hätte noch eine andere Idee. Bau dir eine verkettete Liste, indem du abstrakt gesehen Gleis 1 mit Gleis 2 verbindest (in einer Objektvariable), Gleis 2 mit Gleis 3, Gleis 3 mit Gleis 4 usw. Anschließend rufst du dein benutzerdefiniertes Ereignis für Gleis 1 auf. Ist es belegt, rufst du rekursiv erneut dein benutzerdefiniertes Ereignis auf, diesmal aber mit dem "Nachbargleis", also der Verknüpfung, die du in einer Objektvariable gespeichert hast. Somit ruft sich dein benutzerdefiniertes Ereignis selber solange auf, bis ein freies Gleis gefunden wurde oder kein Nachbargleis mehr existiert. Klassische rekursive Verarbeitung einer verketteten Liste. Vorteil dieser Methode ist, dass sie für beliebige Gleise funktioniert (im Studio bis maximal 25 Gleise, weil dann ein Skript wegen zu vielen Rekursionen abgebrochen wird) und du in der EV nicht die Anzahl der Gleise kennen musst (die EV funktioniert dann also für jeden Bahnhof).

Viele Grüße,

Neo

[fzonk]

Hallo @Goetz

Vielen Dank für deine Beispiele, alle 3 weiteren Varianten funktionieren super. Variante4 unterscheidet sich ja nur minimal von Variante1, daher ergibt sich bei größeren Anlagen ja auch weiterhin ein großer Aufwand um die Ereignisse zu erstellen. So wie ich es verstanden habe ist Variante5 vom Inhalt identisch mit Variante4, mit dem unterschied dass die Abfolge mit LUA geschrieben ist. Da muss ich ehrlich zugeben dass ich mich an LUA noch nicht heran getraue, ich habe seit 25 Jahren nicht mehr mit Programmiersprachen gearbeitet und mein Wissen von damals tendiert Richtung Null, ich müsste mich erst einmal wieder intensiv damit beschäftigen und da fehlt mir noch die Lust zu. Variante6 sieht in Skript natürlich sehr kompakt und übersichtlich aus, an der Stelle wird dann doch schon etwas mehr mein Interesse geweckt sich mit LUA zu beschäftigen.

vor 8 Stunden schrieb Neo:

Ich hätte noch eine andere Idee. Bau dir eine verkettete Liste, indem du abstrakt gesehen Gleis 1 mit Gleis 2 verbindest (in einer Objektvariable), Gleis 2 mit Gleis 3, Gleis 3 mit Gleis 4 usw. Anschließend rufst du dein benutzerdefiniertes Ereignis für Gleis 1 auf. Ist es belegt, rufst du rekursiv erneut dein benutzerdefiniertes Ereignis auf, diesmal aber mit dem "Nachbargleis", also der Verknüpfung, die du in einer Objektvariable gespeichert hast. Somit ruft sich dein benutzerdefiniertes Ereignis selber solange auf, bis ein freies Gleis gefunden wurde oder kein Nachbargleis mehr existiert. Klassische rekursive Verarbeitung einer verketteten Liste. Vorteil dieser Methode ist, dass sie für beliebige Gleise funktioniert (im Studio bis maximal 25 Gleise, weil dann ein Skript wegen zu vielen Rekursionen abgebrochen wird) und du in der EV nicht die Anzahl der Gleise kennen musst (die EV funktioniert dann also für jeden Bahnhof).

Finde ich eine gute Idee, ich hatte unter V4 schon einmal eine solche, jedoch war mit der damaligen EV dies nicht umsetzbar. Ich werde den Vorschlag mal aufgreifen, mal sehen wie weit ich komme und ob ich es zum Laufen bekomme (ohne LUA)…

Gruß Frank

[Goetz]

Hallo @fzonk

vor 20 Minuten schrieb fzonk:

alle 3 weiteren Varianten funktionieren super.

Ich weiß. Ich habe sie ja alle drei getestet (und laaange gebraucht, bis ich alle Fehler rausgebügelt hatte)
Viel interessanter ist daher, ob du die Varianten durchschaust.

 

vor 20 Minuten schrieb fzonk:

ich habe seit 25 Jahren nicht mehr mit Programmiersprachen gearbeitet

Das stimmt nicht ganz. Denn die EV ist auch eine Programmiersprache. Nicht erst in V5, sondern auch in den Vorgängerversionen. Du bist also geübt in der Anwendung. Ob die einzelnen Befehle dabei direkt als text untereinander stehen oder in kleinen, farbigen Feldern, macht keinen sooo großen Unterschied.

Die Version 5 bekommst du, wenn du bei Version 4 auf das <> Symbol klickst. Das ist die automatische Übersetzung in Lua (bitte, schreib das nicht in Großbuchstaben. Das sieht immer so laut aus und ist obendrein auch von den Entwicklern dieser Sprache nicht gewünscht.) Diese automatischen Übersetzungen helfen anfangs enorm dabei, die richtigen Schreibweisen von z.B. Objektnamen zu lernen.

 

vor 20 Minuten schrieb fzonk:

Variante 6 ... an der Stelle wird dann doch schon etwas mehr mein Interesse geweckt

Genau das wollte ich damit bezwecken. Deshalb habe ich dir alle drei Versionen zum Vergleich angeboten.

Viel Spaß bei deinen weiteren Experimenten
Götz

Bearbeitet 20. Juli 2019 von Goetz
Schreibfehler ausgebessert

[Andy]

Im manuellen Modus läuft mein Pfadsucher schon wieder wunderbar und richtig schnell! Überhaupt kein Vergleich zu V4. Habe ihn allerdings direkt auf Lua umgesetzt.
Trotzdem werde ich das Kapitel mit den benutzerdefinierten Aktionen noch nachlernen. Die interessieren mich schon.

vor 8 Minuten schrieb Goetz:

Diese automatischen Übersetzungen helfen anfangs enorm dabei, die richtigen Schreibweisen von z.B. Objektnamen zu lernen.

Und wie!

Man kann da auch noch mit einem Texteditor nachoptimieren:

layout:getEntityByName("Mein Objekt")

kann immer zu

$("Mein Objekt")

optimiert werden. Geht aber wirklich nur, wenn da nicht mehr als der Objektname drinsteht.
Allerdings gibt's kein Zurück mehr. Einmal Lua, immer Lua. Alles andere wäre auch zuviel verlangt.

Gruß
  Andy

[fzonk]

Hallo @Goetz

vor 20 Minuten schrieb Goetz:

Ich habe sie ja alle drei getestet (und laaange gebraucht, bis ich alle Fehler rausgebügelt hatte)

Dies kenn ich nur zu gut

vor 20 Minuten schrieb Goetz:

Viel interessanter ist daher, ob du die Varianten durchschaust.

In Teilen ja, aber wie gesagt, Skriptsprache ist nicht meine Stärke

vor 20 Minuten schrieb Goetz:

Die Version 5 bekommst du, wenn du bei Version 4 auf das <> Symbol klickst.

Ist bekannt und ohne es zu Testen habe ich mir es gedacht

vor 20 Minuten schrieb Goetz:

Diese automatischen Übersetzungen helfen anfangs enorm dabei, die richtigen Schreibweisen von z.B. Objektnamen zu lernen.

Und genau die richtige Schreibweise ist mein Handicap, ich habe zu viel Respekt davor dass ich ein Zeichen vergesse und dann den Fehler nicht finde

vor 21 Minuten schrieb Goetz:

Das stimmt nicht ganz. Denn die EV ist auch eine Programmiersprache. Nicht erst in V5, sondern auch in den Vorgängerversionen. Du bist also geübt in der Anwendung. Ob die einzelnen Befehle dabei direkt als text untereinander stehen oder in kleinen, farbigen Feldern, macht keinen sooo großen Unterschied.

Daher sind mir die (jetzt) bunten Felder lieber, da beschränken sich die Fehler „nur“ in der Zuweisung

vor 21 Minuten schrieb Goetz:

Genau das wollte ich damit bezwecken. Deshalb habe ich dir alle drei Versionen zum Vergleich angeboten.

Hast du auf jeden Fall

Gruß Frank

[fzonk]

Hallo @Neo @Goetz und allen Interessierten,

Und da ist auch schon die erste Umsetzung mit Objektvariablen (Variante7), erst einmal in „kleiner“ Form. Ich habe auf die Vorarbeit von Goetz zurückgegriffen und die von ihm angelegten Objektvariablen weiter genutzt und noch etwas erweitert, von den Benutzerdefinierten Ereignis habe ich mich vorübergehend verabschiedet. Der „Steuerungsblock“ im Ereignis „Objekt-Variable wird gesetzt“ stammt mehr oder weniger immer noch aus Variante1, nur dass nun die Objektziele und Objektwerte aus dem jeweiligen Objekt genutzt werden. Der nächste Schritt wird sein diese Steuerung allgemeingültig zu schreiben, so dass man sie mehrfach auf einer Anlage nutzen kann und jeweils „nur“ die Objektvariablen hinterlegen muss…

Gruß Frank

P.S.: Die Ereignisse aus Variante3 habe ich gelöscht, da diese nicht Zielführend waren.

Benutzerdefinierte Aktion oder Steuerung über Objektvariablen.mbp

[Goetz]

Hallo @fzonk

Ich habe @Neos Vorschlag aufgegriffen und einen rekursiven Weg probiert.

Das macht wirklich 'nen schlanken Fuß.

In dieser Version der Testanlage habe ich alle alten Funktionen (auch die sonstigen) gelöscht und neu gebaut. Außerdem enthält sie nur die Variablen, die für diese variante benötigt werden. Ich denke, so wird es leichter sein, die Zusammenhänge alle nachzuvollziehen.

Viel Spaß damit
Götz

P.S.: Deine Version schaue ich mir gleich an und schreibe dir dann noch ein oder zwei Dinge dazu.

benutzerdefinierte Aktion - rekursiv.mbp

[Goetz]

Hallo @fzonk,

wenn ich darf, dann würde ich gerne zwei kleine Anregungen zu deiner EV beisteuern.

Wenn sich die Besetzt-Variable ändert, dann reagierst du darauf und schaltest die Signallampen entsprechend um. Für diesen Zweck machst du zwei Prüfungen:

Erst prüfst du, ob die Variable auf "True" gesetzt wurde. Und schaltest in dem Fall die Lampe auf Rot.
Und dann prüfst du erneut, ob die Variable auf "False" gesetzt wurde (um in diesem Fall die Lampe auf Grün zu setzen)

Die zweite Prüfung ist eigentlich redundant, denn wenn das Ergebnis der ersten Prüfung ergab, dass die Bedingung nicht erfüllt war, dann kann die Variable nur noch "False" sein. Für diesen Fall (Bedingung nicht erfüllt) gibt es im gelben Prüfungsblock ein zweites Fach. Das ist zwischen der schwarzen Trennlinie und dem unteren gelben Balken.

Dort kannst du die alternative Aktion "Lampe auf Grün setzen" hineinlegen:

Das kann die EV schneller verarbeiten und lesbarer ist es auch.

Der gleiche Trick funktioniert auch für den umgekehrten Fall "Lampe wurde umgeschaltet, Variable muss gesetzt werden"

 

Viele Grüße
Götz

Bearbeitet 20. Juli 2019 von Goetz
Schreibfehler ausgebessert

[fzonk]

Hallo @Goetz

Das schlimme ist, mir ist dies wohl bekannt, aber da ich alle Ereignisse in dem Ordner Sonstiges „nur auf die Schnell“ zusammengewürfelt habe war ich mal wieder Blind und habe an die einfachsten Sachen nicht gedacht. An und für sich würden die Lampen bei einer Anlage gar nicht zum Einsatz kommen, aber hier im Beispiel sollen sie halt mehrere Züge simulieren (die Gleise besetzen oder wieder freigeben), man hätte sie auch hier schon weglassen können, aber dann wäre zum einen eine schlechtere Übersicht und zum Anderen müsste ich jedes Mal die Objektvariablen öffnen um diese umzuschalten. Und nun schau ich mir erst mal in Ruhe seine Steuerung an.

Gruß Frank

P.S.: ich habe inzwischen auch Variante7 allgemeingültig umgeschrieben zu Variante8, so könnte man die Ereignisse mehrfach nutzen auf einer Anlage und nein dies mit den Lampen habe ich noch nicht umgeschrieben…

Benutzerdefinierte Aktion oder Steuerung über Objektvariablen2.mbp

[Goetz]

Gerade eben schrieb fzonk:

mir ist dies wohl bekannt

Das ahnte ich, weil du es an anderen Stellen nutzt.
Ich hatte mich entschlossen es trotzdem zu schreiben, weil es dann vielleicht ein oder zwei stillen Mitlesern zu einem besseren Verständnis hilft.

[fzonk]

Hallo @Goetz

Ich habe mir deine Steuerung mal etwas genauer angeschaut, an und für sich funktional, aber ich sehe ein paar Probleme. Du hast die Steuerung insoweit verändert dass das Gleis erst als besetz gemeldet wird wenn der Zug bereits auf diesem steht. Für diese Beispielanlage völlig in Ordnung ABER dies würde bei einer Anlage wo die Züge von beiden Seiten in den Bahnhof einfahren wohl früher oder später zu einem Unfall führen. Daher habe ich immer in dem Moment wo ein Gleis zugewiesen wird dieses sofort als besetzt melden lassen. Ich habe bereits einige Anlagen unter MBS V4 erstellt wo die Steuerung vollautomatisch und zufällig geschieht. Daher kenne ich die Probleme, denn es kann durchaus sein das 2 oder mehr Züge von verschieden Seiten einen Bahnhof ansteuern. Wenn es dich oder jemand anderen interessiert kann ich gern die entsprechenden Content IDs hier einstellen. Ich bin gerade dabei einer dieser Anlagen mit einer vollkommen neuen EV auszustatten, da MBS V5 ganz andere Möglichkeiten bereit hält und damit ich auch gleichzeitig die Neuerungen kennenlerne.

Gruß Frank

 

[Neo]

Hallo Frank,

hast du dich bewusst für "Eine beliebige Objekt-Variable wird gesetzt" entschieden, um die Rekursion zu starten? Das wirkt auf mich etwas umständlich, auch weil es Zwischenvariablen erfordert. Das gleiche Verhalten erreichst du ja auch mit den benutzerdefinierten Ereignissen, nur dass die Parameter dort nicht irgendwo zwischengespeichert werden müssen, sondern als "Stack" automatisch vom Studio verwaltet werden.

Viele Grüße,

Neo

[Goetz]

vor 9 Minuten schrieb fzonk:

Du hast die Steuerung insoweit verändert dass das Gleis erst als besetz gemeldet wird wenn der Zug bereits auf diesem steht.

Das wäre im Ernstfall wirklich fatal. Das Gleis muss als "besetzt" gelten, sobald es einem einfahrenden Zug zugewiesen wurde. Keine Frage!

Aber der Zweck der Übung war doch eine kompakte Routine für die "Besetzt"-Prüfung.

Das drumherum hatte ich deshalb bewusst einfach gehalten, weil es dafür irrelevant war.

[metallix]

Hi all

Hier noch ein kleiner, abba nicht unerheblicher, nachtrag zu meinem urspruenglichem problem das ja zur creation dieses threads fuehrte:

In der unter diesem beitrag angebotenen testanlage funktioniert sowohl der wechsel der ziehenden lok als auch einfach die umkehrung einer einzelnen einfahrenden lok in eine ausfahrende......allerdings nur so lange die in der anlage vorhandenen rollmaterialien entsprechend auf dem gleis zusammen gestellt sind.

Bei der implementierung in meine vorhandene anlage ist mir ein entscheidender unterschied zwischen V5 und den vorgaengerversionen deutlich worden: Bedingt durch die konventionen in Lua, welches nun als scriptsprache in V5 agiert, ist es zwingend notwendig bei einer auswahlsituation wie in der testanlage auch eine, in einer bedingung abgefragte, antwort mit (falschem) inhalt fuer die "bedingung ist nicht erfuellt" option anzubieten. Andernfalls gibt es die attempt to index a nil value meldung und die anlage pausiert.

Nimmt man auf der testanlage einen schienenbus heraus funktioniert auch der einzllok betrieb ohne probleme da der verbliebene schienenbus ja immer noch die objektvariable mit der angabe einer alternative hat. Wird diese abgefragt und dabei erkannt das die alternative nicht auf dem gleis steht, faehrt der schienenbus eben mit umgekehrter geschwindigkeit aus. (sind beide schienenbusse am werk zieht der vorher gezogene den zug aus). Holt man sich nun eine andere lok auf die anlage und laesst sie den zug einfahren kommt die fehlermeldung bei dem versuch wieder auszufahren.

Konnte man vor V5 die tatsaechlichen wechsel-loks mit einer entsprechenden objektvariablen markiert auslesen und von allen anderen loks, ohne diese objektvariable, wirksam unterscheiden muss nun in V5 jede lok (welche je in diese situation auf der anlage einbezogen sein kann) mit dieser objektvaraiblen bestueckt sein. Um den zustand "bedingung nicht erfuellt" (false) zu erreichen genuegt es irgendein objekt (welches niemals mit der betreffenden lok gemeinsam auf dem gleis stehen wird, z.b. ein baum) einzutragen. Wird die objektvariable zwar erstellt abba kein eintrag gemacht tritt auch wieder der attempt to index a nil value fehler ein.

Cheers

Tom

 

Bearbeitet 30. Juli 2019 von metallix
c

[fzonk]

Hallo Tom,

du kannst den Fehler „attempt to index a nil value“  vermeiden, indem du eine Bedingung vor die Aktionen setzt. Diese muss in etwa lauten „Variable hat Wert“, die zu überprüfende Variable ungleich „Objektname“ und das Textfeld leer lassen, damit werden alle Objekte(Variablen) ausgeschlossen die die Variable nicht haben. Ich kann es gerade nicht besser wiedergeben da ich unterwegs bin, ein Beispiel kann ich dir später aber gern nachreichen.

Gruß Frank