Goetz

Klar - du hast einen Rundungsfehler mehr in deiner Formel, weil du erst die Wurzel ziehst und dann wieder quadrierst.

Sorry - blöde Schlamperei von mir. Du multiplizierst die beiden Werte. Das muss ich dann natürlich auch tun (und sie nicht dividieren) Faktor1 = 2.25504 Bremsweg = 3536 decel_Faktor = Faktor1 * Bremsweg Speed = 150 local A = Speed ^ 2 / decel_Faktor A == 2.8217336153442 Bei dieser Vereinfachung kann man natürlich auf die Berechnung vorab verzichten: local Faktor1 = 2.25504 local Bremsweg = 3536 Speed = 150 local A = Speed ^ 2 / Faktor1 / Bremsweg A == 2.8217336153442

Hallo @Timba dann hätte ich dazu noch einen anderen Tipp: könntest du einmal zu Beginn als globale Konstante im Modul-Skript ablegen, statt es bei jedem Aufruf neu zu berechnen. Den fixen Teil von folgendem Term natürlich auch. Und wenn du dabei den Zahlen 2.25504, 3563 etc. aussagekräftige Namen gibst, dann wäre das noch ein Bonus. Beispiel: Faktor1 = 2.25504 Faktor2 = 3536 decel_Faktor = Faktor1 / Faktor2 -- und an geeigneter Stelle local A = vehicle.currentSpeed^2 / decel_Faktor Ich kenne die Bedeutung der beiden Zahlen nicht. Drum habe ich sie im Beispiel Faktor1 und Faktor2 genannt. Und ich habe in deiner A Formel aufgeräumt. Wenn du erst eine Wurzel ziehst und dann das Ergebnis wieder quadrierst, machst du unnötig viele Rechenschritte.

Dafür gibt es das neue Modewort "deep(l) fake"

Du wirst beim ersten Einsatz von V5 gefragt, ob du deine bisherigen Anlagen übernehmen möchtest. Wenn du dazu "ja" sagst, dann werden sie automatisch für dich in ein V5-taugliches Format konvertiert. Solltest du komplexe Ereignis-Verwaltungen in diesen Anlagen haben, dann musst du die vielleicht anpassen. Aber es wäre sowieso ratsam, die EV mit den Mitteln aus V5 neu zu bauen, weil du sie jetzt viel schlanker und effizienter gestalten kannst.

Er meint die Schreibweise des Namens. Lies doch bitte den ersten Satz, den er zitiert hat. Dann ist klar worauf er sich bezieht. Auszug aus der Website zu Lua:

Doch, selbstverständlich. Der voraus liegende Block ist zum Beispiel beim Passieren des Vorsignals noch besetzt, wird aber kurz darauf frei. Nur den umgekehrten Fall gibt es nicht. Wenn das Vorsignal "Fahrt" zeigt, dann wird das Hauptsignal nicht kurz darauf auf "Halt" umschalten. Du kannst schon mit der Verzögerung arbeiten. Du musst nur hinter die Verzögerung eine weitere Prüfung des Signals setzen. Demo-Anlage: Demo - Verzweigung nach Verzögerung.mbp

Nein, das tut es nicht. (Wenngleich beides manchmal für ähnliche Zwecke verwendet wird) true und false sind die Grundlage von allem. was in deinem PC passiert. Das ist "ja" und "nein" "erfüllt" und "nicht erfüllt" "wahr" und "falsch" Es ist ein einzelnes bit, welches entweder auf 1 (= true) oder 0 (= false) steht. true und false sind die Basis für jede Verzweigung. Es gibt eine Bedingung, die entweder "erfüllt" oder "nicht erfüllt" ist. Ist die Bedingung true, dann wird der eine Programmteil ausgeführt. Ist sie false, dann geht es mit dem anderen Programmteil (nach dem else) weiter. Ich plädiere für aussagekräftige Variablennamen anstelle zusätzlicher Kommentare. Beispielsweise Position_ist_erreicht anstelle von Kran2, denn diese Variable wird in Berlioz Beispiel immer dann auf true gesetzt, wenn der Kran ein Ladegut aufgenommen/abgesetzt hat. Und du hast schon im ersten Anlauf einiges erreicht und gelernt. Aber bevor du jetzt mit drei oder vier Zügen weitermachst, kümmere dich vorab darum, das neu erlernte Wissen richtig zu durchschauen. "Jetzt nutzen und später mal lernen" funktioniert nicht. Bau die Beispiele nach, ohne sie abzuschreiben. Damit meine ich nicht, dass du sie auswendig lernen sollst. Das wäre Blödsinn. Du musst dich mit den Beispielen und Erklärungen beschäftigen, bis du sie in allen Details verstehst. Wenn du sie durchschaust, dann kannst du sie selbst herleiten. Wenn du sie nicht selbständig bauen kannst, dann gibt es noch offene Fragen. Denen musst du dann nachgehen. Und wir helfen dir gerne dabei.

