Goetz

von denen rede ich, wenn ich Abwärtskompatibilität anspreche!

Das kann sie doch. Nur wenn das Ziel des Befehls gar nicht existiert, dann geht es in die Binsen. Aber dann ist der Befehl auch Unsinn und hätte in der V4 eigentlich einen Alarm auslösen müssen statt unbemerkt unter den Tisch (resp. ans Ende der Liste) zu fallen. @Andy Deine Fragen 1, 2 und 3 muss natürlich Neo beantworten. Als Außenstehender kann ich nur anmerken, dass ich richtig bzw. besser finde, wie es jetzt gehandhabt wird. Darüber hinaus bin ich mächtig beeindruckt von dem Maß an Abwärtskompatibilität, das Neo erreicht hat. Das ist eine sehr beachtliche Leistung.

Der Befehl "Umschalten" ist eine Modulo Operation. Weil das Signal oder die Weiche von der höchst möglichen Stellung wieder auf die niedrigste umschalten soll. Für diese Operation benötigst du die Anzahl möglicher Stellungen. Und wenn die Weiche nicht existiert, dann ist dieser Wert = 0 Hier ist die Lua Umwandlung eines einfachen "Umschalten"-Befehls für ein Signal. Beachte bitte das %-Zeichen und dahinter die Anzahl der möglichen Stellungen: $("Formsignal 1").state = ($("Formsignal 1").state + 1) % $("Formsignal 1").stateCount

% ist in Lua der Modulo Operator. Modulo bildet den Rest einer Division. Zum Beispiel ist 7 % 3 = 1 ( denn 7 geteilt durch 3 ist 2 Rest 1 ) % 0 wäre also eine Division durch Null, was natürlich nicht gehen kann.

Auch, wenn es nur so aus Spaß gesagt ist: In dieser Formulierung offenbart sich die Ursache für deine Lernschwierigkeiten. Man kann Wissen nicht in den Kopf hämmern. Lernen ist nie und nimmer ein Kraftakt. Und dass man "sich etwas in den Kopf hämmern müsse" empfehlen stets diejenigen, die selbst nicht viel gelernt haben. Weil sie selbst nicht wissen, wie Lernen geht. Hör nicht auf solche Menschen. Vergiss das Hämmern. Vergiss das "Einprägen". Das ist kompletter Stuss. (Sorry!) Lernen bedeutet, dass man die Dinge mit Neugier betrachtet. Dass man erforscht und experimentiert. Dass man klein anfängt und ein Element nach dem anderen so lange untersucht, bis man es wirklich versteht. Und das man überall nach Zusammenhängen sucht.

Hallo @schlagerfuzzi1, Hier hast du deine Anlage mit ein paar einfachen EV Beispielen zurück. Nein, ganz bestimmt nicht. Weil Variablen ein ganz wichtiger Bestandteil jeder Programmiersprache sind. Aber mit der neuen EV hast du es vielleicht einfacher, Variablen zu verstehen. Und das bleibt weiterhin der einzige Weg etwas zu erreichen. Auf der Anlage passieren bestimmte Ereignisse. Ständig und überall. Mit der EV kann man sagen, was das MBS tun soll, wenn solch ein Ereignis (Zug betritt Gleis, Signal schaltet, Sack Reis fällt in China um …) passiert. Und mit Lua kann man das, was als Reaktion auf ein Ereignis geschehen soll, in Skriptform schreiben statt es aus Bausteinen zusammenzufügen. Gewonnen ist mit Lua erst dann etwas, wenn man komplexe Bedingungen auswerten will. Und von solch komplexen Situationen bist du noch sehr weit entfernt. Weil du vorher lernen musst, wie du die einfachen Abläufe zuverlässig steuerst. Schlagerfuzzis Fragen 01.mbp

