Goetz

Das freut mich, Hans Genau so war das gedacht. Es ist gar nicht wichtig, welche Dinge du dir rauspickst, solange du nur Kleinigkeiten entdeckst, die nützlich für dich sind.

Es ist in erster Linie schwer, an geeignete Geräusche dranzukommen. Das Modell kann Max mittels Maßzeichnungen selbst bauen. Aber das Geräusch kann er nicht so leicht selbst erzeugen. Er müsste es aufnehmen. Ohne Störgeräusche. Und es nützt nichts, am Bahndamm zu stehen und eine vorbeifahrende Lok aufzunehmen. Weil man ein konstantes Fahrgeräusch benötigt. Nicht eins, das an- und abschwillt. (Und geeignetes Aufnahmeequipment bräuchte man obendrein. Und dazu einen Standpunkt, wo man nur das Fahrgeräusch bekommt. Ohne Vogelgezwitscher. Ohne Hall oder Echo.) Man findet solche Geräusche auch nicht einfach im Netz. Noch weniger als kostenfreie Datei. Da findest du nur die vorbeifahrenden Züge, die eben nicht für diesen Zweck geeignet sind.

Ich habe dem ersten Beitrag jetzt noch das fertige Skript aus der Sendung und die kleine Demoanlage beigefügt. Ich denke, dass das vorne im ersten Beitrag am besten aufgehoben ist.

Freut mich, dass es dir gefallen hat. Danke für dein Feedback, Michael.

Alleine mit der grafischen EV wäre das zwar theoretisch möglich. Aber in der Praxis scheitert man - wie Metallix schon in deinem Thread erklärt hat - daran, dass man die Achsen nicht zu fassen bekommt, wenn man über den generischen "Auslöser" jede Straßenbahn ansprechen möchte, welche die Haltestelle anfährt. Diese Hürde kann man mit Lua sehr leicht nehmen. Und es ist äußerst praktisch, dass man zuerst das Gerüst mit der grafischen EV bauen und anschließend in ein Skript umwandeln kann. So hat man im Skript schon alle Schreibweisen für die benötigten Befehle und muss nur noch Anpassungen vornehmen. In einer Twitch Sendung habe ich heute gezeigt, wie man solch eine Sequenz Stück für Stück aufbauen kann. Hier ist die bereinigte Aufnahme auf YouTube Das Skript, welches in der Sendung entstanden ist (für diejenigen, die nur was nachlesen möchten): local Blinker = { vehicle.animations["Blinker rechts"], vehicle.variables["Hinterteil"].animations["Blinker rechts"], } local Tueren = { vehicle.animations["Tür rechts vorne"], vehicle.variables["Mittelteil"].animations["Tür rechts vorne"], vehicle.variables["Hinterteil"].animations["Tür rechts hinten"] } if not deferredCall then vehicle.deceleration = 2 vehicle.acceleration = 3 vehicle.targetSpeed = 0 defer(3, "Blinker an") elseif deferredCall == "Blinker an" then Blinker[1]:play(0, 1) Blinker[2]:play(0, 1) defer(4, "Tür auf") elseif deferredCall == "Tür auf" then for Index , Tuer in ipairs(Tueren) do Tuer:play(0, 1) end defer(7, "Tür zu") elseif deferredCall == "Tür zu" then for Index , Tuer in ipairs(Tueren) do Tuer:play(1, -1) end defer(2, "Abfahrt") elseif deferredCall == "Abfahrt" then vehicle.targetSpeed = 50 defer(1.5, "Blinker aus") elseif deferredCall == "Blinker aus" then Blinker[1]:stop(0) Blinker[2]:stop(0) end Und das hier sind drei Versionen der Anlage Ohne Steuerung: StraBa Sequenz 00.mbp mit grafischer EV: StraBa Sequenz 01.mbp und die finale Version mit Lua Skript: StraBa Sequenz 02.mbp Ich hoffe, dass ich dem einen oder anderen damit ein bisschen Inspiration bieten kann.

