Goetz

Hast du meinen Lösungsvorschlag nicht gelesen? Hast du dir die angefügte Anlage mit dem Lösungsvorschlag nicht angesehen? Das hier ist die entscheidende Änderung: Ich habe dafür deine Variable "Lokname" benutzt und diese an das Textfeld übergeben. Ebenso gut hätte ich die Variable A nehmen können. Oder unnötigerweise den Text noch einmal von "Lokname" nach "A" übertragen können ... (Und jetzt schau ich mir mal dein "Jetzt hab ich's" an …) Nachtrag: Ja, jetzt hast du's. Du nutzt nur immer noch zwei Variablen, obwohl du nur eine benötigst. In A speicherst du eine exakte Kopie von dem, was in Lokname steht. Das bringt dir nichts.

Bitte, lies meine Erklärung oben noch einmal aufmerksam und Wort für Wort durch. Ach - warte. Ich schreibe es einfach noch einmal und in etwas anderen Worten: Deine Variable enthält eine Referenz zum Objekt V200. Diese Referenz wird als V200 angezeigt, weil die EV dir nichts anderes zeigen kann. Mit einer kryptischen Nummer wäre dir ja nicht gedient. Aber das, was da in der Variablen gespeichert ist, ist kein Text! Hier siehst du es deutlicher als in der Ereignisprotokollierung.

Und die Frage habe ich dir beantwortet. Du hast die Antwort nur noch nicht richtig interpretiert. Dein A enthielt keinen Text, sondern eine Objektreferenz. Und etwas anderes als Text kann das Beschriftungsfeld nicht anzeigen.

Deine Variable enthält das Fahrzeug, nicht den Fahrzeugnamen. Das Fahrzeug ist die Objektreferenz. Sozusagen eine für uns unsichtbare Identifikationsnummer dieses Objekts auf der Anlage. Uns wird zwar der Name des Objekts angezeigt (weil wir bei der Nummer überhaupt nicht wissen würden, welches Objekt damit gemeint ist) aber den Namen bekommst du nur mit Fahrzeug.Name (so, wie du es beim oberen Textfeld machst.) Deine Variablen sind ebenfalls für Objekte bestimmt. Du benötigst aber eine Variable für Text (weil der Name eines Objekts ein Text ist.) Außerdem würde eine Variable reichen. Mit den zwei Variablen machst du nur zweimal denselben Fehler. Lokname wird jetzt angezeigt.mbp

in einer außergewöhnlich schönen Umsetzung. Wenn ich mit den Videos jetzt nicht voran komme, dann bist du schuld daran!