nützt dir überhaupt nichts, Wolfgang. Daraus lernst du nichts. Es ist viel lehrreicher, wenn du das selbst machst. Dazu baust du zuerst eine gewöhnliche EV. Zum Beispiel für den Schalter. Wenn der Schalter das Signal auf Fahrt schalten soll, dann sieht das in der EV zum Beispiel so aus: Ein Klick auf das Symbol, welches ich im Bild markiert habe, wandelt diesen Teil deiner EV dann in ein Lua Skript um: Und anders als bei einem Skript von mir oder jemand sonst weißt du bei deinem Skript schon genau, was es tut. Weil du das selbst in der EV festgelegt hast. Denn wenn man die Aktionen für ein Ereignis auf Lua umstellt, dann tut das Skript ganz genau das, was auch die EV vorher getan hat. Der ganze grüne Text ist übrigens nur ein Kommentar. Ein Hinweistext. Das ganze Skript für "Schalter stellt Signal auf "Fahrt" ist also nur eine einzige Zeile Lua. Mehr nicht. Es ist deshalb so wenig, weil ich so wenig in die EV gepackt hatte. Der Schalter schaltet das Signal Signal auf Fahrt - egal, in welche Richtung man ihn umschaltet. Wenn diese einfache Version verstanden ist, dann kannst du den nächsten Schritt versuchen und dir eine neue EV bauen, welche den Schalter zum Umschalten zwischen Fahrt und Halt benutzt. Und das wandelst du dann wieder in Lua um und schaust, was für ein Skript dabei entsteht. Und dasselbe machst du auch für Frage 2 und 3. Bau dir die EV dazu, wandle die Aktionen in Skripte um und schau dir die Ergebnisse an. Fragen die du dir selbst nicht mit der EV beantworten kannst, wirst du auch mit Lua nicht beantworten können. Denn beides stellt an den logische Verstand dieselben Ansprüche. Und Lua ist abstrakter, wohingegen die EV gerade enorm an Lesbarkeit hinzugewonnen hat.

Dann müsstest du eine YouTube Link eigentlich auch als solchen erkennen. Erstens an dem unverwechselbaren "Play"-Knopf in der Mitte. Der leuchtet rot, sobald man mit der Maus über das Vorschaubild geht. Und zweitens am Wort "YouTube" in der unteren rechten Ecke, sobald der Clip läuft. Das kann unmöglich der Grund sein

Der "deferred call" (= verzögerter Aufruf) ist auch in der EV zu erkennen, bevor du in Lua umwandelst. Du siehst eine blaue Box mit der Aktion "Ausführung verzögern". Und oben einen Hinweis zum Grund für die Verzögerung und eine Erklärung dazu, wann sie benötigt wird. Am bequemsten ist, wenn man den Befehl schon vor der Umwandlung in Lua rausschmeißt. Denn nachträglich muss man die ganze "if … elseif … end" Klammer rausschmeißen. Das ist mühseliger und fehlerträchtiger. Mit deferred call: if not deferredCall then defer(0, "_Compatibility_Delay") elseif deferredCall == "_Compatibility_Delay" then $("Ereignisse").variables["Anzahl"] = $("Ereignisse").variables["Anzahl"] + 1 $("Ausgabe").text = $("Ereignisse").variables["Anzahl"] end Du benötigst nur den Block im elseif. Der Rest ist die Zeitverzögerung für die Synchronisation. ohne deferred call: $("Ereignisse").variables["Anzahl"] = $("Ereignisse").variables["Anzahl"] + 1 $("Ausgabe").text = $("Ereignisse").variables["Anzahl"] Zu den übrigen "paar Systemaufrufen" kann ich noch nichts sagen, weil die mir noch nicht begegnet sind.

