tim-fischertechnik

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

Geschwindigkeitsprüfung (bei allen Variationen schlägt der Regler bis zum eingestellten Geschwindigkeitsbereich [auch negativer Bereich] richtig bis zum Anschlag aus und verharrt bei Überschreitung) bestanden! Die Kanten sind viel weicher und sehen dadurch realistischer aus. Die Buchsen haben mehr Tiefenschärfe Das neue Modell ist polygonarmer. Benutzerfreundlicher durch die variablen Geschwindigkeitsbereiche (Variationen). Meiner Meinung nach ist das neue Modell auf jeden Fall eine Bereicherung für den Katalog und übertrifft das alte Modell / kann das alte Modell ersetzen. Viele Grüße Tim

Hallo @Markus Meier, sind wir Modellbauer irgendjemand Rechenschaft schuldig, wann wir Auskunft über den Fortschritt von Modellen geben? Wir Modellbauer geben unser Bestes aber wie schon an vielen Stellen im Forum beschrieben, haben wir (nicht nur die Modellbauer) neben der Beschäftigung hier im MBS auch noch Familie, einen Job oder gehen zur Schule. Und das Projekt selbst kann sich ziemlich in die Länge ziehen. Das Modellieren an sich ist oft nicht am zeitintensivsten, jedoch das Aufsuchen von geeigneten Zeichnungen und Bildmaterial. In Projekten stößt man auf Unzulänglichkeiten, die man am Anfang nicht so in der Form bedacht hatte. (z.B.: komplizierte geometrische Stirnfronten an Triebköpfen, Änderungswünsche von Usern etc.). Bei mir dauert das Texturieren von Modellen fast genauso lang wie das Modellieren von Modellen. Ich bitte dich daher um Geduld! Reinhard wird hier schon ein Update geben, aber dann, wenn es ihm passt. Ich pflichte dir bei, dass klassisches Rollmaterial zum Beispiel Dieseltriebzüge wie die BR 614 nice to have sind. Aber wenn du unbedingt diese Modelle haben möchtest, könntest du selbst Eigeninitiative ergreifen oder den Modellbauern behilflich sein, indem du Geduld mitbringst und geeignete Zeichnungen zusendest. Ich würde gern auch einen Dieseltriebzug als Modell bauen, aber ich habe aufgrund der Schule schlicht nicht die Zeit für solche komplexen Modelle! Daher nenne ich jetzt auch nicht den Namen meines Favoriten. So baue ich eben "einfachere" Modelle der Bahnübergangstechnik und Beschilderungen. Siehe bitte auch hier: Modellwünsch Thomas Lokomotiven für V6 - Modellwünsche - 3D-Modellbahn Studio leicht genervte Grüße Tim

