tim-fischertechnik

Hi @Dad3353, I hope this example will help you. I have attached a small ZIP file with the blender files and the mbe model. In this ZIP file there are also the txt files for the labeling, which is very important. Without these txt files it will not work out. Make sure to use the same names for the txt files as for the texture files. neue Beschriftungssystem in V8.zip Kind regards, Tim

Hallo @Hawkeye, ich verstehe deinen Wunsch natürlich und deine Demo sieht schon toll aus. Aber wie schon Roter Brummer geschrieben hat, gibt es keine entsprechenden GBS-Elemente für die KS-Signale in der Realität. Dabei würde das neue Beschriftungsfeature hier seine Vorteile ausspielen, wenn man editierbare Beschriftungen für die beiden Geschwindigkeiten verwendet. Selbst bei einen herkömmlichen Gleisplanstellpult gibt es eigentlich keinen Hp2-Begriff, sondern nur eine grüne Leuchte für Hp1 und eine rote Leuchte für Hp0. Dann gibt es u. a noch den Sh1-Anzeiger. Der Fahrdienstleiter (Fdl) muss sich überhaupt nicht mit den Geschwindigkeiten herumschlagen, weil sie für das Fahrstellen von Fahrstraßen nicht von Relevanz sind. Der Triebfahrzeugführer hingegen muss sehr wohl die unterschiedlichen Geschwindigkeiten berücksichtigen. Wie du siehst, gibt es auch im MBS Kompromisse wo man geringfügig von der Realität abweicht. Du hattest ja in deiner Demo auch noch über eine kleine weiße Lampe oben signalisiert, dass das Mehrabschnittssignal im verkürzten Bremsabstand steht. Solche Informationen sind für den Fdl überhaupt nicht relevant und wären daher überflüssig. Ich verstehe aber auch, dass man im 3D-MBS sowohl Triebfahrzeugführer und Fdl zugleich sein möchte und daher die genaue Signalstellung auf einen Blick ablesen möchte. Brummi hat ja die KS-Signale erbaut und dort gab es unzählige Varianten (Vorsignale, Hauptsignale, Mehrabschnittssignale) und das wird hier nicht anders sein. Ich schau mal, ob sich da was machen lässt. Bestimmt bekomme ich das hin aber ich will ja auch keine falschen Hoffnungen wecken, wenn am Ende der Baustein überhaupt nicht in den Katalog gelangt. Momentan wichtiger wäre es m. M. n., andere GBS-Bausteine wie einen GBS-Baustein mit editierbarer Zugnummeranzeige zu bauen oder allgemein gesagt, alle bestehenden GBS-Elemente, die sich sinnvoll um eine editierbare Beschriftung umrüsten ließen, zu überarbeiten. Ich spreche bei Gelegenheit mit Bahnland darüber, was am dringendsten in punkto GBS gemacht werden müsste. Viele Grüße Tim

Sodele, damit ich mich voll und ganz auf die GBS-Bausteine konzentrieren kann, möchte ich das Ergebnis meines Gittermast-Bogenleuchten-Projekts präsentieren, das nun endlich fertig geworden ist. Es ist noch eine zusätzliche Variation (Bogenleuchte 3) in der Ausführung mit einem Holzmast hinzugekommen und zusätzlich habe ich noch diverse Aufsätze dem Modell als Variationen beigefügt, sodass man diese flexibel in der Anlage einsetzen kann. Die Variationen (Bogenleuchte 2a und 2b) haben Andockpunkte, an denen sich die Stromleitung andocken lässt. Wenn die Lampe in die falsche Richtung zeigt, wählt man die andere Variation von diesen beiden Variationen aus, weil dort der Kontaktpunkt um genau 180° gedreht ist. Diese Stromleitungen werden als eigenständiges Modell veröffentlicht. als Entwurf unter V8 veröffentlicht: Gittermast-Bogenleuchte: 98A99802-A27A-4B0B-BCF6-223812F5FDBE Leitungen Bogenleuchte: CA66785E-A530-4BB8-948E-DE0BCC77888E Ich hoffe, das euch die neuen Variationen gefallen und ich würde euch um einen letzten finalen Test bitten, da man immer irgendwie was übersieht und es bei einem selbst nicht auffällt. Viele Grüße Tim

Hallo @Hawkeye, ich hatte ganz vergessen zu schreiben, dass ich den Vr2-Begriff ausschließlich auf das GBS-Element bezogen hatte, weil es auf jeden Fall den Vr2-Begriff in der Realität gibt. Trotzdem danke für den Link. Ich hatte irgendwo mal gelesen, dass auf so einem Gleisbildstellpult überhaupt keine Langsamfahrt-Begriffe angezeigt werden, weil es für den Fahrdienstleiter keine Relevanz hat. Er muss nur wissen, ob ein Zug fährt oder nicht aber nicht wie schnell. Von daher gehe ich davon aus, dass es kein GBS-Vorsignal mit Vr2-Begriff gibt. Trotzdem denke ich, dass es kein allzu zu großer Stilbruch ist, wenn man an diese Stelle mal vom Vorbild abweicht. Ok, du hast Recht. Die meisten werden das nicht tun. Ich stehe nur vor der Frage, ob ich die Signalstellungen von den Lichtvorsignalen mit den Signalstellungen der GBS-Vorsignale synchronisieren soll. D. h., dass diese eins zu eins übereinstimmen, damit man die Signale einfach miteinander verbinden kann, ohne die EV einsetzen zu müssen. Wenn die Anzahl der Signalstellungen zwischen Lichtsignal und GBS-Vorsignal unterschiedlich wäre, dann stimmen die Signalbilder nicht mehr überein, was wiederum Verwirrung stiftet. Dann würde der GBS-Baustein den Begriff Vr1 zeigen, obwohl das Lichtvorsignal den Begriff Vr0 (Zs1) zeigt. Es ist auch kein Problem für mich, nur ein Modell, statt den beiden Modellen anzubieten, das dann nur zwei Signalbegriffe (Vr0 und Vr1) ohne Vr0 mit Zs1 anzeigt. Viele Grüße Tim