Hier ist ein Bild zu Andys Erklärung: Das Ereignis "Gleiskontakt wird betreten" hat zwei Auslöser. Denn zwei Objekte sind an diesem Ereignis beteiligt: der Kontakt, der betreten wird das Fahrzeug, welches den Kontakt betritt Deshalb muss man im Anschluss an die Auswahl "Auslöser" aus einer kleinen Liste den gewünschten Auslöser wählen. Und weil das Fahrzeug als Auslöser klar identifiziert ist, ist die Angabe eines bestimmten Gleises weder nötig noch sinnvoll.

yippeeee!!!

Don't, Pete. Not at the beginning. Get to grips with one aspect. Just one. When that is fully understood, tackle the next one. You're progress will be much faster that way. Begin with slowing the train at four different spots on your layout, using only a single event definition in the EM. Concentrate on that. Ignore signals, ignore stopping the train, ignore delay times, ignore barriers, switch points and what not.

Clever gemacht! Und wirklich praktisch

Kiwi? I was under the impression that they call themselves all blacks

Hi Pete, the keyword in your following sentence was "principals". That is what you ought to develop. First (though this has nothing to do with the EM) you may want to rethink your signal strategy. Don't close signals ahead of a train. Close them behind the train. Shut the door, so to speak, after a train has entered a section. That way, you keep everyone else out until the train has vacated that section. This is important because other things that I'll explain later will relate to this tactic. Now you'll want to consider that basically you're doing the same thing at every station for every train on any track. Slow it down, when it approaches the station. Stop at the station. Wait for a specified time. Release the train when conditions are right. The trick is to define each basic sets of action only once. And to find a way to use individual parameters within those action sets where needed. This is why you find the selection "trigger" as a possible target of an action. It stands for "whoever triggered this set of actions." Lets pick the contact used to slow an approaching train as a first example. The event is triggered by two elements: The contact itself and the train. One touches the other and that event causes the chain of actions which you define. You'll want to slow down any train that triggers this contact. This means, that the target of your "set speed" action is one of the triggering objects. And its location is of no interest, because the location of the contact has that covered. Of the triggering objects, only one can have a speed: the train. The contact may be of interest in a different context. That's why it is listed as one of the triggers. But in this case, it's not the trigger that you want to talk to. Choose the "set vehicle speed" action click on the cog next to the "[All vehicles]" label in the box on the right pick "Trigger" open the list under "Vehicle" pick "Vehicle" from that list specify your desired speed below You've successfully defined that any train which touches the contact, will be told to slow down to the speed you requested. Now that you've understood how to generalise the "slow the train that touched the contact" principle, you may place multiple contacts for this purpose at strategic locations. Each with a unique name. At the top of your event definition, you have the "When will the event be triggered?" selection. Here you may choose multiple objects (e.g. all contacts that you placed for this purpose.) Or - even more convenient - you add one keyword (of your choice) to all these contacts. And select this keyword to define all objects that shall trigger this particular event. See, if this makes any sense to you so far. Ask, if somethings unclear. When we know that you've come to grips with this first step, we'll take the next one. And easy does it, Pete One step at a time. Goetz example layout: first steps for Pete.mbp

Small wonder, Pete. Your layout is way too big and loaded to use as a testing ground. What's more, you have way too many entries in your event manager. Some of them double and triple the same set of actions. That's not your fault, because previous versions of the 3D-Train Studio left you with little choice in that matter. But it's a great hinderance now when you're experimenting with different settings. Because you never know for sure, what other events may interfere with what you do. You'd be better off setting your large layout aside for a little while and building a plain oval with one signal on it and no decoration whatsoever. Use that for your experiments. That way, you can concentrate on understanding the V5 EM one element at a time. Step by step. And then, when you're familiar with your new tools, you may rethink your strategy for the Fairmont layout. note: I only just realised that Tom said the same thing. I missed his last sentence. Sorry! Kind regards Goetz

Und an dem Punkt bin ich raus. Das ist mir zu doof ... Es stimmt zwar, dass der Unterschied nicht auf einen Rundungsfehler zurückzuführen ist, sondern auf einen Zahlendreher in meiner Formel: Ich hatte 3536 anstelle von 3563 geschrieben. Aber deine Häme ist einfach daneben gewesen!

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.