Goetz

Jetzt versteht ihr vielleicht besser, warum ich (in meinem Lua Beispiel!) zuerst eine Liste aller belegten Plätze anlege und dann zielsicher und mit nur einem Versuch einen zufälligen Platz aus dieser zweiten Liste greife?

I'm glad it worked

Aber theoretisch könnte auch bei einhundert und mehr Würfen der einzig besetzte Platz nicht dabei sein. Der Zufall ist nicht gerecht. Und er hat kein Gedächtnis. Praktisch kann man diesen Ausnahmefall dennoch vernachlässigen.

fast ... Die Elemente einer Liste sind durchnummeriert. Diese Platznummern heißen Index Du kannst ein einzelnes Element aus einer Liste entnehmen, indem du den Namen der Liste und den Index angibst. Ich verwende deine Variable, welche die gewürfelte Zahl enthält, für den Index. Und das zweimal: Einmal hole ich mir das Signal aus einer Liste und danach dann die zugehörige Fahrstraße aus einer zweiten Liste Damit das so funktioniert, müssen die beiden Listen zusammenpassen. Will heißen: Signal und zugehörige Fahrstraße müssen in den Listen denselben Index haben.

Hallo @Roter Brummer, die Idee, bei nicht besetztem Gleis neu zu würfeln, ist clever! Das war der Trick, der mir nicht einfallen wollte. Wenn du jetzt die Signale und Fahrstraßen in Listen parat hältst, kannst du die gewürfelte Zahl als Listenindex verwenden: Zufällige Zugwahl mit Listen.mbp

Eins spielt hier ins andere, weil durch die deferred calls diese Funktionen noch häufiger neu angelegt werden. Mehrfach nach jedem Betreten eines Kontakts. Und die Rechnerlast ist dabei das geringste Problem. Okay, dann lass ich dich erst einmal machen. Ich dachte nur, dass du Reaktionen lesen willst, wenn du dein Konzept in der jetzigen Form vorstellst?

Yes. It's not a "shunt" signal. It's a "Sperrsignal". A blocking signal. An absolute "you shall not pass!". The aspect name "Sh" stands for "Schutzhalt" and may be loosely translated to "safety halt". It is in no way related to "shunt". For route clearance, the main semaphore is pulled first, alerting the driver to the fact that the entire route is now clear and secured. The Sh signal is pulled second, signalling that passing this signal is no longer prohibited.

unabhängig von irgendwelchen Vergleichen: Wenn ein beliebiger Kontakt betreten wird, legst du alle Variablen und Funktionen neu an. Wenn dasselbe Ereignis durch den deferred call ein weiteres Mal aufgerufen wird, legst du wieder alle Variablen und Funktionen neu an. Egal, wie du das auch rechtfertigst, es ist kein guter Ansatz. äh, neee - wenn du das in anderen Sprachen so anlegst, kommt genau dasselbe dabei raus. Das, was ich bemängle, hat nichts mit Lua zu tun.

Wenn du bitte mal meine Erklärung dazu aufmerksam lesen würdest, könntest du sicher verstehen, was ich dir mitteilen wollte. Es geht um das, was nach Ablauf der Verzögerung passiert. Unter deiner ID finde ich jetzt das Diorama mit funktionierendem Ablauf. (Eventuell wird die alte Anlage beim Überschreiben nicht sofort auf dem Server ausgetauscht?) Aber trotzdem finde ich den Weg, den du beschreitest, ... unprofessionell. Du gibst dich als versierten Programmierer aus. Da muss dir doch klar sein, dass man Funktionen nur einmal deklariert und nicht immer wieder? Ganz unabhängig von der verwendeten Sprache.

Ich denke, nein. Zumindest habe ich keinen zufriedenstellenden Weg gefunden. Deshalb meine Anmerkung, dass solche Situationen sich mit Lua besser handhaben lassen.

Du hast es in eine Funktion eingebettet. Und ich hatte dir schon an anderer Stelle erklärt, warum das so nicht geht.

Okay, ich schaue nach ... ich bekomme unverändert dasselbe, fehlerhafte Diorama unter der ID 18CAA89C-FF0C-42AF-9AD7-E6DC73D82AE5

Das Video zeigt nicht das Diorama, welches ich mit deiner ID 18CAA89C-FF0C-42AF-9AD7-E6DC73D82AE5 bekomme.

frisch mit deiner ID geladen. Aber es macht einen Unterschied, ob du das Protokollfenster geöffnet hast oder nicht. Wenn es geöffnet ist, pausiert die Anlage bei der ersten Fehlermeldung. Ohne offenes Protokollfenster macht sie einfach weiter.

