Goetz

Ich habe mich weiter in das Thema "Weichenbau" eingelesen und dabei festgestellt, dass die 6,4° für den Abzweig ein Näherungswert sind. Tatsächlich wird die Schräge als Verhältnis von Gegen- zu Ankathete angegeben. Das wäre in diesem Fall das Verhältnis 1:9. Der tatsächliche Winkel beträgt dann ca. 6,34° Um mir den Bau weiterer Weichen zu erleichtern, habe ich meine Funktion zur Berechnung der benötigten Werte umgeschrieben. Statt wie bisher die Gradzahl anzugeben arbeite ich jetzt mit dem Verhältnis. So kann ich leichter weitere Weichen wie z.B. eine 500er im Verhältnis 1:12 bauen. Ich ändere die schon veröffentlichten Weichen im Laufe des Tages in 1:9 Weichen um, damit das einheitlich wird.

The double slip switches follow the same switching order that the preexisting and matching lanterns made by seehund have. normal switch point match the lantern order too, of course. But the dss was a bit more of a challenge, with all its different track groupings

Hallo zusammen, an den letzten beiden Tagen hab ich ein paar Standardweichen gebaut, wie man sie für den Maßstab 1:1 recht häufig benötigt. Sie haben die beiden gängigen Radien 190 Meter und 300 Meter. Der Abzweig hat einen Winkel von 6,4° (Verhältnis 1:9) Und die Abmessungen sind so gewählt, dass man sie beliebig zusammenstöpseln kann und dabei immer einen Gleisabstand von 4,5 Metern erhält. Es wird nur wenige unter euch geben, die solche Weichen nutzen können. Weil das keine Modellbahn Maße sind. Aber reale Gleisfelder mit Kreuzungen, Spurwechseln, Gleisharfen etc. lassen sich damit flott bauen. Ihr findet die sechs Objekte in der Kategorie "Gleise, Vorbild-orientiert, Standardgleis". (Danke für die Freigabe, Neo ) Es gibt (zunächst) zwei DKWs und vier Weichen. Wenn der Bedarf da ist, kann ich weitere Weichen z.B. mit Radius 500 und einem Abzweig in 1:12 bauen. Beispiel für ein Gleisfeld mit 4,5 Meter Gleisabstand in den Geraden und Diagonalen

Weil du sie im MBS als Tabelle angelegt hast. Und deine Zellen damit Namen haben. Keine Nummern. Deshalb steht auch oben über der ersten Spalte "Namen"

Wollt ihr mich mit Gewalt missverstehen? Ich zwinge niemanden. Und ich habe auch nicht gesagt, dass es ohne diesen Effekt besser aussähe. Ich meinte nur, dass es schöner wäre den Effekt in der Stärke zu reduzieren. Damit er noch natürlicher wirkt. Ihr müsst bitte sein Bild vom Fachwerkhaus mit Terrasse einmal anklicken, um es in voller Größe zu betrachten. Und dann schaut auf den Saum unten und auf die Eingangstür. An den beiden Stellen sieht man besonders deutlich, dass der Effekt seine eigentliche Wirkung verfehlt, weil er zu stark aufgetragen wurde. Ich denke, dass ist "konstruktive Kritik". Oder nicht?

Nein, damit funktioniert es leider nicht. Eine Tabelle muss "iterable" - also lückenlos nummeriert - sein, damit table.remove() wie von dir gewünscht funktioniert. In einer Liste ist der Index eine Zahl. Eine Tabelle hat Namen als Bezeichner. Auch dann, wenn du als Namen eine Zahl verwendest. Deine 1 ist bei der Tabelle eine "1", also ein String.

Der Unterschied ist enorm, Feuerfighter. Wirklich lohnenswert Aber wärst du bereit, bei deinem Haus den Effekt vorsichtiger zu dosieren? 30% von deiner aktuellen Einstellung wären meines Erachtens genug. Vielleicht noch weniger ... Im Augenblick ist der Effekt so krass, dass die eigentlich tolle Wirkung verpufft. Viele Grüße Götz

Das geht hiermit sehr bequem: Mit der oben genannten Methode kann der GK an seinem Platz bleiben: ohne Relocaten.mbp

Doch, das gibt es. Und dazu noch genau dort, wo man es benötigt: Ich habe mir erlaubt die Aufzählung zu formatieren. Das ist nicht nur nennenswert, sondern sogar besonders gut umgesetzt. Davon können EEPler nur träumen!

