Goetz

Namen spielen überhaupt keine Rolle wenn du (in Variablen, Listen etc.) Objekte speicherst. Ein Objekt wird dir zwar (zur Identifizierung) mit seinem Namen angezeigt. Aber gespeichert wird die Objekt-ID. Du erkennst es daran, dass sich Namensänderungen am Objekt selber sofort auch in deiner EV widerspiegeln. Die Objekt-ID wird dir nicht angezeigt. Aber das Objekt wird auf der Anlage durch Rahmen und Gismo hervorgehoben. Die Schreibweise mit dem $-Zeichen vorweg ist die Objektreferenz in Lua Schreibweise. Lua selbst kennt diese Schreibweise natürlich nicht. Aber Lua ist nur der Übermittler. Und wenn du nur das $-Zeichen schreibst und dann ein Objekt aus der Liste auswählst, dann steht (versteckt) im Code auch die richtige ID zum Objekt. Für wiederholte Aktionen gibt es den Timer. Der Ablauf eines Timers wird als Ereignis gewertet. Und ein Timer kann sich selbst neu starten. Das entspricht in etwa der EEPMain(), ist aber vielseitiger. Erstens bestimmst du selbst den Takt. Zweitens kannst du mehrere Timer parallel betreiben. Drittens kann jeder dieser Timer individuell gestartet und gestoppt werden. Und viertens kann man einen gestoppten Timer zu einem späteren Zeitpunkt wieder starten. Ein Beispiel findest du in meiner Anlage BremsProbe 02. Da frage ich mittels Timer im Abstand von 2 Sekunden nach, ob der Zug schon steht. Wenn die Bedingung erfüllt ist, dann gebe ich die Position der Lok aus und halte den Timer an. Und die Anlage enthält noch weitere nützliche Tricks, wie die Übertragung von Texten an Beschriftungsfelder. Ein Gleis ist eine Weiche, wenn die Eigenschaft "Weichenstellung" existiert. Die Existenz einer Variable oder Eigenschaft kannst du als Bedingung angeben. Weichen sperren kannst du nicht. Aber du kannst das Aufschneiden verhindern. Und auf ein Umstellen der Weiche kannst du reagieren (und z.B. die Weiche bei Nichterfüllung deiner Bedingungen wieder zurück schalten.)

Hier ist eine kleine Beispielanlage zum Thema: Besetzt Abfrage Demo.mbp Die eigentliche Besetzt-Prüfung findet in einem benutzerdefinierten Ereignis statt. Das ist ein Ereignis, welches durch eine Aktion in der EV ausgelöst wird und nicht durch ein Ereignis auf der Anlage. Der Vorteil besteht darin, dass drei verschiedene Ereignisse auf der Anlage dieselbe Aktion starten können. In meinem Fall sind das ein Klick auf den roten Knopf das Betreten eines bunten Gleises das Verlassen eines bunten Gleises

Dazu sind vielleicht folgende Hinweise nützlich: Du kannst in Objekten auch Listen und Tabellen speichern, nicht nur Variablen. Wenn du mehrere Modelle markiert hast, dann kannst du diese Auswahl klassisch mit Strg-C kopieren und beim Erstellen einer Liste unter "bearbeiten" mit einem Klick auf das Insert Icon oder mit Strg-V einfügen. Mit einem Doppelklick auf ein Gleis bekommst du automatisch alle angeschlossenen Gleise bis zu den nächsten Knotenpunkten (Weichen, Endgleise) als eine Gruppenauswahl. In Summe heißt das: Doppelklick aufs Gleis, Strg-C und dann als Liste an relevanter Stelle einfügen, damit du im Bedarfsfall flott in einer Wiederholung alle Gleise auf "besetzt" prüfen kannst.

Sehr schön finde ich, dass du die Verzögerung anpasst, falls bei der gegebenen Verzögerung der Bremsweg nicht ausreichen würde.

@Henry Das liegt an den ganzen übrigen Ereignissen in Thomas Anlage. Die musst du bitte alle deaktivieren, mit Ausnahme des neuen Zug abbremsen2

Funktioniert prima. Und Relikte vom Original zeigen wirklich plakativ, wie viel eleganter man solche Aufgaben jetzt angehen kann.