Guten Abend zusammen! Besteht Interesse an GBS Vorsignal-Bausteinen? (vielleicht kann @Neo was dazu sagen) @h.w.stein-info hatte sich vor langer Zeit Vorsignale als GBS-Baustein gewünscht ... ... und das ist daraus geworden. Es gibt ja bereits Hauptsignale als GBS-Baustein und die Vorsignale wären eine passende Ergänzung dafür. Ich habe zwei Modelle erstellt, mit je zwei Variationen. Das eine Modell ist zweibegriffig (Vr0, Vr1) und das andere dreibegriffig (Vr0, Vr1, Vr2). Jedes Modell lässt sich an ein GBS-Hauptsignal über Kontaktpunkte andocken. Natürlich kann man das Vorsignal auch getrennt vom Hauptsignal auf dem GBS einbauen. Da das GBS-Hauptsperrsignal jedoch etwas größer ausfällt, habe ich eine zweite passende Variation jedem Modell hinzugefügt, damit der Abstand wieder passt. Bei dieser zweiten Version ist die obere linke Ecke nicht abgeschrägt, sondern spitz. Ihr werdet euch vielleicht wundern, dass sich die beiden gelben Lampen ganz unten befinden. Bei einem Vorsignal (nicht GBS-Vorsignal) befinden sie sich ja beide auf der linken Seite. Beim Vorsignal auf einem GBS verhält es sich halt genau umgekehrt. Ich bin auf ein paar Unklarheiten gestoßen: Habe ich das Signalbild Vr2 (ausschließlich für den GBS-Baustein) richtig umgesetzt, und gibt es das überhaupt in der Realität? Die Recherche dazu gestaltet sich zugegebenermaßen recht schwierig. U. a. findet man hier etwas: 2020 1.0 Preisliste Stelltisch 01.04.2020 Seite 27+28.xls (smf-modelle.de). Benötigt man die Signalstellung Vr0 mit Zs1? Bei den Lichtvorsignalen von Roter Brummer kommt nämlich diese Signalstellung genau vor. Ich habe mir jetzt ein nettes Gimmick ausgedacht. Die gelben Leuchten blinken und sollen somit auf die Signalstörung gesondert hinweisen. Gerne freue ich mich über Anregungen und Kritik. Die beiden Modelle habe ich unter folgenden IDs als Entwurf in der Version V8 veröffentlicht. zweibegriffiges GBS-Vorsignal: F661FF5C-09B2-457B-8902-D3AB2D878E8A dreibegriffiges GBS-Vorsignal: 75F15C9B-CD1C-43F8-93B8-87DE59F6F974 Viele Grüße Tim

Hallo zusammen, im Zuge der neuen Version V8 werden Modelle mit der neuen Beschriftungsfunktion unterstützt. Ich habe einem meiner Modelle, der Bü-Ankündigungstafel, nun eine editierbare Beschriftung verpasst, sodass man keine Tauschtexturen mehr benötigt. Zum Testen habe ich sicherheitshalber erstmal einen Entwurf unter einer anderen Content-ID: 6E9F3C8E-C84C-464B-BC85-3DD546D096AC veröffentlicht. @Neo, ich bin hellauf begeistert von diesem neuen Beschriftungs-Feature! Das ist eine enorme Arbeitserleichterung und man spart sich das lästige Hantieren mit Tauschtexturen. Gerne freue ich mich darüber, wenn jemand den Entwurf in V8 testet. Wenn ihr nichts zu beanstanden habt, überschreibe ich die alte Version unter der ursprünglichen Content-ID: B2AAC5BD-4338-45BC-99D9-11DCF2E88092. In V7 bleibt dann der alte Versionsbestand mit Tauschtextur bestehen und in V8 gibt es dann die neue Beschriftungsfunktion. Viele Grüße Tim

Hallo @dbahr, schönes Beispiel! Ich habe noch einen kleinen Verbesserungsvorschlag. Wenn mehrere Fahrzeuge direkt hintereinander auf der Straße in Richtung der Parkplätze fahren, dann werden mehreren Fahrzeugen dasselbe Ziel für die Parklücke zugewiesen. Entsprechend kommt es zu einer Blockade wie auf dem hier gezeigten Bild. Es wird sowohl dem ersten Fahrzeug (Pajero) als auch dem zweiten Fahrzeug (SUV 2) derselbe Parkplatz als Ziel (Parkplatz 4) zugewiesen! Das Problem liegt in der zeitlichen Reihenfolge, wann du den Parkplatz als belegt (Variable: frei = false) deklarierst. Momentan gilt der Parkplatzt erst dann belegt, wenn das Fahrzeug den Gleiskontakt mit dem Schlagwort Parkplatz betritt. In der Zwischenzeit betritt ein weiteres Fahrzeug jedoch den Gleiskontakt "Zufahrt Parkplatz" und der Parkplatz 4 wird irrtümlicherweise als frei deklariert, obwohl das erste Fahrzeug kurzerhand diese Position ansteuert und bald erreichen wird. Die Lösung des zeitlichen Problems besteht darin, dass du die Parkposition direkt als belegt deklarierst, nachdem dem Fahrzeug das Ziel zugewiesen wurde. Damit kannst du dir das zweite Ereignis "Kontakt Parkplatz wird betreten" sparen. Viele Grüße Tim