Man kann auch ganz darauf verzichten, das nächste Ziel in einer Objektvariablen abzulegen. Im folgenden Beispiel nutze ich die Objektvariable "Ziel" für die Zahl, welche die nächste Tabellenposition bestimmt. (Ursprünglich "Var_Ladefolge" genannt) Außerdem prüfe ich bei einem Klick auf den Startknopf, ob die Sequenz schon läuft. Dafür benutze ich die Objektvariable "Ziel" mit folgendem Trick: Eine Variable gilt in Lua als true, wenn sie einen Inhalt hat. Ist sie leer (= nil), dann wird sie als false gewertet. Mit if not Ziel then kann ich also sagen: Nur ausführen, wenn kein Wert in Ziel steht! Taster01 wird betätigt if not $("Schienenkran").variables["Ziel"] then $("Schienenkran").variables["Ziel"] = 2 $("Schienenkran").crane:moveTo (Ladefolge[1]) end Die Ladefolge gehört nicht in das Skript für "Taster01 wird betätigt", weil die nicht bei jedem Tastendruck neu angelegt werden muss. Die gehört in ein eigenes Skript. Solch ein Skript im Basismodul wird beim Start der Anlage einmal ausgeführt. Es ist für all die Dinge gedacht, die man zu Beginn einmal initialisieren (= auf Anfang setzen) möchte. <> Skript Ladefolge = { $("Holz05"),$("Kklm505_11"), $("Holz06"),$("Kklm505_05"), $("Holz12"),$("Kklm505_06"), $("Holz05"),$("Kklm505_12"), $("Holz06"),$("Kklm505_11"), $("Holz12"),$("Kklm505_05"), $("Holz05"),$("Kklm505_06"), $("Holz06"),$("Kklm505_12"), $("Holz12"),$("Kklm505_11"), $("Holz05"),$("Kklm505_05"), $("Holz06"),$("Kklm505_06"), $("Holz12"),$("Kklm505_12") } Diese Variante 2 hat nur 2 Ereignisse, denn die Änderung der Variable ist kein Trigger mehr. Wozu auch? Ich will ja den nächsten Schrott ausführen, wenn der vorherige erledigt ist. Damit genügt doch der Trigger "hat Transportgut aufgenommen/abgesetzt" Kran hat ein Transportgut aufgenommen/abgesetzt local Ziel = $("Schienenkran").variables["Ziel"] if Ziel <= #Ladefolge then $("Schienenkran").crane:moveTo(Ladefolge[Ziel]) $("Schienenkran").variables["Ziel"] = Ziel + 1 else $("Schienenkran").crane:reset() $("Schienenkran").variables["Ziel"] = nil end Bitte beachten, dass die Objektvariable "Ziel" am Ende der Sequenz wieder auf nil gesetzt wird, damit der Knopf den Zyklus erneut starten kann. Die lokale Variable "Ziel" hat nur den Zweck, das Skript lesbarer zu machen. Variante 2 gibt es als Entwurf unter der Content-ID: 8B8C5D4A-576A-42F0-BA99-94613C049C61