würde ich - V5 vorausgesetzt - durch einen Gleiskontakt ersetzen. Den kannst du besser positionieren. Und dann merkst du dir - wie von Tom schon vorgeschlagen - das auslösende Fahrzeug in einer Objektvariablen. Beim Stopp an einem Signal würde ich dieses Signal als Speicherort empfehlen, weil nur in Abhängigkeit von diesem Signal weitergefahren werden darf. Ab der verlinkten Position (47:43) siehst du in diesem Video ein Beispiel dafür, wie man es handhaben kann.

Geil!

Hallo Frank, mit Lua kannst du es so schreiben: for i, Wdh in ipairs({1, 3, 5}) do $("Kippschalter").variables["Lampen"][Wdh].state = state end ipairs nimmt Wertepaare aus einer Tabelle und weist sie den beiden Variablen links vom in zu. Traditionell heißen diese Variablen k und v für key (Schlüssel, also der Name der Zelle) und value (Wert, also der Zelleninhalt). Das MBS nennt die Variablen i (für Index) und Wdh (für Wiederholung), wenn man eine grafische EV umwandelt. Und im konkreten Beispiel spielt der Index i anschließend keine Rolle. Als Funktionsargument übergibt man an ipairs eine Tabelle. Meistens den Tabellennamen. Aber man kann auch direkt die Tabelle einfügen. Die runden Klammern gehören also zu ipairs und kennzeichnen das Funktionsargument. Die geschweiften Klammern darin deklarieren die Aufzählung als Tabelle. for ... in bewirkt, dass der Reihe nach alle Wertepaare aus der Tabelle ausgelesen und an die Variablen übergeben werden. Demo-Anlage: Liste abrufen (Lua).mbp Viele Grüße Götz __________________________________________________________________________ Nachtrag zu and und or: Timba hat es schon angedeutet: Bei and bekommst du nur den letzten, bei or den ersten Wert zurück, weil beides logische Operatoren sind. Sie haben nichts mit Aufzählungen zu tun. Gedacht sind sie für Konstrukte wie if Bedingung_1 == 17 and Bedingung_2 == 4 then Der Vergleich mit == liefert ein true (wahr) oder false (falsch) zurück. Und genau das benötigt if für seine Entscheidung, entweder true oder false. Bei and müssen alle Bedingungen erfüllt sein. Und das bedeutet: Wenn die erste Bedingung nicht erfüllt ist, dann hat sich die Sache schon erledigt. Ist das erste Ergebnis false, dann bekommt das if ein false und der Rest wird nicht mehr geprüft. Eventuelle Funktionen in den nachfolgenden Bedingungen werden nicht ausgeführt! Dasselbe gilt für alle weiteren verknüpften Verbindungen: Sobald eine Bedingung nicht erfüllt ist, bekommt das if ein false gemeldet und die Prüfung wird abgebrochen. Sind alle Bedingungen bis auf die letzte erfüllt gewesen, dann gibt Lua das Ergebnis des letzten Vergleichs ungeprüft an das if weiter. Denn jetzt hängt alles alleine von dieser Bedingung ab. Sie enthält also jetzt in jedem Fall das, was das if bekommen muss. Beim or kehren sich die Verhältnisse um, aber das Prinzip bleibt dasselbe. Diesmal reicht ja eine einzelne erfüllte Bedingung. Also wird das erste wahre Resultat direkt an das if weitergegeben. Und wenn alle vorherigen Bedingungen nicht erfüllt waren, dann gibt Lua die letzte Bedingung ungeprüft an das if weiter, denn sie enthält jetzt die richtige Antwort. Der Empfänger dieser boolschen Verknüpfungen muss nicht zwingend die if-Verzweigung sein. Man kann das Ergebnis ebenso gut an eine Variable übergeben. v = Bedingung > 42 or Bedingung < 1 Die einzelnen Operanden müssen nicht zwingend Vergleiche sein. Jede Zahl und jeder String haben in Lua den boolschen Wert true. Auch die Zahl 0 und der leere String "" Ein fehlender Wert wird in Lua durch nil repräsentiert und als false gewertet. Das erlaubt Tricks wie diesen hier a = (a or 0) + 1 Wenn a existiert, dann ist der Wert links vom or true und wird verwendet. Existiert a (noch) nicht, dann wird es durch die 0 rechts vom or ersetzt. Aus diesen Erläuterungen kannst du ableiten, warum du bei and (nur) den ersten und bei or (nur) den letzten Wert bekommst.