Hallo zusammen, hallo Brummi, ich habe jetzt dein Modell als eigenständiges Modell importiert und unter "CA66785E-A530-4BB8-948E-DE0BCC77888E" als Entwurf veröffentlicht. Nochmal herzlichen Dank dafür für deine Unterstützung. Liebe Grüße Tim

Danke dir. Das sieht klasse aus und funktioniert ausgezeichnet. Habe ich angelegt. Das ist eine gute Idee. Stimmt, wurde behoben. Die ganzen Änderungen habe ich in meinem ursprünglichen Entwurf: 98A99802-A27A-4B0B-BCF6-223812F5FDBE erneut aktualisiert. Ich hoffe, dass ich nichts übersehen habe. Liebe Grüße Tim

Hallo Brummi, Ja genau. Das Maß bezieht sich genau auf die Mittelpunkte der jeweiligen Leitungen und dementsprechend liegen die Mittelpunkte der Isolatoren auch 950mm auseinander. Ich hoffe, dass ich das: richtig verstanden habe. Für Test habe ich ein eigenständiges Modell unter der ID: 291588B9-DF5A-4DA5-A480-6305E823E1FC veröffentlicht und dort schon die Kontaktpunkte eingebaut. Hier habe ich die Höhe der Kontaktpunkte kenntlich gemacht. Der erste befindet sich in einer Höhe von z = 100335mm und der zweite liegt 750mm höher auf z = 11085mm. Liebe Grüße Tim

Hallo zusammen, heute möchte ich euch mal wieder einen kurzen Zwischenstand zum meinem Projekt geben. Wurde umgehend verbessert. Ich hoffe das passt so: Es war zwar verlockend mehrere Edges einer einzelnen Strebe mit nur einem Vertex zu verbinden, was natürlich die Polygonanzahl stark minimiert, aber rein statisch und optisch gesehen ist das nicht tragbar. Ich habe das Modell nochmal komplett neu texturiert und oberhalb der Lampe und an den Seilrollenkästen Rostflecken angedeutet. Wenn es euch nicht zusagt, kann ich das auch wieder rückgängig machen aber ich finde es ganz schön, weil man nebenbei die Konturen besser hervorhebt. Dann gibt es noch eine zusätzliche Variation mit Isolatoren. Erst dachte ich mir, dass es sich hierbei um Telegrafenleitungen handeln müsste. Da es aber genau vier Leitungen sind, wird es wohl eher eine stinknormale Stromversorgung (1. Phase, 2. Phase, 3. Phase, Neutralleiter) sein. Ich habe jetzt mehrere einzelne Telegrafenmastleitungen (17815B07-3A6D-428F-BC1E-E3D16F0ECB3D) für den hier dargestellten Aufbau verwendet. Schöner wäre es, wenn man dafür Splines verwendet. @Roter Brummer: Ich habe daher einen Wunsch an dich. Würdest du eventuell deine Streckentelegraf Leitungen (34D64765-3841-4C4B-BB45-3B76874D8A47) um eine weitere Variation ergänzen oder wenn es mehr Sinn ergibt, ein eigenständiges Modell daraus bauen? Konkret habe ich mir das so vorgestellt: Ich habe die Maße deiner Telegrafenleitung ermittelt und die Abstände einfach übernommen. Dann könnte man von den 6 Leitungen 4 hinauskürzen, sodass man am Ende nur noch zwei hat. Vorschläge zur Aufteilung: Aufteilung 1: 4 Leitungen in einem Modell (Variation) Aufteilung 2: 2 Modelle je 2 Leitungen (oben und unten) Alles Weitere könnten wir ja über PN besprechen. Liebe Grüße Tim

Hallo liebe Community, nach mehreren Versuchen und bestimmt 10 Modifieren konnte ich den Mast verjüngen. Allerdings störte mich die hohe Polygon-Anzahl. Dank der Hilfe von Brummi konnte ich nun einen Polygon ärmeren Gittermast modellieren. Das Modell habe ich erneut aktualisiert. Dem Modell habe ich eine zweite, Polygon ärmere Version hinzugefügt. Ich hoffe, dass der Unterschied zur Version mit weniger Polygonen in Ordnung ist und nicht so sehr ins Gewicht fällt. Liebe Grüße Tim

Hallo zusammen, heute gibt es einen kleinen Vorgeschmack zu einer alten historischen Rundleuchte. Diese findet man im Vorbild häufiger an alten Betriebsstellen und da diese Art von Rundleuchten an einem Gittermast im Katalog noch nicht vorhanden ist, habe ich dieses Modell gebastelt. Das Modell kann als Entwurf unter der Content-ID: 98A99802-A27A-4B0B-BCF6-223812F5FDBE begutachtet werden. Modell als Signal [Signalbegriff: 0 - Licht aus / Signalbegriff: 1 - Licht an] angedeuteter Seilzug mit Umlenkrollen und Handkurbel Ich überlege mir noch, ob ich die Handkurbel mit samt Seilzug noch animiere. Die Leuchte stammt noch aus der Zeit, wo man Petroleumlampen verwendet hatte. Damit man diese besser warten konnte, hatte man die Lampe mit einem Seilzug versehen, um diese absenken zu können. Leider weiß ich nur nicht, an welcher Stelle genau die Lampe vom Träger getrennt ist. Ich vermute folgenden Aufbau: Falls jemand Hinweise hinsichtlich der genauen Funktionsweise von Gittermastleuchten mit Seilzügen hat, freue ich mich sehr. Soll ich die beiden Versionen in der untenstehenden PDF-Datei auch noch bauen? Vorschläge -zusätzliche Versionen für Rundleuchte_Gittermastleuchte.pdf Viele Grüße Tim