Die zusätzliche Variable Kran2 für "go" und "wait" ist aber eigentlich Umstandskrämerei und du kannst das alles einfacher haben. Wenn dein Kran einen Schritt erledigt hat, dann soll er den nächsten nachladen. Und wenn er den nachgeladen hat, dann soll er ihn ausführen. Also kannst du doch ebenso gut auf die Änderung der Variablen Kran1 reagieren und auf Kran2 ganz verzichten: -- Schalter01 wird betätigt Ladefolge = { $("Holz05"),$("Kklm505_11"), $("Holz06"),$("Kklm505_05"), $("Holz12"),$("Kklm505_06"), $("Holz05"),$("Kklm505_12"), $("Holz06"),$("Kklm505_11"), $("Holz12"),$("Kklm505_05"), $("Holz05"),$("Kklm505_06"), $("Holz06"),$("Kklm505_12"), $("Holz12"),$("Kklm505_11"), $("Holz05"),$("Kklm505_05"), $("Holz06"),$("Kklm505_06"), $("Holz12"),$("Kklm505_12") } Var_Ladefolge = 1 $("Schienenkran").variables["Kran1"] = Ladefolge[Var_Ladefolge] -- Variable Kran1 wird gesetzt $("Schienenkran").crane:moveTo ($("Schienenkran").variables["Kran1"]) -- Kran Schienenkran hat ein Transportgut aufgenommen/abgesetzt Var_Ladefolge = Var_Ladefolge + 1 $("Schienenkran").variables["Kran1"] = Ladefolge[Var_Ladefolge] -- mehr braucht es nicht! Eine letzte Unschönheit ist, dass die Variable "Var_Ladefolge" zum Schluss einen zu hohen Wert bekommt und damit in der Tabelle "Ladefolge" ins Leere greift. Glücklicherweise verträgt die Kransteuerung das und tut nichts, wenn moveTo() eine leere Adresse zugewiesen bekommt. Aber du könntest den Wert prüfen und etwas anderes tun, wenn das Ende der Tabelle erreicht ist. -- Kran Schienenkran hat ein Transportgut aufgenommen/abgesetzt Var_Ladefolge = Var_Ladefolge + 1 if Var_Ladefolge <= #Ladefolge then -- das # vor dem Tabellennamen steht für "Anzahl der Elemente in dieser Tabelle" $("Schienenkran").variables["Kran1"] = Ladefolge[Var_Ladefolge] else $("Schienenkran").crane:reset() end Leider sieht ein crane:reset() in diesem Fall nicht schön aus. Die Reihenfolge der Bewegungen ist falsch. Als Entwurf hochgeladen unter Content-ID: D6E75AB2-4FE7-4B7A-A36D-31665635BC24 Weiterhin viel Spaß bei deinen Experimenten

Das ist gut, denn aus deinem Versuch kannst du sehr viel lernen. Ich möchte mit deiner Variablen "Kran2" beginnen. Darin speicherst du einen Text, den du als Bedingung auswertest. Das ist nicht klug, weil der Vergleich von Texten besonders aufwändig ist. Eigentlich willst du nur zwei Zustände unterscheiden. An und Aus. Dafür gibt es einen besonderen Variablentyp namens Boolean. (Der Name geht auf George Boole, den Vater der booleschen Algebra zurück.) In einem Boolean speichert man entweder true oder false (für wahr oder falsch) Jeder Vergleich liefert als Ergebnis ein true oder false, weil zwei Terme entweder gleich sind oder nicht. Deshalb erwartet eine Bedingung (sprich: das if) immer ein true oder false. Wenn du "Kran2" auf true bzw. false setzt, dann kannst du einfach schreiben if Kran2 then und benötigst keinen Vergleich. -- für Kran_go if $("Schienenkran").variables["Kran2"] then $("Schienenkran").crane:moveTo ($("Schienenkran").variables["Kran1"]) $("Schienenkran").variables["Kran2"] = false end -- für Kran_Ende if not $("Schienenkran").variables["Kran2"] then Var_Ladefolge = Var_Ladefolge + 1 $("Schienenkran").variables["Kran1"] = Ladefolge [(Var_Ladefolge)] $("Schienenkran").variables["Kran2"] = true end Beachte bitte, dass unter Kran_Ende geprüft wird, ob "Kran2" nicht wahr ist! if not Kran2 then Diese Änderung gibt es als Entwurf unter Content-ID: E4CB71C1-6591-45B6-9346-88A84E4E8746

Not only are they common knowledge. They're well established and therefor understood by all translating programs. Unlike "abba", "oda" etc.

ganz großes Kino, Brummi