kannst du auch. Nämlich so, wie ich in meinem Beispiel die Position auslese, an welcher der Zug zum Stehen kam. Mit $(Object).transformation.position.x etc. Für deine print() Ausgaben hast du das "Ereignisprotokoll". Dafür ist das Icon rechts neben dem für die EV. Das Protokoll kann auch Objekt- und Modul-Variablen, Timer etc. anzeigen. Für den Faktor 2 beim Bremsweg habe ich auch (noch) keine geometrische Erklärung. Vielleicht steckt irgendwo in den Zusammenhängen ein a² + 2ab + b²? Aber das ist einfach nur ins Blaue hinein geraten und ohne irgendwelche Erkenntnisse dahinter..

Hier ist mein kleines Beispiel: BremsProbe 02.mbp Der angepeilte Haltepunkt ist durch eine Rufsäule (gegenüber vom Stellwerk) markiert. Das Vorsignal dient als Auslöser. Hier wird anhand der Geschwindigkeit und Bremskraft ermittelt, wann der Zug gestoppt werden muss. Das Hauptsignal schickt den Zug wieder auf die Reise. Dabei bekommt er eine zufällige Geschwindigkeit zwischen 80 und 300 km/h und eine zufällige Bremskraft zwischen 2 und 45 m/s² Der Abstand zwischen Vor- und Hauptsignal beträgt 2 Kilometer! (Das reicht knapp bei 300 km/h und 2 m/s² Verzögerung) Ich habe ein paar Kameras aufgestellt, mit denen sich das Geschehen beobachten lässt. Kamera 4 zeigt die Telemetriedaten jeder Runde Die Genauigkeit, mit der ein Zug in diesem Szenario den Haltepunkt trifft, finde ich bemerkenswert.

Ja - du kannst sie in der Objektliste als Filterkriterium benutzen

Ich experimentiere auch gerade damit und stelle fest, dass ich das Ergebnis von Speed * Speed / Decel halbieren muss, um den tatsächlichen Bremsweg zu erhalten. (Maßstab ist auch bei mir 1:1 um die Sache nicht unnötig kompliziert zu machen) Alle Achtung übrigens, Thomas, wie schnell du die Sache mit dem "deferred call" durchschaut hast.

Du kannst doch Erics Methode ganz leicht umkehren, Thomas. Auf der einen Seite hast du die Geschwindigkeit. Also km/h = 3.6 * m / s Auf der anderen Seite hast du die Verzögerung. Also m / s² Damit kannst du bei gegebener Entfernung die Verzögerung ausrechnen. Oder bei gegebener Verzögerung und Entfernung die Dauer. 1 Meter je Sekunde sind 3.6 Kilometer je Stunde (= 60 Minuten mal 60 Sekunden) Damit ist km/h geteilt durch 3.6 = m/s g sei die gefahrene Geschwindigkeit umgeformt in m/s, also s = km / h / 3.6 v sei die Verzögerung d sei die Entfernung bis zum Haltpunkt mit g² / v bekommst du zur gefahrenen Geschwindigkeit den Bremsweg in Metern. Denn bei den Einheiten kürzen sich zwei s und ein m weg. Bleibt ein m übrig. Wenn du den Bremsweg für eine gegebene Geschwindigkeit kennst und auch den Abstand zum Haltpunkt, dann ist die Differenz der beiden der Weg, den du noch mit unveränderter Geschwindigkeit zurücklegen musst. Und wie lange du für den Weg benötigst, errechnet sich aus deiner (umgeformten) Geschwindigkeit g Also: d - (g²/v) ist die Reststrecke vor dem Bremspunkt. Ich nenne sie r Dann ist r / g die Zeit (in Sekunden) die du abwarten musst bevor du bremst. Je nachdem, wie du deinen Bremsweg ausmisst, musst du noch den Maßstab der Anlage (z.B. 1:87) in die Berechnung einfließen lassen. Also zuerst aus der gemessenen Länge des Abstands bis zum Haltepunkt die maßstabsgetreuen Meter formen. Oder gleich den passenden Zollstock verwenden und maßstabsgetreue Meter ausmessen.