Hallo @Markus4.1, benenne mal bitte in all deinen Gleiskontakten am Bahnsteigende die Variable "linke Bahnsteigseite" in "Ausstieg in Fahrtrichtung links" um. Ich Dussel hatte vergessen, dich nochmal explizit darauf hinzuweisen, dass ich ab Version 2 des dritten Lösungsvorschlages diese Variable umbenannt hatte. Im Ereignis "Bahnsteigs - Gleiskontakt betreten --> relative Fahrtrichtung bestimmen/ Fahrtrichtungsumkehr" solltest du alles bis zum Kommentar "Fahrtrichtungsumkehr herauslöschen. Dieser Teil der manuellen relativen Fahrtrichtungsbestimmung wird nicht mehr benötigt, da im anderen Ereignis "Bahnsteigs - Gleiskontakt wird betreten bei der Einfahrt --> Türen öffnen" dies schon von dem Lua-Skript-Baustein übernommen wird, der die relative Fahrtrichtung vollautomatisch bestimmt. Dann müsste alles richtig funktionieren. Viele Grüße Tim

Ja, mein Lua-Skript aus Version 4b ist sogar in der Lage, die Position/Richtung sowohl von Loks als auch von Wagen in einem Zugverbund zu bestimmen und zwar vollautomatisch. Der Erstentwurf funktionierte zuerst nur bei Zügen mit maximal zwei Loks richtig. Diese durften auch nur an den Zugenden platziert sein. In meinem modifizierten Skript werden beliebig viele Züge [Auslöser] berücksichtig, die sich auch an beliebig vielen Stellen, also auch mittig im Zug, befinden können. Die Bilder dienten zur Veranschaulichung der manuellen Konfiguration für die Version 4a und da die anderen beiden Fälle dem Standardverhalten entsprachen, habe ich sie nicht nochmal aufgeführt. Mir war es immer zu mühselig, die Ausrichtung von jedem einzelnen Wagon zu prüfen und dann händisch in Form von Variablen einzutragen. Man kann also Wagen einfach auf die Platte ziehen und muss sich keine Gedanken über eine richtige Ausrichtung machen. Lediglich die beiden Animationsnamen der Türen für links/rechts müssen in einer Tabelle eingetragen werden. Bei meinem Skript nehme ich mir die Kupplungsbelegungen zur Hilfe, um die relative Ausrichtung im ersten Schritt zu bestimmen. Du hattest ja auch schon ein paar erste Tests mit Kupplungsbelegungen gemacht. Ist schon eine tolle Sache! Im zweiten Schritt wird die Ausrichtung/Position auf die Fahrtrichtung gemünzt. Wenn die Ausrichtung eines Wagons identisch zur Ausrichtung der auslösenden Lok ist, wird die Fahrtrichtung des Auslösers übernommen, andernfalls umgekehrt. Beim Stöbern einiger Beiträge bin ich auf diesen Beitrag gestoßen. Interessant ... Ich muss schmunzeln, da die Türsteuerung über fast gleiche Grundkonzepte verfügt. Beispielsweise bestimmst du die Türseite auch über die Fahrtrichtung oder du hast ja auch eine Fahrtrichtungsumkehr, indem du die Zug Geschwindigkeit mit der Zug Ausfahrtrichtung multiplizierst. Natürlich hat da jeder seine eigene Struktur. Ob man jetzt die Ausstiegseite "BahnsteigSeite==links/rechts" [Hawkeye] oder "Ausstieg in Fahrtrichtung rechts == "true/false" [Tim] nennt, ist völlig egal. Vielleicht kannst du ja etwas von der automatischen Fahrtrichtungsbestimmung adaptieren und ich schaue mal, ob ich noch ein Gimmick von dir verwenden kann. Beim Erstellen meines Tutorials wollte ich es vermeiden, Lua einzusetzen und stattdessen den Schwerpunkt auf die grafische EV legen. Und ich muss sagen, ich bin kläglich gescheitert. An zwei Stellen in der EV bin ich um Lua nicht herumgekommen. Es ist also eine ganz schöne Herausforderung, einen Kompromiss zwischen komplexen realistischen Betriebssituationen, die sich nur gut über Lua abbilden lassen und Verständlichkeit auf der anderen Seite mittels überschaubarer grafischer EV, zu finden. Viele Grüße Tim