Angeregt durch die Frage vom SputniKK habe ich ein Video aufgenommen, in dem ich zeige wie man mittels Gleiskontakt Züge im Bahnhof mittig stoppen kann. Im Video stelle ich eine Vermutung bezüglich asymmetrischer Zugverbände an, die ich inzwischen zugunsten einer besseren verworfen habe: sich als Unsinn herausgestellt hat! Wenn sich das erste und das letzte Element im Zugverband in der Länge unterscheiden, dann verrutscht der Mittelpunkt des Zuges ein wenig. Ich glaube, dass er um die halbe Differenz der beiden Wagenlängen verrutscht, weil zur Ermittlung der Zugmitte die beiden Waggonmitten genutzt werden. Und die sind eben nicht gleich weit von beiden Enden entfernt. Für den Bahnhofsverkehr ist dieser Versatz kein Problem. Aber bei einer Schlepptenderlok auf einer Drehscheibe wird man es berücksichtigen müssen. Ich habe mich während der Aufnahme durch den asymmetrischen Bahnhof und den asymmetrisch zusammengestellten VT98 täuschen lassen: Es sah nur so aus, als würde er nicht mittig stoppen. Ich habe später bei dieser kleinen Testanlage mittels Lineal (aus dem Zubehör) nachgemessen und festgestellt, dass der VT98 genau mittig stoppt. Da ist nichts schief und auch nichts verrutscht, außer meinem Augenmaß, dass sich hier täuschen ließ ;-)

Ich bin gerade dabei, ein kleines Video dazu anzufertigen.

Wie soll dir das jemand beantworten ohne zu wissen, was du überhaupt machst?

Das sieht klasse aus!

Das ist nicht schlimm. Passiert allen ständig. Geht gar nicht anders. Aber es ist wichtig, was du mit solchen Denkfehlern machst! Bzw. was du aus ihnen machst. Wisch sie nicht beiseite. Sondern schau ganz genau, welchen Denkfehler du gemacht hast und warum. Das ist die Essenz, aus der man Dinge wie die EV lernt. Deine Denkfehler zeigen dir genau, welches Detail du missverstehst. Du musst dir nur erlauben hinzusehen. Ohne Scham. Und mit Neugier!

Das ist kein Müll. Im Gegenteil - der nächste mit einer ähnlichen Frage findet diesen Thread und freut sich, dass es schon eine Antwort gibt. Deshalb wäre es gut, für neue Fragen neue Threads zu starten. Das gibt anderen eine bessere Chance, solche Themen zu finden.

Dreh nicht die Bodenplatte, sondern deinen Standpunkt. Einfach den Mauszeiger mitten ins Bild legen, mittlere Maustaste (= Mausrad) gedrückt halten und Maus bewegen. Übrigens öffnest du für eine neue Frage besser auch einen neuen Thread mit passendem Titel. Sonst ist es ein Glücksspiel, ob jemand (wie ich jetzt) die neue Frage findet und beantwortet.

Du hast ein Ereignis, dass die Lok abbremst, wenn sie das Bremsgleis betritt. Diesem Ereignis fügst du eine Bedingung hinzu: Die Bedingung lautet: Signal steht auf Position Signal ist das Blocksignal hinter dem Bremsgleis Stellung ist HP0 Jetzt wird der Zug nur noch gebremst, wenn das Signal auf Halt steht. Beim Haltegleis benötigst du genau dieselbe Bedingung. Damit bleibt noch ein letztes Problem: Das Signal schaltet ausgerechnet dann auf Fahrt, wenn der Zug schon auf dem Bremsgleis unterwegs ist. Wahrscheinlich spricht das Ereignis für das Umschalten des Signals bei dir im Moment nur den Zug auf dem Haltegleis an. Füge diesem Ereignis eine zweite Aktion hinzu, die genauso wie die erste einem beliebigen Zug eine Geschwindigkeit gibt. Aber diesmal nicht dem Zug auf dem Haltegleis, sondern dem zug auf dem Bremsgleis.