Ja und ja. Beispiel und Erklärung folgen, wenn ich wieder am PC sitze. vorweg. Die Bremskraft ist in Meter je Sekunde zum Quadrat angegeben. Damit kannst du die richtige Bremskraft für jede gegebene Geschwindigkeit und Entfernung zum Haltepunkt ausrechnen. Persönlich finde ich es mit zwei Bremspunkten schöner und realistischer. Man bremst ab dem ersten Punkt so, dass man bei jeder Geschwindigkeit ein wenig vor dem zweiten Punkt eine Annäherungsgeschwindigkeit von z.B. 40 km/h erreicht. Und dann peilst du ab dem zweiten Punkt mit fester Bremskraft genau den Haltepunkt an. Den Maßstab musst du nur berücksichtigen, wenn du eine allgemeine Formel aufstellen willst und die realen Abstände für die Berechnung der Bremskraft heran ziehst. Ansonsten genügt ein empirisch ermittelter Faktor für die Distanz.

Köstlicher Humor! "Die Befreiung der Realität von der Wirklichkeit."

Klasse, Aloys

Ja, das darfst du tun. Das hat keine negativen Auswirkungen. Ich wollte gerne nur ein Objekt dafür verwenden, weil ich dann nur ein Objekt ändern muss, wenn ich neue Ideen ausprobieren will ich zeigen wollte, wie man bei diesem (komplizierteren) Weg an die benötigten Daten dran kommt. Ich benutze den kleinen Schattenbahnhof ja eigentlich nur, um die verschiedenen Methoden vorzustellen, die man in der EV anwenden kann. Pick dir davon das raus, was dir gefällt. Das Einzige, was hängen bleiben kann, sind Werte in deinen Variablen. Und die kannst du leicht überprüfen, wenn dir etwas komisch vorkommt. Und beim Wechsel von einer Anlage zur anderen bleibt ganz bestimmt nichts hängen.

Er muss im Auslöser sein. Der Kern meiner EV ist ja, dass eine einzige Definition für alle Ausfahrsignale funktioniert. Es gibt aber individuelle Unterschiede, je nachdem, welches Signal gerade das Ereignis auslöst. Also möchtest du über diesen Auslöser an die individuellen Unterschiede kommen. Zum Beispiel die individuellen Anzeigen im Pult. Und das erreichst du, indem du diese individuellen Dinge in den auslösenden Objekten speicherst. du schreibst also ins Signal: "zu dir gehört dieses Gleis und jene Besetztanzeige" Die Definition für das Einfahrsignal habe ich von den Ausfahrsignalen getrennt, weil ich bei der Einfahrt andere Faktoren beachten muss als bei der Ausfahrt. Ich muss zum Beispiel bei der Einfahrt prüfen, ob im Schattenbahnhof noch mindestens ein Platz frei ist. Aloys verwendet Flügelsignale. Bei denen gibt es noch keinen optischen Unterschied zwischen Ein- und Ausfahrsignalen. Der kam erst mit den Lichtsignalen.

Wow - das hast du alles sehr gut umgesetzt, Aloys Funktioniert prächtig. Dass am Signal 201 die Besetztanzeigen nicht gelöscht werden. liegt am vorherigen Schritt. Der kann beim Signal 201 nicht ausgeführt werden Es soll eine Weiche umgestellt werden. Und das Signal 201 hat als einziges keine zugeordnete Weiche. Deshalb habe ich, wie du im Bild oben siehst, diesen Schritt in eine Bedingung gesetzt. Ich prüfe damit zuerst, ob überhaupt im Signal eine Weiche gespeichert ist. Wenn nicht, dann wird auch nicht versucht eine Weiche umzuschalten. Wenn ein Befehl "ins Leere greift" - also beispielsweise die benötigte Variable nicht findet - dann werden alle nachfolgenden befehle nicht mehr ausgeführt. Das ist eine Schutzmaßnahme, die verhindert dass an solch einer Stelle Unsinn passiert. Anbei die korrigierte Fassung: Aloys Schattenbahnhof (korrigiert).mbp.

Oh ja, den P111 erinnere ich noch gut. Mein Onkel hatte einen und mein Cousin fuhr mit mir damit über den kleinen Erdbeeracker hinter'm Haus. Das war in etwa zu der Zeit, aus der auch mein Avatar Bild stammt.