Hallo @neuLich, du hattest in einer deiner Beispielanlagen gezeigt, wie man eine Spitzenbeleuchtung entsprechend der Fahrtrichtung für genau eine Zuggattung umsetzen kann. Ich habe mich dem Wunsch angenommen und eine generische Spitzenbeleuchtung für alle Zuggattungen entworfen. Funktionsbeschreibung: Die meisten Aktionen habe ich mit Kommentaren versehen. Dennoch möchte ich hier kurz darauf eingehen, wie das allgemeine Prinzip hinter der Spitzenbeleuchtung funktioniert. Wann müssen überhaupt die Spitzen- und Schlusslichter eines Zuges wechseln? Eigentlich nur dort, wo der Zug seine Fahrtrichtung umgekehrt, also in Kopfbahnhöfen. Deswegen prüfe ich zuerst, ob der Zug die Fahrtrichtung wechselt (Variable Fahrtrichtungsumkehr == True). Grafik 3/14: EV für Spitzenlichtbeleuchtung Dann werden alle vier Lichter (Spitzenlichter/ Schlusslichter, je vorne/ hinten) für jeden Wagon innerhalb des Zugverbunds ausgeschaltet. Zuvor wird geprüft, ob der Texteintrag und die Tabelle überhaupt existiert. Nicht jede Lok/ Wagon muss zwangsläufig zwei Spitzenlichter haben. Da kann dann mal das hintere Spitzenlicht fehlen. Nach einer kurzen Verzögerung von 0,5 Sekunden werden die Lichten unter bestimmten Kriterien eingeschaltet. Ein Licht wird nur eingeschaltet, wenn die Kupplung auf derselbe Seite wie das Licht frei ist, d.h. nicht mit anderen Wagen gekuppelt. Die Fahrtrichtung entscheidet über die Farbe (weißes Spitzenlicht oder rotes Schlusslicht). Wagen, die mitten im Zugverbund eingereiht sind: Beide Kupplungen sind belegt, weswegen überhaupt kein Licht eingeschaltet wird. Wagen am Zugende: Hierbei ist eine Kupplung frei und ein Licht wird eingeschaltet. Loks ohne Wagen: Hierbei sind beide Kupplungen frei. Folglich werden zwei Lichter eingeschaltet. Ein konkretes Beispiel: Grafik 3/15: Beispiel hintere rote Schlusslicht wird eingeschaltet Die Diesellok DB 212 fährt mit drei Umbauwagen mit negativer Geschwindigkeit (hintere Kupplung zeigt Richtung Prellbock) in das Stumpfgleis ein. Hierbei ist die hintere Kupplung frei und die hiergezeigte Bedingung ist erfüllt. Das weiße Spitzenlicht wird zuvor in dem oben beschriebenen Teil ausgeschaltet und nach einer kurzen Verzögerung leuchtet das rote Schlusslichte auf. Konfigurierung: Grafik 3/16: Konfigurierung der Namen für Spitzen- und Schlusslicht Anbei die 5. Version: 3. Lösungsvorschlag - Version 5.mbp fertig. Das Tutorial ist zu Ende. Viele Grüße Tim

Danke Götz, das hilft mir weiter. Nun weiß ich beruhigt, woran es lag. Die Variable "positive Fahrtrichtungsumkehr" wird ja vom Lua-Skript bereitgestellt und dann in der grafischen EV ausgelesen. Meine Tests mit der EV-Protokollierung ergaben, dass die Fahrtrichtung schon ausgelesen wurde, ehe sie durch das Lua-Skript verändert wurde. Das ergab dann natürlich immer eine fehlerhafte Fahrtrichtung. Jetzt habe ich natürlich den Lua-Skript-Baustein ganz nach oben über die eh schon vorhandene Verzögerung gezogen. Das fehlerhafte Verhalten lässt sich also in der beigeführten Anlage nicht mehr nachvollziehen, weil ich es zuvor schon behoben hatte. Viele Grüße Tim