Ich will's versuchen. Für das Beispiel wähle ich Städtenamen (statt Zuggattungen) um eine Weiche umzuschalten. Einfach, weil das plakativer ist und mir schneller ein paar Städtenamen einfielen. Zuerst gibst du jeder Lok, die infrage kommt, eine Variable. Eine Variable ist einfach nur ein Speicherplatz, dem du einen Namen gibst. Den Namen darfst du dir frei ausdenken. Wichtig ist nur, dass alle Loks einen Speicherplatz mit demselben Namen bekommen! Ich nenne ihn in diesem Beispiel "Richtung". Denn an der entscheidenden Stelle werden wir jede Lok die "anklopft" fragen: "Was steht bei dir im Speicherplatz Richtung drin?". Vor dem Namen musst du noch den Informationstyp festlegen, den du speichern möchtest. Im Beispiel werden das Städtenamen sein. Das ist der Typ "Text". Deine Zuggattungen (Fern, Nah, Güter, Bau etc.) wären ebenfalls Text. Und wenn du die Text-Variable namens "Richtung" (oder "ZugGattung" oder "mein_Speicherplatz") erzeugt hast, gibst du als Text dein Unterscheidungsmerkmal ein. Bei mir ist das "Essen" oder "Hamburg" oder "Kiel" etc. Nun setzt du vor die Weiche einen Kontaktpunkt und bestimmst dann, was beim Überfahren des Kontaktpunkts passieren soll. Dabei benutzt du das, was in den Variablen der Loks steht, als Bedingung. Die Bedingung lautet also: "Eigenschaft/Variable besitzt den Wert" Rechts neben Variable klickst du auf das Zahnrad und wählst "Variable(erweitert)" aus. Die erweiterte Art benötigst du, weil du zwei Dinge angeben musst: wer hat die Variable (denn das ändert sich, je nachdem welcher Zug gerade über den Kontakt fährt.) wie heißt die Variable Auf dem zweiten Zahnrad wählst du nun "Auslöser", denn du willst etwas von demjenigen wissen, der gerade über den Kontakt gefahren ist und so dieses Ereignis ausgelöst hat. Es gibt zwei Auslöser: Den Gleiskontakt und das Fahrzeug, welches den Kontakt überfahren hat. Wähl mit dem kleinen Pfeil aus der Liste das Fahrzeug aus. Dann darunter (im Bild nicht sichtbar) den Namen der Variablen. Im Beispiel also "Richtung". Dann änderst du unter dem = Zeichen per Zahnrad den typ auf "Text" Und nun schreibst du eine Stadt (bzw. eine Zuggattung) in das Feld! (Im Beispiel oben steht "Münster") Für die übrigen Städte, welche dieselbe Weichenstellung benötigen, klickst du unten rechts auf "weitere Bedingungen hinzufügen. Im folgenden Fenster kannst du dann eine ganze Liste von Bedingungen erstellen. Und weil bis auf die Städtenamen alle gleich sind, geht es mit dem markierten Copy-Knopf besonders schnell. Du musst nur bei jeder Kopie eine andere Stadt eintragen. Aber- wie gesagt - nur die Städte (oder Zugattungen), welche dieselbe Richtung brauchen. Alle anderen musst du nicht aufzählen. Letzte Aktion: Achte unbedingt darauf, dass die Verbindung zwischen den einzelnen Bedingungen ein "oder" ist. Denn wenn ein Zug nach Münster oder Osnabrück oder Bremen oder Hamburg oder Kiel will, muss er nach Norden abbiegen. Alle anderen Städte fahren an dieser Weiche geradeaus. Die müssen nicht explizit genannt werden, denn geradeaus ist die Stellung für die Weiche, falls die oben genannten Bedingungen nicht erfüllt sind. Warum so viele Städte? Damit du dir vorstellen kannst, dass an der nächsten Weiche erneut sortiert wird. Zum Beispiel: "Duisburg oder Essen nach rechts, der Rest geradeaus ... Jetzt müsste dir theoretisch klar sein, was eine Variable ist. Sie ist einfach ein Platz, an dem man Informationen ablegen kann. Texte, Zahlen, Objekte … was auch immer man sich für später merken möchte. Diese Speicher heißen variablen, weil der Inhalt dieses Speichers geändert werden kann. Er ist also änderbar. Eben variabel. Entschuldigung: Natürlich habe ich Hannover falsch geschrieben. Sorry! Das ist herrlich naiv und kurzsichtig von dir. Ich mach das doch nicht nur für dich. Es gibt eine ganze Reihe User hier, die sagen: Ich muss das in Aktion sehen, sonst verstehe ich es nicht. Das Video muss (und möchte!) ich also trotzdem machen. Zug-Variable bestimmt Weichenstellung.mbp

Ich habe gerade begonnen ein paar Videos zu diesen Themen (EV, Variablen, Schlagworte …) aufzunehmen. Du musst dich aber bitte noch eine Weile gedulden, bis die reif für die Veröffentlichung sind. LUNA heißt mit richtigem Namen übrigens Lua und wird bitte nicht in Versalien (= Großbuchstaben) geschrieben, weil es ein Name ist und keine Abkürzung.