und auch nicht fehlerfrei. Wenn der Radlader den Sandhaufen erreicht hat, bricht das Skript mit einer Fehlermeldung ab: Du legst alle Funktionen, Variablen etc. immer wieder neu an. Und verwendest den deferred call unverändert falsch. Zuvor noch nicht, weil ihm ein anderer Fehler (das - im String Pattern) zuvor kam. Aber jetzt wird es zum Problem.

Hello Herman, The combination is used, when journeys and shunting operations both start from this location. The winged signal gives clearance for the route to the next destination. The black signal in front gives clearance for a shunting operation. The black signal is the stronger one of the two. Which is why it must be switched to "go" (= Sh1) in both cases, whereas the winged signal only switches to "go" (Hp1 or Hp2) when an entire route is clear and protected. The end of the range for shunting operations is often marked by a sign with the name Ra10, looking like this: The shunting range must end before the entry signal for oncoming traffic, for obvious reasons. Modern signals combine all aspects in one signal. Here is a main signal displaying "Sh1" for a shunting operation: note the similarity of the diagonal line, which the two white dots form, with the diagonal black bar from the old semaphore signalling the same aspect. Kind regards Goetz

Deine Situation ist einer der Fälle, die sich mit Lua wirklich besser handhaben lassen. Deshalb würde ich gerne noch ein weiteres Skript beisteuern. Meines Erachtens ist es klüger, zuerst aus der Liste aller Signale eine zweite Liste zu generieren, die nur die besetzten Plätze enthält. Und dann geht man im nächsten Schritt hin und greift sich aus dieser neuen Liste zufällig ein Signal heraus. Damit ist sicher gestellt, dass immer ein wartender Zug gefunden wird. local WarteListe = {} local SignalListe = {$("Sig 01"), $("Sig 02"), $("Sig 03"), $("Sig 04"), $("Sig 05")} for i, Signal in ipairs(SignalListe) do if #layout:getVehiclesOn(Signal) > 0 then table.insert(WarteListe, Signal) end end local Anzahl = #WarteListe if Anzahl > 0 then local Zufall = math.random(1, Anzahl) local Signal = WarteListe[Zufall] Signal.state = 1 end Ich habe das Skript ausführlicher als üblich (= mit mehr Zwischenschritten) geschrieben weil ich hoffe, dass so deutlicher wird was an jeder Stelle passiert und wofür es benötigt wird. Viele Grüße Götz

Hallo Gmd, unter anderem baust du jedes Mal, wenn du einen beliebigen Kontakt betrittst, die folgenden Funktionen alle neu (und immer wieder identisch): function playFrontAnimation () function getKontaktPrefix (contact) function setSpeed(vehicle, speed) function processFrontKontakt () function processSideKontakt () function processRearKontakt () function processWaitKontakt () Ich sehe darin keinen Sinn. Und ich bezweifle auch, dass die deferred calls so, wie du sie eingebaut hast, funktionieren können. Ein deferred call ruft nach meinem Verständnis das Ereignis erneut auf und nicht die Lua Funktion innerhalb deines Ereignisses (die du obendrein bei jedem Aufruf neu anlegst). Viele Grüße Götz

Hallo @edgarfauth, Die von @streit_ross genannten Hilfsmittel sind die Ursache. Und eine Neuinstallation der Software hätte diesen Fehler nicht behoben. Danke, dass du zuvor einen Blick auf die Anlage gewährt hast. Viele Grüße Götz

das ist dein Beispiel mit fertig eingerichteten Fahrstraßen: Pendelstrecke mit FS.mbp

Es wäre schlau, wenn du uns vorher einen Blick auf die Anlage werfen ließest. Dann können wir die Ursache eventuell einkreisen. Neuinstallationen sind ein Holzhammer, der keinerlei Erkenntnisgewinn zulässt.

oh sorry, das hatte ich falsch gelesen.

Wenn du ein Fahrzeug mit Geschwindigkeit 0 ins Portal geschickt hast - z.B. mit dem Knopf im Fahrmenü des Fahrzeugs oder mit einem Befehl in der EV - dann kommt es auch mit Geschwindigkeit 0 wieder raus. Du kannst aber auf das Ereignis "Fahrzeug verlässt Depot" reagieren und dem Auslöser "Fahrzeug" eine Geschwindigkeit zuweisen. Am besten eignet sich hierfür die Ist-Geschwindigkeit.

Alles klar. Danke für die Erklärung Aber es hat mir geholfen, manches besser zu verstehen. Danke Gmd