Ja, sowohl Version 4a als auch Version 4b behandeln die Türsteuerung. Es geht hierbei konkret darum, dass die beiden Loks eines Zuges auch in die entgegengesetzte Richtung mit ihrer "Schnauze" zeigen können und es dann nicht zu Fehlern kommen sollte. Die Version 4a setzt diese Fehlerbehebung komplett grafisch um, während die Version 4b diese mittels Lua-Skript umsetzt und darüber hinaus hoffentlich viel anwendungsfreundlicher ist. Hierbei muss keine händische Konfiguration vorgenommen werden. Alles läuft automatisch ab. relative Fahrtrichtung bestimmen - Lua-Skript-Baustein: Grafik 3/13: Lua-Skript-Baustein / Reihenfolge der Aktionen - sequenzielle Abfolge Der Lua-Skript Baustein, der hier im obigen Bild zu sehen ist, übernimmt dieselbe Aufgabe wie die EV-Erweiterung im vorherigen Beitrag. Mit dem Baustein wird nämlich die relative Fahrtrichtung eines kompletten Zuges automatisch bestimmt. Der Vorteil dabei ist, dass: die Objektvariablen "andererTriebkopf" bzw. "andere Triebkopf" nicht mehr benötigt werden. man die Konfigurierung der Ausrichtung mittels des Schlagworts "gedreht" nicht mehr händisch vornehmen muss. Dies geschieht jetzt automatisch in Form der Variablen "Ausrichtung". man sich Frust und Ärger vermeidet, wenn die händische Konfigurierung nicht so richtig funktionieren will. Für alle Interessierten gibt es einen Vorher-nachher-Vergleich meines Lua-Skripts. Erstentwurf: Allein die Bestimmung der relativen Fahrtrichtung beinhaltet in etwa 105-Lua-Codezeilen. Der größte Teil an Kommentaren ist davon ausgenommen. verbesserte Version: function orientationOfNextWagon(_wagon, _nextWagon) -- Funktion prüft, ob der nächste Wagon im Zugverbund im Bezug auf den aktuellen Wagon in die gleiche oder entgegengesetzte Richtung zeigt if _nextWagon.couplers[0].connectedCoupler ~= nil then -- vK ist gekuppelt if _nextWagon.couplers[0].connectedCoupler.vehicle == _wagon then return 1 end end if _nextWagon.couplers[1].connectedCoupler ~= nil then -- hK ist gekuppelt if _nextWagon.couplers[1].connectedCoupler.vehicle == _wagon then return 0 end end end local t = layout:getVehicleGroup(vehicle) -- Zugverbund vK = t[1].couplers[0].connectedCoupler -- vordere Kupplung hK = t[1].couplers[1].connectedCoupler -- hintere Kupplung if vK ~= nil then t[1].variables["Ausrichtung"] = 0 --> vordere Kupplung [1. Wagon im Zugverbund] belegt else t[1].variables["Ausrichtung"] = 1 --> hintere Kupplung [1. Wagon im Zugverbund] belegt end for i, wagon in ipairs(t) do if i >= #t then print("ABBRUCH DER SCHLEIFE: Ab "..#t..". Position ("..t[#t].name..") sind keine zu bestimmenden Wagen vorhanden") break end nextWagon = t[i+1] nextWagon.variables["Ausrichtung"] = orientationOfNextWagon(wagon, nextWagon) end if vehicle.currentSpeed > 0 then -- Geschwindigkeitsbestimmung des Auslösers [Triebfahrzeug] posGeschwindigkeit = true else posGeschwindigkeit = false end for k, v in ipairs(t) do -- Fahrtrichtung für alle Wagen im Zugvebund bestimmen (Fahrtrichtung bezieht sich auf dei Fahrtrichtung des Auslösers!) if v.variables["Ausrichtung"] == vehicle.variables["Ausrichtung"] then v.variables["positive Fahrtrichtung"] = posGeschwindigkeit -- übernehme Fahrtrichtung bei gleicher Ausrichtung else v.variables["positive Fahrtrichtung"] = not posGeschwindigkeit -- drehe Fahrtrichtung um bei entgegengesetzter Ausrichtung end end Hier seht ihr meinen modifizierten Code, der aus insgesamt 46 Zeilen besteht. Ich habe nur eine Bitte. Versucht erst gar nicht, den Code zu verstehen, wenn ihr nicht Lua lernen wollt! Wichtig ist eigentlich nur, was so ein Baustein ausspuckt! Der Lua-Skript-Baustein funktioniert wie eine Schnittstelle und überträgt in diesem Falle eine Variable "positive Fahrtrichtung". Auf diese Variable kann nämlich später die grafische EV zurückgreifen. Ich freue mich wie immer über Anregungen unserer Lua-Experten, wenn man den Code noch schlanker machen könnte. Dann habe ich eine Frage an euch. Welche der Versionen sagt euch mehr zu? Die mit oder ohne dem Lua-Skript-Baustein? Markus hatte ja geschrieben, dass derzeit seine Türsteuerung nicht funktioniert, was vermutlich an der äußert komplizierten Konfigurierung (Version 4a ohne Lua-Skript-Baustein) liegt. ... und eine Frage an @Goetz. In der obigen Grafik habe ich eine Randbemerkung geschrieben. An der markierten Stelle wollte ich eigentlich zuerst den Skript-Baustein einfügen, doch dann traten undefinierte Zustände auf. Der ICE zum Beispiel öffnete bei jeder zweiten Runde die Türen auf der falschen Seite. Nun habe ich das natürlich verbessert, sodass sich die Türen auf der richtigen Seite öffnen. Abhilfe schafft dann immer eine nachgestellte Verzögerung. Gibt es eine Faustregel, wann man eine Verzögerung nach einem Lua Skript benötigt und wann nicht? Nach meinem Verständnis werden ja alle Ereignisse von oben nach unten (sequenziell) abgearbeitet. Anbei die Version 4b: 3. Lösungsvorschlag - Version 4b.mbp Viele Grüße Tim