@tjarkheinrich Für solche Fälle sind Variablen gedacht. Du hinterlegst im Zug in einer Variablen die Art des Zuges. In der EV liest du diese Variable aus und nutzt sie als Bedingung, um zu entscheiden wie eine Weiche gestellt werden soll. Da die neue EV Mehrfachbedingungen zulässt, kannst du beispielsweise unterscheiden: Wenn die Variable "Art" den String "Fernzug" oder "Regionalzug" enthält, dann schalte Weiche 1 auf Stellung 1 (= geradeaus), andernfalls (also für "Güterzug", "Rangierfahrt", "Bauzug" etc.) auf Stellung 0.

Oh, please …! Gimme some rest, will you? I'm eager to help but I'm not your lackey, you know?

Ja, stimmt. Da ist das benutzerdefinierte Ereignis eher gerechtfertigt. Für die Dunkelschaltung der Vorsignale ist dein Ansatz sinnvoller. Darum ging es mir in erster Linie. Ich wollte aufzeigen, dass man Muster nach Möglichkeit nur einmal bauen und dann mit individuellen Daten füttern sollte, statt sie viele Male zu kopieren und anzupassen.

You're wrongly passing on a string "vehicle" instead of the object vehicle, which is what you should do. Try $("set grill"):invoke(vehicle) -- no quotation marks around "vehicle"

My mistake - sorry all modules come before any events. So, you may sort your modules differently and you may sort your events outside these modules in any order too. But you cannot stick an event between two modules (unless you put that event itself inside another module.)

und der Hund im Pfeffer - hihi (scnr)

Genau darum geht es! Das ist deshalb vorteilhaft, weil sich diese Dinge erfahrungsgemäß des Öfteren ändern. Beispielsweise kommen weitere Funktionen hinzu, die ebenfalls ausgeführt werden sollen wenn ein Signal schaltet. Mit dem benutzerdefinierten Ereignis muss man es nur einmal an zentraler Stelle ändern. Die Parameter beim Auslösen des benutzerdefinierten Ereignisses habe ich einfach in die vorgesehenen Felder eingetragen. Die Felder werden deshalb bei der Aktion angeboten, weil ich die Variablen im benutzerdefinierten Ereignis erzeugt habe. Die EV "sagt": Du willst das benutzerdefinierte Ereignis für die hell/dunkel-Schaltung auslösen? Dann benötige ich von dir bitte die folgenden drei Informationen. Der Aufwand ist bei deiner und meiner Vorgehensweise mehr oder weniger identisch. Aber das Beispiel eignet sich gut, um den Umgang mit benutzerdefinierten Ereignissen zu üben. Damit man es nicht gerade dann lernen muss, wenn man es unbedingt benötigt.

Hier ist ein Beispiel zu meinem Vorschlag, ein benutzerdefiniertes Ereignis für die hell/dunkel Schaltung aller Vorsignalwiederholer an den Hauptsignalmasten zu verwenden. Das benutzerdefinierte Ereignis erledigt die eigentliche Umschaltung. Die ist ja in allen Fällen identisch. Für diesen Zweck werden beim Aufruf des Ereignisses drei Argumente mitgegeben: Die Stellung des Hauptsignals das Vorsignal-Objekt mit sichtbarem Signalbild das dunkle Vorsignal-Objekt Für jedes Hauptsignal reagiert die EV dann, wenn das Signal umschaltet. Die Aktion ist der Aufruf des benutzerdefinierten Ereignisses mit Übergabe der Signalstellung des auslösenden Hauptsignals und der beiden am selben Mast befindlichen Vorsignale. Ich habe eine kleine Demo angehängt, die das Ganze in Aktion zeigt. Testanlage Vorsignal Dunkelschaltung.mbp

Ja, ich denke das wäre sinnvoll. Vielleicht kann man sogar noch einen Schritt weitergehen und ein "benutzerdefiniertes Ereignis" erstellen. Also ein einziges Ereignis, dass alle Signale nutzen können um jeweils ihre Vorsignale hell/dunkel zu schalten. Denn die Aktion ist ja für alle identisch, nur die Parameter (sprich: die Objekte) ändern sich.