Hallo @Markus4.1, du hattest mich gefragt, ob es möglich ist, eine ganze Platte in seiner Höhe zu variieren, weil du noch einen weiteren Bahnhof "CityPark" anschließen möchtest, der aber im Bezug zum HBF etwas höher liegt. Ich nehme diesen Post zum Anlass, eine kleine spezifische Anleitung zum Verschieben von Platten zu erstellen (ich hoffe das ist so in Ordnung). Erst einmal muss ich dich loben, dass du die Objekte verschiedenen Ebenen zugeordnet hast. Das ist genau richtig so und du verschaffst dir eine enorme Arbeitserleichterung später beim Verschieben der Platten, da die Objekte vereinfacht gesagt durch Ausblenden von einzelnen Ebenen geschickt gruppiert werden können. Wie man eine bestehende Platte mit Inhalt in ihrer Höhe verschiebt (Mist ich habe vergessen, die Ebene am Anfang höher zu setzen): Im Folgenden werde ich anhand dieser Anlage (C8AF82DE-77C6-4374-A606-21AFE2B84927) von Markus die Platte, auf der sich die Drehscheibe befindet, höher setzten. Die Platte, auf der sich der HBF befindet bleibt unverändert. Vorrausetzung für das Verschieben einer Platte ist, dass du sämtliche Objekte einer, besser mehreren aussagekräftigen Ebenen zugeordnet hast! Wenn du nur eine Ebene für Gleise angelegt hast aber zwei Platten verwendest, musst du zwei Gleisebenen (z.B.: Ebene - Gleise HBF und Ebene - Gleise Betriebswerk) anlegen, weil du ja nur eine der Ebenen verschiebst. Die gleiche Prozedur gilt für alle andere Arten an Ebenen genauso. Blende alle Ebenen aus (durchgestrichenes Augensymbol), die du nicht auf deiner Platte haben/ gruppieren willst. Wenn eine Ebene nicht sichtbar ist, wird sie nicht ausgewählt! Achte beim Ausblenden von Ebenen auf besondere Objekte wie Bodenplattem, die standardmäßig fixiert/gesperrt sind und nur durch einen Doppelklick sonst anwählbar wären. Klicke auf die Pinnadel, um diese zu entsperren. Halte die linke Maustaste gedrückt und ziehe das Auswahlfenster über den gesamten Bereich der Platte. Dazu schaltet man am besten in die 2D-Ansicht. Gruppiere deine ausgewählten Objekte mit Strg + G und vergebe der Gruppe einen aussagekräftigen Namen. Verschiebe deine Gruppe in z-Richtung auf die gewünschte Höhe. Wenn du genau arbeiten möchtest, kannst du die Höhe in den Eigenschaften aufaddieren/berechnen lassen. Löse die Gruppierung mit Strg + U auf, um die einzelnen Objekte wieder bearbeiten zu können. Fertig! Wie man Ebenen gleich am Anfang höher legt : Lege eine neue Ebene an und weise ihr eine bestimmte Höhe zu. (siehe Wiki: Arbeiten mit Ebenen/Layern - Planung - 3D-Modellbahn Studio) Wähle eine Bodenplatte aus, um Gleise etc. auf die Platte zu ziehen und stelle sicher, dass du die richtige Ebene aktiviert hast, bei der die Höhenbeschränkung aktiviert ist. Aktiviere die automatische Höhenanpassung, damit sich Objekte entlang der Bodenplatte (verwende dazu die Option - Gelände) oder über anderen Objekten (verwende dazu die Option - Stapel) ausrichten. Erst wenn du mit der Höhe zufrieden bist, legst du weitere Ebenen mit derselben Höhenbeschränkung fest. (ggf. ist die Höhenbeschränkung unterschiedlich) Fertig! Liebe Grüße Tim

Wichtig ist, dass man in den Exporteinstellungen unter Inlcude das Kästchen "+ Y Up" setzt. Wenn man dies vergisst, werden die Achsen beim Export vertauscht. Die z-Achse in Blender entspricht dann nicht mehr der z-Achse im Studio. Hier noch weitere Einstellungen und eine Erklärung wofür das gut ist: speichert die letzten Exporteinstellungen ab, damit man diese nicht immer neu festlegen muss damit selektiert man nur Objekte mit der linken Maustaste oder mit der Tastenkombination "A" um alle Objekte auszuwählen. Das kann äußert praktisch sein, wenn man noch Hilfsmittel wie Zeichnungen als Objekte im Projekt hat und diese nicht mitexportieren will. die besagte Korrektur der Achsen In Blender gibt es sogenannte Modifier mit denen du Objekte manipulieren kannst. Beispielsweiße gibt es einen Mirror-Modifier zum Spiegeln. Damit diese beim Export und nicht nur in Blender angewendet werden, muss man das Kästchen (Punkt 4) aktivieren, wenn man von diesen Feature Gebrauch nimmt. Edit: Eigentlich sollte es nur ein Post geben und ich bin auf die Taste zum Abschicken des Posts aus Versehen gekommen. Jetzt weiß ich, dass es so eine Taste gibt. Liebe Grüße, Tim