Ein kleiner Abstecher, der nur am Rande etwas mit dem eigentlichen Thema zu tun hat. Ich habe gerade dank Neos Hilfe gelernt, wie man in der EV auf die Fallunterscheidung verzichten und die Schalterstellung direkt als An/Aus für die Lichter nutzen kann. Wenn man "Animation stoppen" verwendet anstelle von "Animation abspielen", dann hat man auch da die Möglichkeit, die Position anzugeben, an der die Animation stehen soll. Für das Licht interessieren mich nur zwei Positionen: Start und Ende. Die haben die Werte 0 und 1. Das entspricht der Stellung, die ich vom Schalter bekomme. Deshalb kann ich die Position des Auslösers direkt als Wert für die Position der Animation benutzen. Jetzt steht in der EV für "Schalter wird betätigt" nur noch eine Schleife, welche die Lampen je nach Schalterposition ein oder ausschaltet. Das ist schön übersichtlich und effektiv.

Und davor haben sie auch schon 5 Kerzen mit einem Streichholz angezündet.

Liste oder Tabelle? Was ist der Unterschied? Wann benutzt man was? Während eine Liste eine nummerierte Aufzählung von Elementen ist, bekommen alle Elemente einer Tabelle Namen. Die nummerierte Aufzählung benötigt man dann, wenn man alle Elemente in einer Schleife ansprechen möchte. Eine namentliche Aufzählung ist sinnvoll, wenn man die Elemente individuell auswählen möchte. Vielfach wird man beides kombinieren und dafür möchte ich im folgenden ein Beispiel beschreiben. Für einen Weichengruppenschalter benötigt man eine Liste von Weichen und Stellungen. Wenn ich hier von Einfahrsignal A im Westen ins Gleis 6b möchte, dann muss ich insgesamt 6 Weichen und DKWs in unterschiedliche Stellungen bringen. Diesen Weg kann ich nun komplett in einem Konstrukt aus Listen und Tabellen speichern. Weil ich bei Betätigung des Gruppenschalters alle Weichen schalten möchte, benötige ich eine Liste mit 6 Elementen. Weil ich für jede der Weichen das Objekt und die Stellung hinterlegen möchte, besteht jedes dieser 6 Elemente aus einer Tabelle mit zwei Einträgen: Einem Objekt "Weiche" und einer Zahl "Stellung". In der EV kann ich nun auf Tastendruck alle Elemente der Liste nacheinander benutzen. Ich entnehme jedem Element die Weiche und die Stellung und verwende diese beiden Tabelleneinträge in meiner Aktion "Weiche stellen":

Die Erweiterung für die EV welche ich im folgenden beschreibe, ist derzeit noch in der Entwicklung. Mit dem nächsten Update wird man in der EV die Möglichkeit haben, mit einer einzigen Aktion mehrere Objekte anzusprechen. Beispielsweise mit einem Schalter alle Lampen an- oder auszuschalten, denen man dasselbe Schlagwort gegeben hat: Im Beispiel gebe ich 8 Paulaner Laternen dasselbe Schlagwort "Biergarten". In der EV kann ich nun eingeben, dass sie in einer Wiederholung nacheinander alle Objekte mit diesem Schlagwort suchen soll. Das gefundene Objekt wird an eine lokale Variable namens "Wdh" übergeben und diese Variable kann ich innerhalb der Wiederholung als Ziel einer Aktion auswählen. Die Aktion "Animation abspielen" wird für alle Objekte mit dem Schlagwort Biergarten durchgeführt. Nacheinander wird jedes dieser Objekte als "Wdh" an die Aktion "Animation abspielen" übergeben. Obwohl die Aktionen für alle Laternen nacheinander ausgeführt werden, gehen alle Laternen zugleich an bzw. aus. Denn die Übermittlung der einzelnen Befehle geht rasend schnell. Die Ausführung des Befehls übernehmen die einzelnen Objekte selber. Eine Alternative zu Schlagwörtern sind Listen. Das sind durchnummerierte Aufzählungen, die zum Beispiel Objekte (aber ebenso gut auch alle anderen Variablen) enthalten können. Hier habe ich im Kippschalter eine Liste namens "Laternen" hinterlegt, in der alle Laternen einzeln aufgeführt sind. Diese Liste kann ich ebenfalls für eine Wiederholung verwenden. Für die Wiederholung wähle ich die Liste wie eine Variable aus. Die einzelnen Objekte der Liste übergebe ich wieder an einen temporären Speicher. In diesem Beispiel habe ich ihn in "ListenElement" umbenannt. Das Objekt in diesem temporären Speicher ist dann wieder das Ziel meiner Aktion: Das Ergebnis ist dasselbe. Alle Lampen werden bei Betätigung des Schalters ein- oder ausgeschaltet. Bei Verwendung von Lua kann man auch auf die Prüfung der Schalterstellung verzichten und sie stattdessen direkt als Parameter für die Animation verwenden: local animPos = (state + 1) % 2 -- state ist die Stellung des auslösenden Schalters local animDir = state * 2 - 1 local t = $("Kippschalter").variables["Laternen"] for i, Wdh in ipairs(t) do Wdh.animations["Licht An/Aus"]:play(animPos, animDir) end