Mist - wieder kein Bier dabei Stehen drei Düsseldorfer am Tresen. Der erste bestellt ein Pils, der zweite ein Weizen, der dritte einen Orangensaft. Fragen ihn die ersten zwei: "Was ist denn mit dir los?" Antwortet er: "Na, wenn ihr kein Bier trinkt, dann will ich auch keins."

Das glaube ich dir gerne, Brummi. Okay, das kann ich, soweit mein Wissen in dieser Hinsicht reicht, nachvollziehen.

Okay, das ist machbar, aber irgendwie krumm. Da würde ich mir ein Update der Vorsignale mit der Erweiterung um eine zusätzliche Signalstellung "dunkel" wünschen.

No, not quite. But the timers, event variables and the event script come first. Below that you may sort your modules (folders) and events in any order. are placeholders that you declare. Give them any name you want. When you call the generic event, you can pass on any data (e.g. the triggering vehicle) to those placeholders. That way, your generic event has access to that object or data and may change its values. The error message is exactly what it says: Your timer script doesn't know what vehicle you're talking about. There's "nil" vehicle stored in the variable "vehicle". When an event is triggered by a vehicle, the triggering vehicle is automatically transferred to the variable "vehicle". But it (as all variables) is a local one, not known to other events. If this wasn't the case, you couldn't have different vehicles triggering different events at different locations. The expiration of your timer is not triggered by a vehicle. So the variable "vehicle" doesn't exist here. You'll need to store the vehicle elsewhere and then access that storage (i.e. variable) in your timer function. Having said that, a timer is not your best choice for a delayed vehicle command anyway. V5 offers a much better alternative: Simply insert a delay command before the action. The EV will take care of the rest and you don't have to bother with reacting to a timer expiring.

@ralf3 Hier zeigt sich ein kleines Problem bezüglich der Vorsignale für die Mastmontage im MBS. Sie lassen sich leider nicht dunkel schalten. Das wäre aber zwingend nötig, denn wie man in deinem Video gut erkennen kann, hat man sonst am selben Mast zwei widersprüchliche Signale: Einmal "Halt" und einmal "Fahrt". Deshalb wird die Vorsignal-Anzeige bei der realen Bahn dunkel (= aus) geschaltet, wenn das Hauptsignal am selben Mast "Halt" zeigt. Ein eigenständiges Vorsignal irgendwo auf halbem Wege zwischen Ausfahr- und Blocksignal wäre vom Ausfahrsignal unabhängig und müsste daher nicht dunkel geschaltet werden. Aber nett aussehen tut es. Auch deshalb, weil das Umfeld gut ausgestaltet ist.

Yes, it is. But what you suggest is two triggering events and not two conditions. You may also have two events triggering the same action. But the method differs, depending on the two events being either of the same type or different ones. If they are of the same type, simply select multiple elements as triggering objects: However if you want two events of different types to trigger the same action, you want to set up a generic event … … and execute this in your two different events: Please, let me know if you'd prefer screenshots with captions in English and I'll gladly exchange them.

@Reinhard möglicherweise hatte er diesen Anhänger zum Vorbild

Aaahh - jetzt ... Es handelt sich um zwei Timer mit sehr ähnlichen Namen. "CheckD1" und "CheckD1west". Ich hatte übrigens keine Zweifel, dass es läuft. Ich fand es nur zu umständlich (weil ich es für einen Timer hielt.) Und natürlich hatte ich verstanden, dass es dir nicht um die konkrete EV ging, sondern um grundsätzliche optische Verbesserungen. Du kannst übrigens auch beide Timer in einer Mehrfachbedingung auswerten. Das ist besser, als diese gestaffelten Bedingungen.

Hallo @metallix Der Aufbau deiner EV ist unnötig umständlich. Du brauchst keinen zweiten Check, ob der Timer nicht läuft. Alles, was dort drin steht, kannst du in den unteren Kasten von "Timer is running" packen, denn wenn diese Bedingung nicht erfüllt ist, dann läuft der Timer nicht.