Hallo zusammen, im Folgenden möchte ich euch Lösungsvorschläge für dieses Problem aufzeigen. Dazu werde ich im ersten Beitrag eine Lösung ohne Lua und im zweiten eine Lösung mit Lua präsentieren. relative Fahrtrichtung bestimmen - Lösung ohne Lua: Grafik 3/10: Erweiterung für relative Fahrtrichtungsbestimmung Beschreibung der EV: Zuerst wird in der mehrfachen Bedingung geprüft, ob: im Auslöser eine Objektvariable mit dem Namen "anderer Triebkopf" existiert. der andere Triebkopf als Wert in dieser Objektvariablen eingetragen ist. Das Objekt soll ja nicht leer sein. im Gleiskontakt die Variable Fahrtrichtungsumkehr wirklich true ist. Wenn alle dieser 3-Bedingungen erfüllt sind (UND-Logik), wird geschaut, ob der gegenüberliegende Triebkopf gleich oder umgekehrt zum Auslöser positioniert ist. Schlagwort "gedreht" vorhanden: → Der andere Triebkopf (nicht der Auslöser) zeigt in die entgegengesetzte Richtung wie das auslösende Triebfahrzeug. Bei einer Fahrtrichtungsumkehr in Kopfbahnhöfen etc. muss die die Ausrichtung (in Form des Schlagworts: "gedreht) aller Wagen umgekehrt werden, da jetzt nun die andere Lok wieder aus dem Bahnhof fährt, und zwar mit entgegengesetzter Geschwindigkeit wie die auslösende Lok zuvor. Grafik 3/11: entgegengesetzte Ausrichtung zweier Loks Schlagwort "gedreht" fehlend: → Der andere Triebkopf (nicht der Auslöser) zeigt in die gleiche Richtung wie das auslösende Triebfahrzeug. Alles bleibt wie beim Alten. Die auslösende Lok fährt in die gleiche Fahrtrichtung weiter weswegen die Ausrichtung aller Wagen beibehalten wird und nichts Weiteres in der EV unternommen werden muss. Wie die Ausrichtung im Zugverbund umgekehrt wird! Für jeden Wagon (auch Lok) wird die Ausrichtung umgekehrt: Wenn zuvor das Schlagwort "gedreht" in einem Wagon vorhanden war, wird es gelöscht. Wenn das Schlagwort "gedreht" zuvor gefehlt hat, wird es nun vergeben. Konfiguration des Schlagworts "gedreht": Wenn man einen neuen Zug anlegt, geht man am besten anhand folgender Schritte vor. Grafik 3/12: Konfigurierung Schlagwort gedreht Suche im Zugverbund eine Lok aus, die später losfahren soll. Wenn die vordere Kupplung dieser Lok in Fahrtrichtung zeigt, dann lösche das Schlagwort "gedreht", falls schon vergeben. Wenn die hintere Kupplung dieser Lok in Fahrtrichtung zeigt, dann vergebe das Schlagwort "gedreht". Prüfe bei allen übrigen Wagen, ob diese in die gleiche oder in die entgegengesetzte Richtung wie die ausgewählte Lok zeigen. gleiche Ausrichtung: Schlagwort löschen entgegengesetzte Richtung: Schlagwort vergeben Diesmal stelle ich neben der großen Beispielanlage auch eine kleine Mini-Demo ein, die sich auf das Wesentliche beschränkt. Die EV-Ergänzung aus der Mini-Demo wurde auf die größere Beispielanlage eins zu eins übertragen : MINI-Demo für 3. Lösungsvorschlag - Version 4a.mbp 3. Lösungsvorschlag - Version 4a.mbp Viele Grüße Tim Fortsetzung folgt in Kürze

Hallo @Roter Brummer, Ist das Einfahren des letzten Wagons in das blaue Depot in der hier gezeigten Anlage (veröffentlicht als Entwurf: 16B3A6D4-B039-42C5-A9A1-3889D1DEBDF3) besser? Ich habe folgende Änderungen vorgenommen: Die Kupplungen werden im Ereignis "Einfahrt Depot blau" nicht mehr aktiviert, sondern deaktiviert. Dafür werden die Kupplungen aktiviert, wenn der GK "Gleiskontakt Zugende" betreten wird. Wenn der Zug zu lange ist (besteht zufällig aus vielen längeren Wagons), werden Wagons über das "Zugende" hinaus nicht angekuppelt. Zusätzlich wird hier die automatische Verzögerung ausschließlich bei Wagen deaktiviert, sodass diese nicht mehr sanft, sondern zügig ankuppeln. Ich bin auch ratlos, warum der letzte Wagen so "ruppig" abgebremst wird und dann ziemlich allein gelassen wird. Aber so funktioniert es wenigstens. Liebe Grüße Tim

Hallo @rothie65, soweit wie ich erkennen kann, benutzt du die Version V3. Dabei kann es öfters zu Internetproblemen kommen, weil eine bestimmte Datei veraltet ist, wie in einem Beitrag von Neo beschrieben. Dort wird geraten, eine Datei "ServiceAPI.zip"als Zip zu downloaden und die alte Datei durch die neue zu ersetzen. Vielleicht ist das ein Versuch wert. Viele Grüße Tim

Hallo @Trainfan, eigentlich wollte ich dir eine persönliche Nachricht (PN) schreiben. Aus irgendeinem Grund kannst du keine PN empfangen. Daher hier meine gekürzte/zensierte Fassung. Wenn das mit der PN nicht klappt, kannst du natürlich weiterhin über das Forum schreiben oder wende dich bei Problemen am besten an Neo. Viele Grüße Tim

Hallo zusammen, in diesem Beitrag zeige ich euch einen Lösungsweg für den oben genannten Fehler auf. Ich habe die EV an einigen Stellen aufgeräumt. Dabei sind folgende Änderungen vorgenommen worden: Die Bezeichnung einiger Ereignisse wurde zum besseren Verständnis geringfügig erweitert. Die Variable "Austieg in Fahrtrichtung links" wurde in "Ausstieg in Fahrtrichtung" korrigiert. Die Ermittlung der Ausstiegseite in Form der Variable "Ausstieg in Fahrtrichtung links" erfolgt nicht mehr über zwei Zuweisungen, sondern einer. Zuvor wurde die Aussiegseite vom Gleiskontakt auf das auslösende Fahrzeug übertragen und im Anschluss wurde im Ereignis: "Bahnsteigs-Gleiskontakt wird betreten bei der Einfahrt --> Türen öffnen" als Auslöser das Fahrzeug verwendet, um die richtige Türseite zu ermitteln. Nun wird in diesem Ereignis direkt auf den Gleiskontakt als Auslöser zugegriffen. Die Zuweisung des Zugs und des Bahnsteig-Gleiskontakts zum Signal wurde in das Ereignis: "Bahnsteigs-Gleiskontakt betreten --> relative Fahrtrichtung bestimmen/ Fahrtrichtungsumkehr" verschoben. Die Überarbeitung der Fahrtrichtungsumkehr, die ich im Folgenden vorstellen werden. Um die Änderungen zwischen dieser und der vorherigen Version nachvollzuziehen, empfehle ich die beiden EV-Einträge miteinander zu vergleichen. Wie mit der neuen Fahrtrichtungsumkehr auch Züge mit nur einer Lok richtig umkehren: Grafik 3/8: EV für die Fahrtrichtungsumkehr Überall dort, wo eine Aktion nummeriert wurde, befindet sich ein Lua-Skript. Leider sind wir an dieser Stelle an einem Punkt angekommen, wo sich der Einsatz von Lua nur schwer vermeiden lässt, weil sich nur durch Lua der EV-Umfang begrenzen lässt. Ich werde dann immer den passenden Code hier einstellen. Für die Ermittlung des gegenüberliegenden Triebkopfs am anderen Zugende wird nicht mehr die Variable "andere Triebkopf" benötigt, sondern die Bestimmung erfolgt automatisch mithilfe des ersten Lua-Skripts. -- Lua Skript Nr. 1 local t = layout:getVehicleGroup(vehicle,1) -- 1 bedeutet: filtere alle Fahrzeuge in einem Zug mit einem Antrieb -- ermittle gegenüberliegenden Triebkopf im Zugverbund if t[1] == vehicle then andererTriebkopf = t[#t] -- letzte Element/ letzter Wagon else andererTriebkopf = t[1] -- erste Element/ erster Wagon end Dabei werden zunächst alle Fahrzeuge mit einem Antrieb aus dem Zugverbund einer Tabelle t zugeordnet. Wenn das erste Element/ erster Wagon der Tabelle t[1] gleichzeitig das auslösende Fahrzeug (vehicle) ist, wird das letzte Element/ letzter Wagon t[#t] aus der Tabelle der Variablen andererTriebkopf zugeordnet, andernfalls das erste Element. Die Raute # in Lua ermittelt immer die Anzahl an Elementen einer Tabelle. Somit kann mit t[#t] immer auf das letzte Elemente einer Tabelle zugegriffen werden, egal wie viele Elemente die Tabelle besitzt. Mithilfe der Bedingung Fahrzeug steht auf einem Gleiskontakt wird ermittelt, ob der Auslöser den Zug zieht oder schiebt. Ein Auslöser zieht immer einen Zug, wenn das Fahrzeug [Auslöser] gleichzeitig auf dem Gleiskontakt [Auslöser] steht und ein Auslöser schiebt einen Zug, wenn er selbst nicht auf dem Gleiskontakt steht. Wenn also der Auslöser den Zug schiebt und die Variable "Fahrtrichtungsumkehr" wahr ist, dann wird der Antrieb des Auslösers deaktiviert und dafür der Antrieb des gegenüberliegenden Antriebs aktiviert. (Der Auslöser zeigt in diesem Fall ja in Richtung Prellbock und soll bei der Abfahrt nicht angetrieben werden). -- Lua Skript Nr. 2 print("Auslöser ("..vehicle.name..") zieht Zug") Hier wird das auslösende Fahrzeug, welches den Zug zieht, in der EV-Protokollierung ausgegeben. -- Lua Skript Nr. 3 local v = andererTriebkopf -- gegenüberliegende Triebkopf if v:hasEngine() then v.engine.active = true -- aktiviere Antrieb vom gegenüberliegenden Triebkopf end Das Skript wurde fast vollständig aus der Aktion "Antrieb ausschalten/einschalten" durch Umwandeln extrahiert. Die einzige Veränderung besteht in der ersten Zeile, bei der die Variable andererTriebkopf der Variable v zugeordnet wurde. Die Variable andererTriebkopf kennen wir ja schon vom ersten Skript. Wenn der Auslöser den Zug schiebt, wird der Antrieb vom gegenüberliegenden Triebkopf zuerst deaktiviert und im Anschluss daran der Auslöser zur Sicherheit nochmal aktiviert. Die Skripte 4 und 5 ähneln den beiden vorherigen sehr. -- Lua Skript Nr. 4 print("Auslöser ("..vehicle.name..") schiebt Zug") -- lediglich andere Bezeichnung 'schiebt' -- Lua Skript Nr. 5 local v = andererTriebkopf if v:hasEngine() then v.engine.active = false -- deaktiviere Antrieb vom gegenüberliegenden Triebkopf end False deaktiviert in diesem Fall den Antrieb. Grafik 3/9: EV-Fahrtrichtungsumkehr für das Anfahren Im Ereignis "Wenn das KS Hauptsignal schaltet --> Türen schließen" werden ausschließlich nur alle Fahrzeuge mit aktiven Antrieb in einer Wiederholung angesprochen! Das habe ich so bewusst gewählt, da ich ja zuvor die Antriebe deaktiviere und aktiviere und somit sicherstelle, dass immer nur ein Antrieb aktiviert ist. Wenn der Zug beispielsweiße in einem Kopfbahnhof die Fahrtrichtung umkehren soll (Fahrtrichtungsumkehr = True), dann wird allen Fahrzeugen mit aktivem Antrieb eine negative Geschwindigkeit relativ zur Fahrtrichtung vergeben, andernfalls eine positive Geschwindigkeit. Anbei die dritte Version: 3. Lösungsvorschlag - Version 3.mbp Viel Spaß damit. Viele Grüße Tim

Ja, dem schließe ich mich auch an und freue mich schon auf das Modell. (Wer schaut schon schräg von dieser Perspektive? Da kann man doch gar nicht richtig die Skala erkennen ). Viele Grüße Tim

Edit: einziger Kritikpunkt/Verbesserungsvorschlag Von der Draufsicht aus gesehen hat eine Polygonfläche (Viereckfläche bestehend aus zwei/mehreren Dreiecken) einen Knick, sodass ein Dreieck sichtbar wird. (ziemlich vernachlässigbar/fällt kaum auf) Liebe Grüße Tim