Hallo Frank, dein Posting hatte ich leider durch das nachfolgende von Tesla übersehen. Sorry! Ja, die gibt es. Leg nur bestimmte Bestandteile in die Liste. (Das wäre der einfachste Weg) Die Frage ist: Wie möchtest du unterscheiden, welche Dinge aus der Liste verwendet werden sollen und welche nicht? Du willst nicht alle einzeln ansprechen. Okay. Aber dann musst du doch auf andere Weise festlegen, welche Elemente betroffen sein sollen. Sag du mir, woran die Elemente erkennbar sind und ich sage dir, wie du sie in der Wiederholung identifizierst. Wenn sie z.B. ein bestimmtes Schlagwort haben, dann kann ich dir zeigen, wie du diese Elemente in der Wiederholung rausfilterst. Wenn es der Name ist, dann kann ich dir zeigen, wie du den (mittels Lua) zerlegst und nach einem bestimmten Namensteil suchst. Wenn es der Index in der Liste ist, dann zeige ich dir, wie du eine zweite Liste mit den Indexen erstellst und auf die erste anwendest. Zur dritten Version (die deiner Eingangsfrage am nächsten kommt) habe ich hier eine weitere Demoanlage für dich: Liste abrufen (Auswahl).mbp

Nein, das siehst du falsch. Pardon. Ich hatte fälschlich Ereignisverwaltung gelesen und nicht Ereignisprotokollierung Die Liste bearbeitest du (wie eine Variable) dort, wo sie steht. Im Fall von Franks Beispiel steht sie im Kippschalter. Es gibt mehrere Wege zu dieser Liste. Das Ereignisprotokoll ist einer davon (wenn dort in der rechten Spalte das Objekt steht) Ein Rechtsklick auf das Objekt mit anschließendem "Schlagwort/Variable bearbeiten" ist ein zweiter. Ein Klick auf das Symbol mit den drei waagerechten Strichen im Eigenschaftsfenster ist ein dritter. ...

Hallo Frank, hier ist zunächst eine Version in der alle (und nicht nur ausgesuchte) Elemente der Liste angesprochen werden. Sie kommt außerdem ohne eine Bedingung aus, weil einfach die Schalterstellung an die 5 Lampen übertragen wird. Damit hast du schon zwei Dinge hinzugelernt. Den Einsatz von Wiederholungen und eine Alternative zur Bedingung. Um jetzt gezielt nur einen Teil der Liste anzusprechen, müsstest du diesen Teil irgendwie vom Rest unterscheiden. Und da wäre es doch das einfachste, dass du nur diesen Teil in die Liste packst. Alternativ kannst du es natürlich auch mit einem Schlagwort in manchen Objekten hinkriegen oder anhand des Namens und per Lua ausbaldowern, wer nun umschalten darf und wer nicht. Aber warum willst du dir das Leben schwerer machen als nötig? Demo-Anlage: Liste abrufen (alle).mbp

Das wäre eine "oda abba" Verknüpfung Oppa abba üba Obaammagau oda abba üba Untaammagau oda abba übahaupnich kommp kanna dann im Aeignisprotokoll lesen. scnr

Wow - Danke, Timba!

Da diese Objekte nicht per se in einer Tabelle stehen, kommst du auch nicht mit pairs() dran. Sie können mit der Funktion layout:getEntitiesByKeyword() alle in eine Tabelle übertragen werden. Danke für die Erinnerung, Timba!

Du hast viele Ereignisse erstellt. Aber kein benutzerdefiniertes Ereignis. Das bekommst du über das + Zeichen in der oberen linken Ecke des EV Fensters. Dort kannst du jeden Ereignistyp auswählen um dafür ein neues Ereignis zu erstellen. Unter anderem auch das benutzerdefinierte Ereignis. Dem gibst du dann einen Namen und in der Aktion kannst du es anschließend mit diesem Namen ansprechen.

Nein, der Auslöser ist kein Objekt auf der Anlage. Weder ein Schalter, noch ein Zug, ein Gleisstück, ein Kontaktpunkt oder eine Animation. Und auch kein Timer in der EV. Der Auslöser für benutzerdefinierte Ereignisse ist ein Eintrag in einem anderen Ereignis. Für ein Beispiel fehlt mir aktuell die Zeit. Brauchst du aber auch nicht. Du kommst wunderbar ohne benutzerdefinierte Ereignisse zurecht bis du irgendwann, eines Tages mal denkst: "An dieser Stelle wäre es praktisch, wenn ich aus diesem Ereignis heraus ein anderes Ereignis auslösen könnte." Und wenn dieser Wunsch aufkommt, dann ist das benutzerdefinierte Ereignis das, was du suchst.