Genau so ist es, Tom.

Ja, das wäre es. Und genau das wird demnächst in einem Update kommen. Das Update wird zwei Erweiterungen für die EV enthalten Wiederholungen Listen und Tabellen Für die Wiederholungen kann man entweder Schlagwörter oder Listen verwenden. Oder ein Skript schreiben, welches eine Liste zurück gibt. Ich schreibe am Wochenende mal was dazu. Aber dafür eröffne ich einen neuen Thread.

Mehr zum Signal Ne4 Schachbretttafel findet ihr bei Interesse hier

Der Telegrafenmast unterhalb der vier Bäume (über der roten 1) steht nicht nur an anderer Stelle, sondern auch auf der anderen Seite des Gleises. (Kurvenaußenseite vs. Kurveninnenseite) Der kann also nicht dasselbe Objekt sein wie das Signal auf der linken Seite des Gleises. Ich würde auch ein Signal auf der falschen Seite nebst Schachbretttafel rechts annehmen. Und die nahe Straße wäre ein guter Grund für diese Platzierung des Signals. Der Flügel über der Fahrbahn wäre durch den Straßenverkehr gefährdet.

Ein Streckentelefon wäre nur in unmittelbarer Nähe des Signals sinnvoll. Und auf Höhe der Gleise. Nicht oben auf der Böschung und am Straßenrand. Und warum meinst du, dass er sich mit dem Signal vergriffen hat?

Kann man so machen. Aber wenn jemand eine falsche Wahl trifft, dann erkläre ich zuerst, warum die falsch ist und welche die richtige Alternative wäre. Wenn das verstanden wurde, dann gehe ich den nächsten Schritt und zeige, was es noch für Möglichkeiten gibt und welche Besonderheiten die bieten. Wobei sich das fast immer erübrigt, wenn man die Basics wirklich durchschaut hat. Dann erschließen sich die Besonderheiten oft von alleine, Weil sie darauf aufbauen. Fängt man aber in der Mitte an und zeigt nur den "besten" Weg auf, dann werden die Grundlagen oft nicht verstanden und die Informationen bleiben auch nicht so gut im Gedächtnis. Weil Assoziationen fehlen. Und die sind der Stoff, der Erinnerungen Halt gibt.

Ich habe mir deine erste EV noch einmal genauer angesehen. Für den Fall "Taster, An" hat sie nur einen Eintrag. Den konntest du dort nur einsetzen, als die Bedingung noch leer war. Als beide beschrifteten Felder mit "Bedingung ist erfüllt" und "Bedingung ist NICHT erfüllt" sichtbar waren. Die Aktion ist aber trotzdem im falschen Feld gelandet. Ein weiterer Fehler hat mit den beiden Feldern einer Bedingung gar nichts zu tun. Du beginnst die Animation rückwärts in der Position Start. Du musst sie bitte am Ende beginnen, damit sie von dort zum Start zurücklaufen kann.

Tatsächlich zeigt genau dieser Faden hier - von Anfang an gelesen - dass das nicht der Fall wäre. Denn das Problem war nicht, dass das Feld für "nicht erfüllt" nicht gefunden wurde. Das Problem war ursprünglich, dass nicht klar war, warum eine Bedingung eine Verzweigung ist. Dass man "Schalter an/aus" gleichsetzen kann mit "Bedingung: Schalter ist an - erfüllt/nicht erfüllt". Ein sichtbares Feld für "nicht erfüllt" hätte daran nichts geändert. Der Zusammenhang zwischen zwei möglichen Schalterstellungen und der Prüfung einer Bedingung wäre dadurch nicht deutlicher geworden. Und wenn man weiß, dass man einen Platz für die Aktionen benötigt, die im Falle "nicht erfüllt" ausgeführt werden sollen, dann findet man den schmalen Streifen unterhalb der Trennlinie ebenso leicht wie ein beschriftetes graues (oder auch rotes) Feld.