Die sind in diesem Fall aber in ihrer Auswirkung sehr verschieden. Es ist ratsam, Objekte immer über ihre Adressen anzusprechen und nicht mittels ihrer Namen. Weil man in Lua auch andere Variablen verwendet als Objektvariablen. Wenn du Eins Zwei = 12 schreibst, dann interpretiert Lua das Leerzeichen als Trenner zwischen zwei Namen oder Schlüsselworten. Aber die Objektvariable ist eigentlich ein Bezeichner in einer Tabelle. Daher die Schreibweise ["Eins Zwei"] Und die Anführungszeichen deklarieren alles dazwischen als einen String und somit auch als einen Bezeichner. Damit hast du bei Objektnamen und Objektvariablen viel Freiheit.

Für Objektvariablen gelten andere Regeln, Ronald. Denn diese Namen sind Bezeichner in einer Tabelle. Das erkennst du an der Lua-Schreibweise dieser Namen in eckigen Klammern und Anführungsstrichen. Leer- und Sonderzeichen in Variablennamen bereiten Lua keine Probleme, wenn sie eindeutig als Teil des Namens erkennbar sind. Ich habe übrigens für meine Korrektur Aloys Original Versuch benutzt. Die enthält keine Änderungen von dir.

Hallo @aloys63 Deine EV enthielt nur einen klitzekleinen Fehler. Du hast im Signal den Namen des Zugs gespeichert. Du musst aber die Objektadresse speichern. Das sieht oberflächlich betrachtet gleich aus. Aber es sind zwei verschiedene Dinge. So sieht der Eintrag in der EV bei dir aus: Und so müsste er richtig aussehen: Mit dieser einen Änderung funktionieren bei dir alle Signale so, wie du es vorgesehen hattest: Aloys Versuch (korrigiert).mbp Wenn du Objekte in Variablen speicherst, dann zeigt dir das Modellbahnstudio den Namen des Objekts. Aber es merkt sich nicht den Namen, sondern "das Ding", welches diesen Namen hat. Du könntest drei Loks mit identischem Namen auf der Anlage haben und das Modellbahnstudio wüsste trotzdem immer, welche von den drei Loks gemeint ist, wenn du die Objektadresse speicherst. Es ist übrigens völlig egal, ob dieses Objekt Leerzeichen im Namen hat oder nicht. Viel Spaß mit deiner korrigierten Anlage und deinen weiteren Experimenten Götz

Eine Liste hat fortlaufend nummerierte Zellen. in einer Tabelle hingegen hat jede Zelle einen Bezeichner. Damit haben die Elemente einer Liste eine Reihenfolge, die einer Tabelle jedoch nicht. Diese Unterscheidung wird in fast allen Programmiersprachen getroffen. Und somit auch im MBS. Wenn du eine Tabelle erstellst, dann wirst du bei jedem Element nach einem Namen gefragt. Bei einer Liste ist das nicht der Fall. Lua fasst beide Arten von Elementen in einer Tabelle zusammen. In dieser Hinsicht ist diese Skriptsprache ein Exot. Aber die Tabellen und Listen in den MBS-Objekten haben nichts mit Lua zu tun. Lua hilft dir nur, sie zu verwalten.

Ein Programm verhält sich nur dann verschieden, wenn es (irgendeinen) Unterschied gibt. Sonst nicht. Es hat kein Eigenleben ... "Ich sehe keinen Unterschied" oder "Ich finde keinen Unterschied" ist die bessere Einstellung. Weil du so nicht den Blick für Unterschiede verschließt. Wenn du steif behauptest es gäbe keinen, dann wirst du ihn (und somit die Ursache) auch nur schwer entdecken können.

Versuch doch mal bitte, dem Tabellenplatz zuerst einen anderen Wert zuzuweisen, bevor du ihn löscht. $("Abzweigung").variables["Wartender_Obj"] = 1 -- erst Objekt ersetzen table.remove($("Abzweigung").variables["Wartender_Obj"],1) -- dann löschen

ist immer ein Hinweis darauf, dass die Umstände nicht identisch sind. Da wir dir nicht zuschauen, können wir nur schwer einschätzen, worin genau der Unterschied bestehen mag. Wenn ich bei einem vermeintlichen Klick aufs Gleis die Maus ein wenig ziehe, dann wird das neue Stück angehängt. Lasse ich die Maus still liegen, dann erzeugt der Klick die Kopie an Ort und Stelle. Aber ich kann nicht sagen, ob du vielleicht auf die gleiche Weise mal dieses, mal jenes Verhalten erzeugst.