Ja, Quackster. Haben sie alle. Jeder, der hier etwas erklärt und somit zum besseren Verständnis der EV beigetragen hat, hat dazu auch kleine Demoanlagen gebaut. Dazu gab es dann entweder Erläuterungen in schriftlicher Form oder in Form eines Videos. Dann geh bitte mal in dich und suche danach, was es ist. Denn irgendetwas macht dich gerade grantig und ungerecht. Es verstellt dir den Blick für all die Mühen, die sich einige hier schon gemacht haben um ihre Erkenntnisse mit der ganzen Gemeinschaft zu teilen. Frag dich bitte mal selbst, warum du nicht siehst bzw. nicht schätzt, was andere beitragen. Und warum du nicht akzeptieren kannst, dass es für andere genauso viel Mühe bedeutet und daher auch nicht alles perfekt ist. Warum du nur für dich in Anspruch nimmst sagen zu dürfen "besser kann ich es eben nicht". Aber an andere die Forderung stellst, sie mögen bitte alles perfekt abliefern. Warum du die Mühen anderer einfach mit einem "ist mir nicht gut genug" vom Tisch wischt. Verständnisvolle Grüße Götz

Hallo Quackster Das hatte zwei Gründe. Erstens muss man ein Werkzeug kennenlernen, bevor man es anwendet. Im konkreten Fall: Man muss Lua im Kern verstehen, bevor man Weichen damit schaltet. Zweitens wären zu dem Zeitpunkt, als die Einführung entstand noch nicht möglich gewesen, weil es das MBS mit Lua (sprich V5) noch nicht gab. Daher war der Zeitpunkt ideal, um vorbereitend denjenigen, die daran Interesse hatten, Grundlagen zu vermitteln. Konkrete Anleitungen zur grafischen EV (zuerst) und zu Lua (im Anschluss) sind geplant, haben sich aber durch äußere Umstände leider verzögert. Gruß Götz

und die scheinen mir, nach einer ersten Durchsicht von Variable "Überprüfung" wird gesetzt und Benutzerdefinierte Fahrt SB<KB das Ergebnis einer ungünstigen Taktik zu sein. Denn letztlich ist das, was passieren soll, vergleichsweise überschaubar. Ich habe mich noch nicht genügend in dein Konzept hineindenken können, um alternative Vorschläge (ohne Lua) anzubieten. Ich habe derzeit den Kopf auch noch nicht richtig frei dafür. Aber vielleicht schaffe ich es nächste Woche irgendwann, dir konkrete Verbesserungsvorschläge zu machen. Wenn du das möchtest.

Hallo Frank, darf ich dir einen Tipp geben? kannst du anders und viel schlanker strukturieren. Du rufst mit einer Vielzahl von Bedingungen jedesmal dasselbe benutzerdefinierte Ereignis auf und übergibst dabei unterschiedliche Werte. Damit muss deine EV viel zu viele Prüfungen durchlaufen, die schlicht nicht notwendig wären. Stattdessen könntest du die Werte, welche deine Entscheidungskriterien sind, an das benutzerdefinierte Ereignis übergeben. Und dort anhand dieser Werte ableiten, was zu tun ist. Die richtige Aktion zu den möglichen Kombinationen hinterlegst du dann am besten in einer Tabelle. Die ist fast immer die bessere Alternative zu mehreren verschachtelten if-Verzweigungen. Weil du beim if alle einzelnen Stationen durchlaufen musst. Einen Tabellenplatz kannst du hingegen direkt adressieren. Beispiel: Ein Signal soll auf Fahrt schalten, wenn zwei Weichen dahinter auf Gerade stehen. Bei Abzweig soll Langsamfahrt gezeigt werden. Signalstellung = { {3 , 3} , {3 , 2} } a = W1 + 1 b = W2 + 1 Stellung = Signalstellung[a][b] W1 und W2 stehen in diesem Pseudocode für die Stellungen der Weichen 1 und 2. Weil ich keine 0 gebrauchen kann, addiere ich noch eine 1 dazu. Mit der Stelle der ersten Weiche wähle ich entweder den erstenoder den zweiten Block aus. Mit der Stellung der zweiten Weiche wähle ich in dieser Gruppe entweder den ersten oder den zweiten Wert aus. Nur wenn beide Weichen die Stellung 1 haben (was durch das Hinzuaddieren von 1 dann eine 2 ergibt), lande ich im zweiten Block beim zweiten Wert. Es ist im Beispiel der einzige Fall, in dem die Stellung 2 (= Fahrt) ist. In allen anderen Fällen bekomme ich eine 3 (= Langsamfahrt). Es ist kein einziges if im Spiel. Lieben Gruß Götz

Die Kombination Beige - Purpurrot ist das Farbschema von TEE und Rheingold in den Siebzigern. Das ist längst Geschichte. Das gelb-graue Design ist die Farbgebung für Fahrzeuge der Systemtechnik und ein aktuelles Farbschema.