Weil du die falschen Blöcke frei gibst. Ich beziehe mich auf diese Fassung der Anlage von heute Abend: Du schaltest den Block vor der Lok frei. Das ist falsch. Du musst die Einfahrt in den Block hinter der Lok frei geben. Also das Signal auf Grün schalten, welches eine Position weiter zurück liegt. Das Verfahren nennt sich "Selbstblock". Das Prinzip ist wie folgt: Ein Signal steht nur dann auf Rot, wenn der Abschnitt hinter dem Signal besetzt ist. Die Grundstellung ist also Grün. Bitte, schmeiß deine gesamte EV wieder über den Haufen. Nicht deaktivieren und für später aufbewahren, sondern wirklich wegwerfen. Da ist viel zu viel Mist drin, der dich verwirrt. Und nun musst du zwei Dinge gedanklich trennen: Zuerst das Starten und Stoppen einer Lok per Signal. (Das klappt bei dir schon recht gut, aber noch nicht fehlerfrei.) Und dann kommt erst die Blocksteuerung. Du musst also zuerst für alle vier Signale das Stoppen und Starten eines Zuges neu einrichten. Und durch manuelles Bedienen der Signale prüfen, dass alle vier richtig arbeiten. Der Zug muss bei jedem Signal durchfahren, wenn es Grün zeigt anhalten, wenn es Rot zeigt und wieder losfahren, wenn er am roten Signal wartet und das Signal auf Grün wechselt. Wenn das einwandfrei funktioniert, dann kommt die Blockschaltung dran: Wenn ein Zug am Blocksignal 1 vorbei gefahren ist, dann muss er das Signal für Block 4 auf Grün schalten. Denn den Block 4 hat der Zug gerade verlassen. Der ist nun frei für den nächsten Zug. Wenn ein Zug am Blocksignal 2 vorbei gefahren ist, dann muss er das Signal 1 auf Grün schalten. usw.

Not surprising, Curt. The refresh rate of your monitor is 60 Hz. It cannot show more than 60 different frames per second. If you sync the output of 3D MBS with your monitor, the software only renders frames that the monitor can actually show. Without the sync, the software may well be capable of producing many more frames. But the monitor can't show them, because it's refresh rate is fixed. Anything else would result in unbearable flickering. So what'll happen, when the software produces more frames than the monitor can handle? Simple: The next frame is ready to show while the monitor is still busy drawing the previous one. Halfway down the screen (or where ever the drawing process is at that moment), the content changes to the new frame. If you have movement in your picture, you may notice a rip in your picture. The faster the movement, the more noticeable the tearing. The "vertical sync" option prevents tearing, that's all. At framerates below 60, you shouldn't see any difference between "vertical sync" on / off.

That's spot on, Andy

Warum macht wer was? Da machen so viele Loks ganz unterschiedliche Dinge falsch. Nimm dir zuerst nur einen einzigen dieser Fehler vor und untersuche ausschließlich das Verhalten. Hast du das schon probiert? Dass du einen einzelnen Fehler gründlich untersuchst? Und mit "untersuchen" meine ich nicht "mit dem, was andere tun, vergleichen". Das bringt nämlich nichts. Ich meine damit, dass du selbst versuchst genau zu verstehen, was welcher Schritt in der EV an dieser Stelle auslöst.

Aber die von ralf3 eigesetzte Brücke ist - im Widerspruch zu meinem ursprünglichen Eindruck - hoch genug für eine OL. Drum hatte ich meinen ersten Text durchgestrichen.

unterschiedliches - je nachdem, welche Lok (ohne C, weil es die Kurzform von Lokomotive ist) du fahren lässt. Die V 200 fährt auf deiner Anlage am Blocksignal 1 durch und der nächsten Lok aufs Heck, aber keine Lok zieht vom Blocksignal 4 nach und fährt in das frei gewordene Gleis. Ich glaube, du musst zunächst einmal jede Position einzeln betrachten und lernen, wie man diesen Punkt richtig verschaltet. Sonst hast du zu viele Baustellen auf einmal.

Würde ich so nicht sagen. Erstens gibt es unter Brücken und in Tunneln manchmal Oberleitungen (resp. Stromschienen), die ein ganzes Stück tiefer sitzen und den Abnehmer ein Stück nach unten drücken. Das ist nur im MBS fast nicht umsetzbar. Und zweitens gibt es auch Kastenbrücken, die nicht für elektrifizierte Strecken gebaut wurden und somit auch nie eine Oberleitung bekommen werden.

siehst du auch fast nichts vom Fahrdraht. Hier habe ich mal ein kurzes Stück zum Vergleich eingezogen. Schau mal, ob es dir ins Auge springt oder ob du es suchen musst.