BahnLand

Hallo Michael, am Besten liest Du Dir mal das Tutorial zu den Tunneldurchbrüchen in der Bodenplatte durch. Dort findest Du einige Informationen zu den prinzipiellen Eigenschaften der "Löcher" und Tipps, wie man diese möglichst eng um ein mögliches Tunnelportal begrenzt und anschließend geeignet "abdichtet". Einige Anwendingsbeispiele hierzu, die ich auf meiner Gotthard-Anlege realisiert habe, findest Du in diesem Beitrag. Die Gotthard-Anlage selbst ist im Online-Katalog in der Kategorie "Große Anlagen" unter dem Namen "Gotthard Nordrampe (in Betrieb)" zu finden. Ich denke, dass Du es mit diesen Hilfestellungen schaffst, Deine "Schluchten" auf einigermaßen passende Dunneldiurchbrüche zu reduzieren. Du kannst Dir auf der Gotthard-Anlage die Tunnel-Öffnungen (sprich "Löcher" in der Bodenplatte direkt ansehen, indem Du im Ansicht-Menü die Ebenen aktivierst und dann in der rechts angezeigten Ebenen-Übersicht die Ebene "Bauwerke Tunnelportale" ausblendest (zum Aus- und Einblenden auf das Auge klicken). Tunnelportale mit "echter" Öffnung (also ohne schwarze "Wand") und auch Tunnelröhren findest Du zuhauf im Online-Katalogverzeichnis Landschaft - Tunnel und in dem dort vorhandenen Unterverzeichnis Tunnel(CH).. Für das Setzen der Tunnelröhren entlang des Gleisverlaufs hat EASY eine "Tunnel-Setz-Maschine" gebaut, die Du im Modellbahn-Studio als Planungs-Plugin "Tunnel-Setzen" starten kannst. Viele Grüße BahnLand

Hallo Hans, die Darstellung deiner 6-stelligen Festzkommazahlen (4 Stellen vor und 2 Stellen hinter dem Dezimalpunkt) wäre ja so einfach, wenn die Berechnung einer 8-stelligen Festkommazahl (bis zu 5 Stellen vor und bis zu 3 Stellen hinter dem Deszimalpunkt) im Modellbahn-Studio ordentich funktionieren würde. Denn dann könnte man die Zahlen 0000,00 bis 9999,99 in diesem festen Ausgabeformat immer dadurch darstellen, dass man die Zahl "10000.001" hinzuaddiert und dann die gesamte Zahl so hinter einer Maske anordnet, dass die beiden Einsen vorne und hinten durch die Maske abgedeckt werden (siehe die beiden Zahlen im oberen Teil des nachfolgenden Bildes). Leider lassen sich solche Zahlen im Modellbahn-Studio nicht durch eine Berechnung herstellen. Weist man einer Variable den Wert "10000.001" oder eine andere Zahl dieses Formats (Nullen durch andere Ziffern ersetzt) direkt zu, wird die Zahl ordentlich angeommen und kann daher auch in einem Beschriftungsfeld korrekt angezeigt werden. Wird diese Zahl aber berechnet, indem man beispielsweise die oben beschriebene Summe aus dem eigentlich darzustellendem Wert und der Zahl "10000.001" bildet, geht beim Ergebnis die "1" ganz rechts durch Rundung verloren. Zum Test der hier beschriebenen Zahlen-Darstellungen füge ich die zugehörge Testanlage entsprechend dem obigen Bild bei: Festkommazahlen.mbp Mit dem Schalter des oberen Beispiels aus dem Bild kann man sich abwechslungsweise das korrekte Ausgabeformat (kompletter Wert wurde der Variable direkt zugewiesen) und das "verfälschte" Format (Anzeige des durch Berechnung entstandenen Variablenwerts) anzeigen lassen. Ersetzt man während der korrekten Anzeige den Wert im Beschriftungsfeld ganz oben durch einen anderen Wert der Form "1xyzw.uv1", wobei die Buchstaben u-z beliebige Ziffern darstellen sollen, kann man diesen Effekt auch bei diesen anderen Zahlen beobachten. Frage an Neo: Ist das ein Fehler im Modellbahn-Studio oder lassen sich solch große Festkomma-Werte im Windows grundsätzlich nicht berechnen? Nun könnte man einfach die Anzahl der anzuzeigenden Stellen (vor oder hinter dem Dezimalpunkt) um 1 reduzieren. Dann würde das Demonstrationsbeispiel in der oberen Bildhälfte funktionieren. Möchte man dagegen unbedingt die 4 Stellen vor dem Dezimalpunkt und die 2 Stellen dahinter behalten, muss man sich etwas anderes einfallen lassen: Ich habe hierzu im dem in der unteren Bildhälfte darhestellten Beispiel die 8-stellige Festkommazahl (einschließich der vorne und hinten hinzugefügten Einsen) in zwei Abschnitte aufgeteilt (siehe die weißen Beschriftungsfelder rechts oben. Hierdurch wird garantiert, dass der linke Zahlenteil aufgrund der hinzugefügten 1 in der 1000er-Stelle immer 4-stellig ist. Genauso garantiert die 1 ganz rechts im rechten Zahlenteil die konstante Angabe von 3 Stellen hinter dem Dezimalpunkt. Die Aufspaltung wird zwischen die erste und zweite Stelle vor dem Dezimalpunkt gelegt, weil die 1er-Stelle die einzige ist, die immer dargestellt wird. Um die beiden Zahlenteile bei der Anzeige wieder zu einer Zahl ohne trennenden Zwischenraum zusammenschieben zu können, muss der Hintergrund der Beschriftungsfelder transparent gemacht werden. Das hieraus resultierende Ergebnis sieht man schließlich in den grauen Rahmen, wobei jener rechts absichtlich etwas transparent gehalten wurde, um die verdeckten Einsen zu sehen. Damit die Ziffern innerhalb der dargestellten Zahl immer denselben Abstand haben und damit auch mimmer an derselben Stelle positioniert sind, hab ich eine Schrift mit konstantem Zeichenabstand gewählt. Mir bekannte zum Windows-Standard gehörende Schriften mit festem Zeichenabstand sind Courier New (obere Anzeige im Beispiel) und Lucida Console (untere Anzeige im Beispiel, im Windows vorhanden mindestens seit Version 7). Die Verwendung dieser Schriftarten macht die getrennte Darstellung der einzelnen Ziffern in verschiedenen Beschriftungsfeldern und damit den erhöhten Berechnungsaufwand bei einer Änderung des Werts der Gesamtzahl überflüssig. Da es im Modellbahn-Studio leider keine Textmanipulations-Funktionen für Variablen und auch keine Rundungs-Funktion gibt, musste ich ein paar kleine Tricks anwenden. Insbesondere benutze ich die oben beschriebene (eigentlich nicht gewollte) Zwangs-Rundung. Im Einzelnen habe ich die Variablen wie folgt manipuliert: Variablen: Wert = Ursprünglich darzustellender Zahlenwert Vorne = Vorderer Teil des Zahlenwerts ab der 10er-Stelle aufwärts Hinten = Hinterer Teil des Zahlenwerts, bestehend aus 1er-Stelle und den Dezimalziffern hinter dem Dezimalpunkt Berechnungs-Abfolge: Vorne = Wert / 10 (Verschiebung der 1er-Stelle hinter den Dezimalpunkt) Vorne = Vorne + 1000000 (Addition von 1000000 erzwingt das oben beschriebene fälschliche Abschneiden der Dezimalstellen. Hierbei wird in Abhängigkeit vom Dezimalwert auf- oder abgerundet.) Vorne = Vorne - 1000000 (Rücknahme der für das Erzwingen der Rundung benötigten Million) Vorne = Vorne * 10 (Wiederherstellung der korrekten Position des Dezimalpunkts. Der Wert unterscheidet sich nun vom Ursprungswert durch die Auf- oder Abrundung auf ein ganzzahliges Vielfaches von 10) Vorne = Vorne - 10, falls der gerundete Wert größer als der Ursprungswert ist (Um diese Aktion nur bedingt ausführen zu können, ist sie in einem separaten Countdown-Ablauf realisiert, die von der vorangehenden Aktion direkt angestoßen wird (Wartezeit = 0). Für den weiteren "gemeinsamen" Ablauf wird in beiden Aktionszweigen (für Bedingung erfüllt und nicht erfüllt) ein weiterer Countdown-Ablauf mit Wartezeit 0 angestoßen.) Hinten = Wert - Vorne (Die Variable "Hinten" enthält nun den Anteil "<10" des ursprünglichen Werts, die Variable "Vorne" den Rest.) Vorne = Vorne + 1000 (Darstellung der 10er-, 100er- und 1000er-Ziffer des ursprünglichen Werts werden erzwungen, die vorderste Ziffer wird bei der Darstelung durch die Maske verdeckt.) Hinten = Hinten + 0.001 (Darstellung von 2 Stellen hinter dem Dezimalpunkt wird erzwungen, 1er-Stelle vor dem Dezimalpunkt wird immer angezeigt, dritte Stelle hinter dem Dezimalpunkt wird bei der Darstelung durch die Maske verdeckt.) Durch das Zusammenfügen der beiden Beschriftungsfelder mit den Ausgaben der Variablen "Vorne" und "Hinten" und das Verdecken der ersten und letzten Ziffer der Gesamtzahl erhält man die Anzeige des ursprünglichen Werts schließlich im gewünschten Format "xxxx.xx", wobei auch führende und abschließende Nullen mit dargestellt werden. Wie die mit diesem Algorithmus hergestellte Darstellung schließlich aussieht, kann man sich im unteren Beispiel der beigefügten Demo anschauen, wobei die darzustellende Zahl über getrennte Schalter für jede Stelle hoch- (obere Schalterzeile) und heruntergezählt (untere Schalterzeile) werden kann. Beim Spielautomaten wird man dann anstelle der hier platzierten Ziffern-Schalter die berechnete 6.stellige Zahl (4 Stellen vor und 2 Stellen hinter dem Dezimalpunkt) direkt als Ursprungs-Variablen-Wert verwenden. Eine explizite Behandlung der einzelnen Ziffern ist somit nicht mehr erforderlich. Viele Grüße BahnLand

Hallo Lobo, eigentlich wird einem erst durch die hier gezeigten Anlagen-Präsentationen so richtig klar, wie fleißig Du in den letzten Wochen warst. Das komplette Dorf, bei dem die gesamte Modellvielfalt auf einen Blick zu sehen ist, und damit die Harmonie zwischen den einzelnen Gebäuden erst so richtig zu Geltung kommt, steigert den ohnehin schon positiven Eindruck der Einzelgebäude gewaltig. Das ist schon eine tolle Leistung, die Du da erbracht hast und noch weiter erbingst. Viele Grüße BahnLand

Hallo Brummi, auf jeden Fall ist es gut, dass Du Deine Variante hier veröffentlicht hast. Es könnte ja sein dass es auch bei anderen nicht so funktioniert wie ich es beschrieben habe. Welches Kriterium letztendlich dafür verantwortlich ist, welche Variante nun bei wem "die richtige" ist, werden wir wohl nie herausfinden. Jedenfalls vielen Dank für Deine Information. Viele Grüße BahnLand

Hallo Brummi, jetzt bin ich aber total verwirrt: Ich habe neben Sketchup V8 die beiden neuen Versionen Sketchup 2016 und Sketchup 2017 installiert. Daher gibt es bei mir im AppData-Bereich auch die beiden Verzeichnisse C:\Users\<username>\AppData\Roaming\SketchUp\SketchUp 2016\SketchUp\Plugins und C:\Users\<username>\AppData\Roaming\SketchUp\SketchUp 2017\SketchUp\Plugins. In beiden Verzeichnissen habe ich den DirectX-Exporter angelegt und kann daher den Exporter sowohl in Sketchup 2016 als auch in Sketchup 2017 aufrufen. Die beiden Verzeichnisse C:\Users\<username>\AppData\Roaming\SketchUp\SketchUp 2016\SketchUp\Tools und C:\Users\<username>\AppData\Roaming\SketchUp\SketchUp 2016\SketchUp\Tools gibt es bei mir dagegen nicht. Wenn ich dieses neu anlege und das Exporter-Script (die rb-Datei) dorthin verschiebe, ist beim erneuten Start von Stektchup der Menüpunkt "Erweiterungen" verschwunden. erst wenn ich die rb-Datei in das Plugins-Verzeichnis zurückschiebe, ist der Menüpunkt beim erneuten Statt von Sketchup wieder da, und ich kann den Exporter aufrufen. Ich habe nun auch das Prorammverzeichis von Sketchup 2016/2017 angeschaut und dort tatsächlich jeweils das Unterverzeichnis Tools gefunden: C:\Program Files\SketchUp\SketchUp 2016\Tools und C:\Program Files\SketchUp\SketchUp 2017\Tools. Dort sind auch eine Menge von Sketchup-Rupy-Scripts und die "StandardlLib" von Ruby abgelegt. Also habe ich versucht, auch den DirctX-Exporter dort mit hinein zu packen (geht allerdings nur mit Administrator-Berechtigung, da es sich bei dem Programme-Verzeichnisbaum um einen System-Verzeichnisbaum handelt). Wenn ich danach wieder die entsprechende Sketchp-Version starte, ist auch hier der DirectX-Exporter im Hauptmebü von Sketchup nicht sichtbar. Bei mir funktioniert also tatsächlich nur die Variante C:\Users\<username>\AppData\Roaming\SketchUp\SketchUp 2016\SketchUp\Plugins und C:\Users\<username>\AppData\Roaming\SketchUp\SketchUp 2017\SketchUp\Plugins. Was ist an Deinem System anders als bei meinem? Ich habe Windoes 10 Home (64 Bit, Version 1607) im Einsatz. Viele Grüße BahnLand

Hallo Hans, bei der Ereignisdefinition "Zug betritt Gleis" musst Du ja das Gleis explizit nennen. D.h. Du benötigst für jedes Gles, für das der zugehörige Wert ausgegeben werden soll, eine "Zug betritt Gleis"-Definition. Da Du allen Gleisen als Bezeichung die jeweils zu übergende Zahl zuweisen möchtest, ist die Feststellung dieses Werts dann ganz einfach: Beispiel: Zug betritt Gleis "40" --> Wert = $_Trigger2._Name Du könntest natürliich als Wert dann auch explizit Wert = 40 verwenden, da Du ja dieses Ereignis sowieso für jedes betroffene Gleisstück definieren musst. Da sich bei den vielen gleichartigen Ereignisdefinitionen jedoch das Kopieren anbietet, kommst Du mit der Verwendung von $_Trigger2._Name schneller voran. Den dann musst Du in jeder Ereignisdefinition das Gleis nur noch im "Ereignis" anpassen, während in der "Aktion" der Gleisname über die Variable $_Trigger2._Name automatisch erkannt wird. Beachte aber bitte, dass dann, wenn z.B. das Gleis "40" mehrmals existiert (mindestens 1mal in jedem Oval), Du auch die ERegnisdefinition für jedes dieser Gleise "40" separat bereitstellen musst (Du musst dann im "Ereignis" auch immer das "richtige" Gleis "40" auswählen). Eine andere Möglichkeit bestünde darin, alle Gleise nicht mit den Zahlenwerten als Namen zu versehen, sondern jeweils eindeutige Gleisnamen zuzuweisen. Und dann für jedes Gleis eine Objektvariable "Wert" zuzuweisen. Beispiel: Gleis xyz besitze die Objektvariable "xyz.Zahl" mit dem Inhalt "xyz.Zahl = 40". Dann würde die Ereignisdefinition wie folgt aussehen: Zug betritt Gleis "xyz" --> Wert = $_Trigger2.Zahl Vorteil gegenüber der ersten Variante: Die Eindeutigkeit der Gleis-Bezeichnungen macht es einfacher, alle Gleise zu berücksichtigen und nicht versehentlich eines zu übersehen. Viele Grüße BahnLand

Hallo Marko, ich hoffe, dass Du Dein originales Höhenfeld nur für die Präsentation hier im Forum in das JPG-Format umgwandelt und nicht versucht hast, dieses (wieder in BMP zurück konvertiert) auf die Bodenplatte zu bringen. Das JPG-Format macht nämlich alle "gleichmäßigen" Farbabstufungen durch die Komprimierung kaputt (verfranst das Bild künstlich, um so trotz Komprimierung das Bild fast wie das Original aussehen zu lassen). Ich habe Dein unteres Höhenfeldbold einmal auf eine Anlage importiert und das folgende Ergebnis aus der zurück konvertierten JPG-Datei bekommen: Füge mal Deinem Höhenfeld in den beiden gegenüberliegenden Ecken wie in dem unteren Bild gezeigt eine kleine weiße (Farbwert (255,255,255)) und schwarze Fläche (Farbwert (0,0,0)) hinzu (leider konnte auch ich das Bild hier nur im JPG-Format hochladen, aber das Original hat das BMP-Format). Wenn Du dann nochmal versuchst, das Höhenfeld auf die Anlage zu bringen, wirst Du sehen, dass die untere Eckfäche tatsöchlich auf Höhe 150 und die obere Eckfläche auf Höhe 2500 liegt (bei mir hat's zumindest so funktioniert). Ich vermute daher, dass bei Deinem Höhenfeld die dunkelsten Flächen (nahe dem Farbwert (0,0,0)) für die unteren Ebenen irgendwie verloren gegangen sind. Viele Grüße BahnLand

Hallo fex, Danke für das Däumchen und auch allen anderen für die "Gefällt-mir"-Klicks! Was da nach 30 Tagen abläuft, ist die Lizenz für die Vollversion "Sketchup 2016". Denn wenn Du Sketchup Make installierst, bekommst Du automatisch für diese 30 Tage die Vollversion bereitgestellt. Wenn die 30 Tage um sind, wird dann automatisch auf Sketchup Make 2016 (die Light Version von Sketchup 2016) zurückgeschaltet. Sketchup Make hat keine zeitliche Beschränkung und kann daher von Dir bis zum "Sankt-Nimmerleins-Tag" benutzt werden. Wenn Du nicht gerade obj-Dateien exportieren oder importieren möchtest, reicht Sketchup Make (d,h, die Light Version) nach meiner bisherigen ERkenntnis vollkommen aus. Ich verwende auch nur Sketchup Make und habe zumindest bisher noch nicht bemerkt, dass mir irgend eine dringend benötigte Funktionalität fehlen würde. Übrigens gibt es jetzt auch schon Sketchup 2017 und Sketchup Make 2017. Mit diesen Versionen kannst Du den neuen DirectX-Exporter ebenfalls einsetzen. Viele Grüße BahnLand

Hallo Lobo, die eingezogenen "Fensterhöhlen" machen schon was her, und die Dachgauben sind Dir auch sehr gut gelungen. Viele Grüße BahnLand

Hallo Lobo, nach der Größe des Zylinders zu urteilen könnte es sich auch um einen Urenkel von William Wilson handeln, der als erster Lokführer des Adlers zwischen Nürnberg und Fürth pendelte. Zumindest erschien mir dessen Kopfbedeckung in dem zum 100-Jährigen Bestehen der deutschen Eisenbahn gedrehten Film etwas zu "überdimensioniert" . Bei Deiner Bank, wo man offenbar günstig MBS-Aktien kaufen kann (), gefallen mir besonders die Kugellampen am Haupteingang mit der jeweils hell leuchtenden Halbkugel im unteren Bereich. Ich vermute, dass Du da jeweils zwei Kugeln des Grundkörper-Sortiments in der Höhe etwas versetzt übereinander gestülpt hast, sodass man oben und unten jeweils eine Hälfte der beiden Kugeln sieht (liege ich da richtig?). Viele Grüße BahnLand

Hallo Wolfgang, das mit dem Flag hatte ich verstanden. Nur wegen der verschiedenen Werte 0 und 1 dachte ich, ich hätte eventuell etwas übersehen. Ansonsten ist Dein Algorithmus für mich jetzt klar. Vielen Dank für Deine zusätzliche Erklärung. Man kann bei den Ereignissen "Zug betritt/verlässt Gleis" die Fahrtrichtung des Zuges schon erkennen, wenn man in der Ereignisdefinition zusätzlich die Bedingung "Lok/Wagen steht auf einem Gleis" auswertet. Wichtig ist hierbei, dass das als Auslöser verwendete Gleisstück und das Gleisstück, auf welches man sich in der Bedingung bezieht, unmittelbar aneinander anschließen. Man betrachte hierzu beispielsweise das grün-blaue Gleispaar vor der Diesellok im Bild links vorne. Ich möchte hierzu das Gleisstück, welches als Auslöser für die Ereignisse "Zug betritt Gleis" und "Zug verlässt Gleis" herangezogen wird, als "Ereignisgleis", und das Gleis, das in der Bedingung "Lok/Wagen steht auf einem Gleis" betrachtet wird, als "Prüfgleis" bezeichnen. Sei nun das grüne Gleis das Ereignisgleis (Zug betritt/verlässt grünes Gleis) und das blaue Gleis das Prüfgleis (Lok/Wagen steht auf blauem Gleis). Ist nun bei dem Ereignis "Zug betritt grünes Gleis" die Bedingung "Lok/Wagen steht auf blauem Gleis" erfüllt, fährt der auslösende Zug von rechts nach links. Ist die Bedingung nicht erfüllt, fährt der Zug von links nach rechts. Man kann also für beide Fahrtrichtungen getrennte Aktionen ausführen lassen. Erklärung für das Erkennen der Fahrtrichtung: Fährt der Zug von links nach rechts, betritt er das grüne Ereignisgleis, bevor er das blaue Prüfgleis erreicht. Er kann sich also zum Zeitpunkt der Ereignis-Auslösung nicht auf dem Prüfgleis befinden. Die Bedingung ist also nicht erfüllt. Fährt der Zug dagegen von rechts nach links, muss er zuerst das blaue Prüfgleis passieren, bevor er das grüne Ereignisgleis erreicht. Zum Zeitpunkt der Ereignisauslösung befindet er sich also gezwungenermaßen noch auf dem Prüfgleis, sodass die Bedingung erfüllt ist. Beim Ereignis "Zug verlässt Gleis" ist die Fahrtrichtung des Zuges in Abhängigkeit davon, ob die Bedingung erfüllt ist oder nicht, vertauscht: Ist bei dem Ereignis "Zug verlässt grünes Gleis" die Bedingung "Lok/Wagen steht auf blauem Gleis" erfüllt, fährt der auslösende Zug von links nach rechts. Ist die Bedingung nicht erfüllt, fährt der Zug von rechts nach links. Auch hierfür eine Erklärung: Fährt der Zug von links nach rechts, befährt er das blaue Prüfgleis im Anschluss an das grüne Ereignisgleis. In dem Moment, wo er das Ereignis "Zug verlässt grünes Gleis" auslöst, befindet er sich also noch auf dem blauen Prüfgleis. Die Bedingung "Lok/Wagen befindet sich auf blauem Gleis" ist also erfüllt. Fährt der Zug dagegen von rechts nach links, passiert er also das blaue Prüfgleis vor dem grünen Ereignisgleis, muss er zu dem Zeitpunkt, wo er das grüne Ereigisgleis verlässt, zwangsläufig auch das blaue Prüfgleis bereits verlassen haben. Deshalb ist hier beim Auslösen des Ereignisses "Zug verlässt grünes Gleis" die Bedinging "Lok/Wagen steht auf blauem Gleis" nicht erfüllt. Wer Lust hat, kann jetzt einfach mal das ganze Szenario durchspielen, wenn man die Funktionalität des grünen und des blauen Gleises vertauscht, also das blaue Gleis als Ereignisgleis ("Zug betritt/verlässt blaues Gleis") und das grüne Gleis als Prüfgleis ("Lok/Wagen steht auf grünem Gleis") verwendet. Wie sehen die Schlussfolgerungen für "Bedingung erfüllt" und "Bedingung nicht erfüllt" dann aus? Tipp: Die Begriffe "lnks" und "rechts" müssen in der obigen Beschreibung einfach vertauscht werden. Aber warum? Die Antwort auf die Frage steckt in meinen beiden "Erklärungen". Viel Spaß beim Tüfteln. Bei dem obigen Bild werden übriges die Gleispaare "grün/blau" mit dem Ereignis "Zug betritt Gleis" verwendet. Sie erfüllen damit den Zweck der in den vorangegangenen Beiträgen beschriebenen Beginn-Gleise. Die Gleispaare "gelb/orange" werden dagegen mit dem Ereignis "Zug verlässt Gleis" verwendet. Sie entsprechen damit den Ende-Gleisen der vorangegangenen Beiträge. Dadurch, dass durch die Zusatzberdingung die Fahrtrichtung des Zuges erkannt werden kann, braucht man hierfür die Objektvariablen "<Lok>.BüAusgang" als Indikator-Variablen, ob der Zug in den Bahübergangvereich ein- oder ausfährt, nicht mehr. Man löst das Schließen der Schranken (über das Hochsetzen des Belegungszählers) einfach nur dann aus, wenn sich der Zug beim Passieren des jeweiligen Beginn-Gleises zum Bahnübergang hin bewegt. Fährt der Zug vom Bahnübergang weg, wird diese Aktion nicht ausgeführt. Umgekehrt verhält es sich beim Öffnen der Schranken an den Ende-Gleisen. Die Aktion "Belegungszähler herunterzählen" (bei "0" werden die Schranken geöffnet) darf nur angestoßen werden, wenn sich der das Ende-Gleis passierende Zug vom Bahnübergang weg bewegt. Fährt der Zug auf den Bahnübergang zu darf, der Zähler nicht heruntergesetzt werden. Viele Grüße BahnLand

Hallo Wolfgang, nachdem ich jetzt Dein Video zweimal angesehen habe, ist mir klar, wofür Du die Objektvariable "<Lok>.BüAusfahrt" benötigst. Du identifizierst hierdurch die Fahrtrichtung des Zuges und verhinderst dadurch, dass die Schranken geschlossen werden, wenn der Zug ein Beginn-Gleis in der "falschen" Richtung "betritt". Das mache ich bei meinem Algorithmus über die Abfrage, ob ein Fahrzeug des Zuges auf dem unmittelbaren Nachbargleisstück steht. Auch damit kann ich erreichen, dass die Schranke nur dann geschlossen wird, wenn sich der das Beginn-Gleis betretende Zug in Richtung zum Bahnübergnag hin und nicht in entgegengesetzter Richtung bewegt. Damit benötige ich die Zug-bezogene Objekt-Variable nicht, und konnte daher mit ihr in der EV von Gertschi auch nichts anfangen. Auf die Indikator-Variable "Schranke_geschlossen" hatte ich bei meiner Demo-Anlage ebenfalls verzichtet, da der Anstoß zu Schließen einer bereits geschlossenen Schranke eigentlich "Ins Leere" läuft und damit zumindest bei meiner Demo keine Auswirkung hat. Sobald aber mit dem Schließen der Schranke Zusatz-Aktionen verbunden sind, wie bei Deinem Beispiel das Aktivieren des Läutewerks, benötigt man diesen Indikator, um ein erneutes Läuten bei bereits geschlossener Schranke zu verhindern. Insofern habe ich beim Betrachten Deines Videos jetzt doch wieder etwas dazugelernt. Zu dem Problem von Gertschi hast Du ja die Lösung schon formuliert. Nur eine Frage häbe ich noch? Warum unterscheidest Du bei der Objektvarable "<Lok>.BüAusfahrt" die Werte 0 und 1 für den Ein- und Ausfahrbereich des Bahnübergangs-Abschnitts? Es wird doch nur überprüft, ob die Variable leer oder nicht leer ist, um beim "Betreten" eines Beginn-Gleises "richtig" reagieren zu können (oder habe ich etwas übersehen?). Viele Grüße BahnLand

Hallo Gertschi, was bezweckst Du mit der Objektvariable _Trigger1.BüAusfahrt, und warum verknüpfst Du diese Variable mit der Lok? Ist diese Variable der Belegungszähler für den Bahnübergang, um feststellen zu können, wann die Schranke wieder geöffnet werden darf? Wenn ja, bräuchtest Du zwei getrennte Belegungszähler für Bahnübergang A und Bahnübergang B, die beide den Wert 0 besitzen, solange sich kein Zug in den Bahnübergangs-Bereichen befindet (siehe die Vorgangsbeschreibung weiter unten). Du hast in Deinem Anlagenbild nur die Beginngleise ausgezeichnet (grün für Bahnübergang A, blau für Bahnübergnag B). Welches sind die Endegleise? Meinst Du damit die gelben Gleise für Bahnübergang A und die roten Gleise für Bahnübergang B? Du kannst _Trigger1 nicht einfach durch _Trigger2 ersetzen. Denn bei den Ereignissen Zug betritt/verlässt Gleis (ich vermute, dass Du Dich auf diese beziehst) repräsentiert _Trigger1 immer die Lok, deren Zug das Gleis betriitt oder verlässt, und _Trigger2 das Gleis, das betreten oder verlassen wird. Bei anderen Ereignissen der EV können _Trigger1 und _Trigger2 dagegen ganz andere Typen von Objekten repräsentieren. Ich habe mr mal Deine Anlage 2 - fertig Test Steuerung.mbp aus diesem Beitrag, auf die Du Dich beziehst, angeschaut. Da habe ich aber noch keine Objektvariable _Trigger1.BüAusfahrt gefunden. Kann es sein, dass dieser Stand Deiner Anlage nicht aktuell ist? Zum theoretischen Ablauf: Nähert sich ein Zug Bahnübergang A und betritt dabei in Fahrtrichtung zum Bahnübergang A hin ein diesem Bahnübergang zugeordnetes Beginngleis, muss der Belegungszähler für diesen Bahnübergang A um 1 hochgezählt werden. Sind die Schranken dieses Bahnübergangs zu diesem Zeitpunkt geöffnet (das ist der Fall, wenn der Belegungszäheler vor dem Erhöhen den Wert 0 besaß), müssen sie geschlossen werden. Entfernt sich der Zug vom Bahnübergang und verlässt dabei ein Endegleis in Fahrtrichtung vom Bahnübergang weg, wird der Belegungszähler für diesen Bahnüberang um 1 erniedrigt. Geht der Zähler hierbei auf 0, befindet sich kein Zug mehr im Bereich dieses Bahnübergangs, sodass dessen Schanken geöffnet werden können. Soll dieser Ablauf außer für den Bahnübergang A auch für einen weiteren Bahnübergang B realisiert werden, müssen alle verwendeten "Betriebsmittel" (das sind die Beginngleise, die Endegleise und auch der Belegungszähler!) neu eingerichtet werden. Wird für den zweiten Bahnübergang dann (vom ersten Bahnübergang völlig unabhängig) die gleiche Ablaufsteuerung realisiert, spielt es überhaupt keine Rolle, ob sich die "Belegungsabschnitte" um die einzelnen Bahnübergänge herum (also die Abschnitte zwischen Beginngleis und Endegleis für jedes Gleis am Bahnübergang und jede Fahrtrichtung) überscneiden oder nicht. Jedes "Zug-betritt/verlässt Gleis"-Ereignis bezieht sich immer genau auf einen der betrachteten Bahnüberänge und steuert somit auch nur diesen, ohne etwas von möglichen anderen Bahnüberängen "zu wissen". Trotzdem wird jeder Bahnübergang - für sich betrachtet - ordentlich geschlossen, wenn sich ein Zug nähert, und auch wieder ordentlicxh geöffnet, wenn sich "der letzte" Zug entfernt. Es gibt hierbei keinerlei Synchronität zwischen mehreren existierenden Bahnübergängen. Schau Dir bitte zwecks der hier beschriebenen Bahnübergangs-Schaltung einmal diese Beschreibung und das zugehörige Anlagenbeispiel an. Das sollte Dir eingentlich weiterhelfen. Eine fertige Anlage mit Bahnübergangssteuerung findest Du übrigens im Online-Katalog in der Rubrik "Experimentelle Anlagen": Bahnübergangs-Steuerung. Allerdings ist dort die Schrankensteuerung für jedes Gleis nur in einer Fahrtrichtung realisiert Viele Grüße BahnLand

Hallo Gertschi, ich habe mir gerade Deine Anlage 2 angeschaut. Ganz schön verzwickt. So ganz habe ich den Überblick über die verschachtelte Linienführeung mit den vielen Tunneln noch nicht gefunden. Aber gefallen tut mir die Analge sehr! Viele Grüße BahnLand

Hallo zusammen, aufgrund von Neo's Beitrag habe ich den Exporter und - vor allem - auch die Dokumentation noch einmal "angefasst". Mit der Aussage, dass es einen "Standard"-Maßstab für die an das Modellbahn-Studio zu übergebenden Modelle nicht mehr geben wird, ist die Einstellung "Zielgröße" in meinem DirectX-Exporter theoretisch überflüssig geworden, weil man dann, wenn man als Zielgröße für die X-Datei grundsätzlich die Originalgröße verwendet, gleich diesen Maßstab als _Scale_-Information weitergeben kann. Da es aber aufgrund der ursprünglichen zwingenden Anforderung "H0-Maßstab" im ehemaligen 3D-Eisenbahnplaner, der auch in den bisherigen Versionen des Modellbahn-Studios als "Standard-Maßstab" beibehalten wurde (jetzt allerdings wegen der möglichen _Scale_-Objekt-Definition nicht mehr zwingend einzuhalten), und in bisherigen "Zwischenlösungen" die neuen "Standard-Maßstäbe" 1:1 und 1:100 angedacht wurden, hatte ich bereits in der Februar-Version meines DirectX-Exporters indirekt (über die MBS-Versions-Auswahl) die Auswahlmögichkeit der Zielgröße in den Exporter-Einstellungen eingeführt. Die aktuelle Zielgröße stellt also "nur" eine Verallgemeinerung der Einstellung "Zielgröße" mit Eliminierung des Versionsbezugs dar. Wie Quackster an anderer Stelle mit Recht anmerkte, kann es nicht sein, dass aufgrund einer Änderung der Zielgröße in der X-Datei aufgrund neuer Vorgaben bei der Neugenerierung eines bereits bestehenden Modells vorhandene X-Datei-Erweiterungen (z.B. AnimationSet-Definitionen) neu berechnet (umskaliert) und damit auch neu geschrieben werden müssen. Deshalb lasse ich die individuelle Auswahl-Möglichkeit der Zielgröße in meinem DirectX-Exporter bestehen. Dem Modellbahn-Studio ist es nach Neo's letzter Aussage schließlich egal, in welchem Maßstab ihm das Modell vorgelegt wird, da es in jedem Fall die Information benötigt, in welchem Maßstab das Modell in der X-Datei vorliegt. Durch die automatische Ergänzung der X-Datei um diese Information mittels des "_Scale_-Objekt-Frames" durch den DirectX-Exporter, wenn die entsprechende Exporter-Einstellung gesetzt ist (_Scale_-Objekt : hinzufuegen), erspart man sich die händische Eingabe des X-Datei-Maßstabs beim Hochladen des Modells in den Online-Katalog und auch das Bereitstellen eines solchen Objekts im Sketchup-Modell. Deshalb lasse ich auch diese Exporter-Einstellung bestehen. Mit der Ersetzung der als Zielgröße eigentlich "sinnlosen" Einstellung "H0*Zoll" durch "wie Original", was bedeutet, dass als ZIelgröße der Maßstab der Originalgröße übernommen werden soll, kann jeder Anwender des DirectX-Exporters selbst entscheiden, ob er wie in obigem Beitrag von Neo beschrieben als Zielgröße grundsätzlich die Originalgröße des Sketchup-Modells weitergeben oder die Zielgröße individuell auswählen möchte. Entsprechend kann der Anwender auch entscheiden, ob er die Abfrage des Maßstabs durch das Modellbahn-Studio beim Hochladen beantworten oder diese Information bereits vorab in der X-Datei hinterlegen (lassen) möchte. Im DirectX-Exporter einmal eingegebene Einstellungen bleiben für alle danach durchgeführten Export-Vorgänge bestehen, bis sie der Anwender durch einen neuen Aufruf des Einstellungs-Dialogs explizit ändert. Anbei die aktualisierte Fassung des DirectX-Exporters und der zugehörigen Beschreibung. Noch ein Erklärungsversuch zur auswählbaren Einstellung "H0*Zoll" bei der Originalgröße: Sketchup ist ein amerikanisches Programm und gibt an der Ruby-Schnittstelle, die vom DirectX-Exporter "angezapft" wird, die Modellmaße in der Einheit "Zoll" gemessen aus. Das Modellbahn-Studio und auch dessen Vorläufer 3D-Eisenbahnplaner sind deutsche Programme und interpretieren die in der X-Datei hinterlegten Maßangaben als cm-Maße. Hierdurch ergibt sich der Effekt, dass dann, wenn beim Export keine entsprechende Transformation der Modellmaße erfolgt, beispielsweise ein Würfel, der in Sketchup mit einer Kantenlänge von 1 Zoll (= 2,54 cm) erstellt wurde, nach dem Export in der X-Datei dieselben Koordinaten-Angaben aufweist, diese aber im Modellbahn-Studio (oder 3D-Eisenbahnplaner) zur Darstellung des Würfels mit einer Kantenlänge von 1 cm, also zu einer um den Faktor 2,54 verkleinerten Darstellung gegenüber der Originalgröße des Sketchup-Modells führen. Da der vor der Existenz des eigenen DirectX-Exporters benutzte Exporter von Erwan de Cadoudal (https://sites.google.com/site/edecadoudal/sketchupwithdirectx) nur eine solche 1:1 Übernahme der Sketchup-Koordinaten in die X-Datei unterstützte, mussten daher alle Sketchup-Modelle, die im damaligen 3D-Eisenbahnplaner im Maßstab H0 dargestellt werden sollten, in Sketchup in dem um das 2,54-fache vergrößerten Maßstab "H0*Zoll" konstruiert werden. Da diese Modelle bei marginalen Änderungen auch heute noch für das Modellbahn-Studio exportiert werden können sollen, ohne sie hierfür umskalieren zu müssen, habe ich in den Einstellungen des DirectX-Exporters auch diesen Maßstab als Originalgröße berücksichtigt. Viele Grüße BahnLand

Hallo Lobo, dass die Verwendung der Ebene anstatt des Quaders nicht in allen Fällen funktioniert und zudem mit mehr Arbeitsaufwand verbunden sein kann, ist mir völlig klar. Dies gilt vor allem, wenn man die 3-Dimensionalität betonen möchte. Denn gerade dann werden eben mehr als nur eine Seite des Quaders sichtbar, die man dann auch alle durch entsprechende Ebenen ersetzen müsste. Und dann ist die Einsparung von Polygonen ja auch nicht mehr so hoch (siehe meine Beispiele der Reduzierung auf 1/6 oder "nur" auf 1/3). Insofern ist mein obiger Beitrag auch weniger als "Kritik", sondern mehr als "Anregung" zu verstehen. Also: Erfreue uns weiter mit Deinen schönen Modellen! Viele Grüße BahnLand

Hallo Lobo, ich sehe an Deinem "Rohbau" der Kirche, dass Du die Außenwände des Turms mittels Quadern realisierst. Gibt es einen Grund, dass Du hier anstelle des Quaders nicht die Ebene verwendest? Auch wenn dadurch das Problem der vielen Materialien nicht gelöst wird, könntest Du hierdurch immerhin eine ganze Menge von Polygonen einsparen: Bei den diagonalen Wänden könntest Du beispielsweise den Polygon-Verbrauch auf 1/6, bei den geraden Wänden auf 1/3 absenken. Der Grund dafür ist, dass bei den diagonalen Wänden jeweils nur eine Seite des Quaders von außen sichtbar ist, während es bei den Quadern für die geraden Wände zwei Seiten sind (für die einander gegenüber befindlichen Außenwände des Kirchturms). Eine hier für das gesamte Bauwerk ganz gröb geschätzte Reduzierung der Polygonzahl auf 1/3 wäre ja auch schon was wert. Ansonsten sind Deine Gebäude, die Du ja gerade am Fließband fertigst, schon eine Augenweide. Ich verstehe, warum Quackster damit schon seine Anlage "bepflastert" . Viele Grüße BahnLand

Hallo alle Sketchup-Modellbauer, der hier bereitgestellte neue Sketchup-DirectX-Exporter ist zwar ein Plugin, aber nicht für das Modellbahn-Studio, sondern für Sketchup (um dort Modelle für das Modellbahn-Studio exportieren zu können). Download aktuelle Version DirectX-Exporter V5 (31.10.2024).zip Download ältere Versionen DirectX-Exporter V4 (16.04.2021).zip DirectX-Exporter V3.zip Ich habe noch ein wenig an meinem Sketchup-DirectX-Exporter herumgebastelt und dabei folgende Korrekturen und Erweiterungen vorgenommen: Fehlerbehebung bei Teilobjekten ohne Flächen Wenn in einem Sketchup-Modell gruppierte Bauteile vorhanden waren, für die keine Flächen darzustellen waren, brach der Export bisher mit Fehler ab. Der Fehler wird jetzt abgefangen. Wird nun ein Bauteil ohne zu realisierende Flächen erkannt, wird dies im Export-Protokoll zwar angezeigt, die Bearbeitung aber fortgesetzt und "sauber" beendet. Im Protokoll werden Bauteile ohne darzustellende Flächen mit "0 Flächen" ausgewiesen. DirectX-Exporter funktioniert jetzt auch mit den neuen Sketchup-Versionen Es ist mir gelungen, die Ursachen, warum der DirectX-Exporter bisher mit den neueren Sketchup-Versionen nicht eingesetzt werden konnte, zu identifizieren und zu beseitigen. Hauptknackpunkt war hierbei die Verwendung einer neueren Ruby-Version durch Sketchup, durch welche UTF-8-Codes, zu denen insbesondere die deutschen Umlaute ä, ö, ü und das scharfe ß gehören, nicht mehr unterstützt werden und daher zu einem Abbruch des Ruby-Scripts (also des DirectX-Exporters) mit Fehler führen. Ich habe deshalb alle Umlaute und das scharfe ß in den Textausgaben durch "ae", "oe", "ue" und "ss" ersetzt. Auch wenn's jetzt etwas "weniger schön" aussieht, funktioniert es jedenfalls. Ein weiteres Problem stellte die inkompatible Änderung der Datums- und Uhrzeit-Ausgabe dar, die ich zur Berechnung der Ausführungszeit für den Export verwende. Hier hat sich das Ausgabeformat geändert, sodass ich einen neuen Lokalisierungs-Algorithmus für die Uhrzeit benötigte. Der DirectX-Exporter stellt jetzt automatisch fest, in welchem Format Datum + Uhrzeit ausgegeben werden, und wählt dann selbst die passende Aufbereitungsvariante aus. Somit kann der Exporter nun gleichermaßen sowohl mit den älteren Sketchup-Versionen (z.B. Sketchup V8) als auch mit den neuern Sketchup-Versionen (z.B. Sketchup 2016 oder Sketchup 2017) eingesetzt werden. Ausgabe in verschiedenen Zielgrößen und Hinzufügen eines _Scale_-Objekts möglich Laut Neo wird sich der vom Modellbahn-Studio verwendete "Standard"-Maßstab in der angekündigten neuen Version 4 von H0 (1:87) auf den Vorbild-Maßstab (1:1) oder den Maßstab 1:100 ändern (noch nicht endgültig festgelegt). Damit muss der Modellbauer zukünftig seine Modelle entweder in der neuen "Eingangs-Größe" für das Modellbahn-Studio abliefern oder in sein Modell das "_Scale_"-Objekt integrieren, mit dem er dem Modellbahn-Studio mitteilen kann, dass sein Modell eine vom "Standard" abweichende "Eingangs-Größe" besitzt. Letzteres ist vor Allem für solche Modelle von essentieller Bedeutung, die bereits für die bisherige Version des Modellbahn-Studios übergeben wurden, und deren X-Datei nach dem Export durchgeführte Änderungen und Erweiterungen (z.B. eine nachträglich hinzugefügte AnimationSet-Definition) enthalten. Bei einer Umstellung des Maßstabs für die mit dem DirectX-Exporter zu erzeugenden X-Datei müssten auch die hinzugefügten Änderungen und Erweiterungen entsprechend "umskaliert" werden. Lässt man dagegen den Maßstab für die X-Datei unverändert (mit ebenfalls unveränderter Erweiterung), und fügt stattdessen das _Scale_-Objekt ein, wirkt sich die dann implizit durchgeführte "Umskalierung" durch das Modellbahn-Studio auf die gesamte X-Datei (einschließlich der hinzugefügten Änderungen) aus (der Modelbauer muss selbst die Umskalierung nicht mehr machen). Der DirectX-Exporter bietet nun in den Einstellungen sowohl die Möglichkeit, eine neue Zielgröße für die beim Export zu erstellende X-Datei zu spezifizieren, als auch das _Scale_-Objekt durch den DirectX-Exporter automatisch hinzufügen zu lassen. Der DirectX-Exporter testet dann zuerst, ob in dem zu exportierenden Sketchup-Modell bereits ein _Scale_-Objekt vorhanden ist. Wenn nein, erzeugt der DirectX-Exporter das _Scale_-Objekt selbst, indem der den dort zu hinterlegenden Maßstab, in dem er auch die X-Datei erzeugt, aus den Einstellungen für die Zielgröße herausliest, und die X-Datei selbsttätig um dieses _Scale_-Objekt ergänzt. _Gizmo-Objekt zur individuellen Positionierung des Koordinatenkreuzes im MBS-Modell In den Einstellungen des DirectX-Exporters besteht bisher die Möglichkeit, den von Sketchup anhand der Positionierung des Sketchup-Modells relativ zum Koordinatenkreuz "abgelieferten" Koordinaten-Ursprung des Modells unverändert zu übernehmen oder ihn - für jede Koordinaten-Richtung getrennt - an den Minimal- oder Maximal-Wert aller Eckpunkte des Modells oder den daraus berechneten Mittelpunkt zu verlegen. Mit dem "_Gizmo"-Objekt besteht nun die Möglichkeit, diesen "Koordinaten-Ursprung" im Sketchup-Modell an jede beliebige Stelle zu verlegen und dadurch bei der Anzeige des Modells im Modellbahn-Studio dessen Gizmo exakt an dieser Stelle zu positionieren. Hierzu fügt man in das Sketchup-Modell eine Bauteil-Gruppe ein, der man die Bezeichnung "_Gizmo" gibt. Das Bauteil muss aus einer eingefärbten Fläche bestehen (am besten eine horizontale quadratische Fläche), deren geometrischer Mittelpunkt (Mitte zwischen den kleinsten und größten Koordinaten des Bauteils) als individuell zu positionierendes Koordinatenkreuz verwendet wird. Dieses "_Gizmo"-Bauteil wird dann an jene Stelle im Modell verschoben, wo bei der Anzeige durch das Modellbahn-Studio das Gizmo positioniert werden soll. Beim Export des Sketchup-Modells bestimmt dann der DirectX-Exporter die Mittelpunkt-Koordinaten des _Gizmo-Bauteils und verwendet diese anstelle der Exporter-Einstellungen für die X-, Y- und Z-Ausrichtung, um das Gesamtmodell relativ zu diesem "Gizmo"-Koordinatenkreuz zu verschieben. Das "_Gizmo"-Objekt selbst (also das entsprechende Bauteil im Sketchup-Modell) wird nicht Bestandteil der X-Datei und damit auch nicht Teil des Modells im Modellbahn-Studio. Beispiel für die Wirkungsweise des _Gizmo-Objekts: Das obige Bild zeigt zwei Varianten desselben quadratischen Flächenmodells, die sich nur durch die Position des hellblauen Vierecks unterscheiden. Dieses ist die mit "_Gizmo" bezeichnete Bauteil-Gruppe des Sketchup-Modells. Beim linken Bild fällt dessen Mittelpunkt mit dem Mittelpunkt des Gesamtfläche zusammen. Beim rechten Bild ist der Mittelpnkt des _Gizmo-Objekts in die äußere Ecke des grünen Quadrats verschoben. Auf dem zweiten Bild sind 4 gleichartige Flächenodelle auf einer Bodenplatte des Modellbahn-Studios platziert, die sich wie folgt unterscheiden: Die beiden Flächen in der oberen Zeile besitzen kein _Gizmo-Objekt. Es sind daher die Angaben für die X-, Y- und Z-Ausrichtung in den Einstellungen des DirectX-Exporters gültig. Beim linken Bild ist dort die Angabe "unveraendert" für alle 3 Richtungen eingestellt. Es sollte also die originale Position des Koordinatenkreuzes aus dem Sketchup-Modell übernommen werden. Leider sind die Werte, die Sketchup für das Koordinatenkreuz relativ zum Modell ausgibt, in x-Richtung etwas verschoben, sodass auch das Gizmo im Modellbahn-Studio entsprechend etwas verschoben ist. Da das Gesamtmodell zum Koordinatenursprung symmetrisch aufgebaut ist, kann man diesen Fehler von Sketchup durch die Exporter-Einstellungen "mittig" für die X- und die Y-Richtung beheben. Bei am Koordinatenkreuz unsymmetrisch ausgerichteten Sketchup-Modellen kann man aber auch hier die Position des Koordinatenkreuzes gegenüber dem Sketchup-Modell nicht auf das Modell im Modellbahn-Studio übertragen. Denn es gibt ja nur die Einstellungen "kleinster oder größter Koordinatenwert aller Eckpunkte" oder "Mittelpunkt zwischen kleinstem und größtem Koordinatenwert", der ja nicht zwingend mit dem Koordinatenursprung zusammenfallen muss. Bei den zwei unteren Beispielen wurde im Sketchup-Modell ein _Gizmo-Objekt erzeugt und wie im vorangehenden Bild positioniert. Vergleicht man hierzu die untere Modell-Reihe in der Darstellung des Modellbahn-Studios, sieht man, dass das Gizmo jeweils exakt an jener Stelle platziert ist, an welcher es auch im Sketchup-Modell platziert wurde. Dies gilt unabhängig davon, in welcher Position das Sketchup-Modell bezogen auf das dortige Koordinatenkreuz platziert ist. So, nun möchte ich Euch bitten, den neuen DirectX-Exporter, den ich Euch hier in dem beiliegenden ZIP-Paket beigelegt habe, einmal auszuprobieren. Bitte folgt bei der "Installation" des Exporters der als PDF-Datei ebenfalls in diesem Paket abgelegten aktualisierten Beschreibung. Denn die Dateien müssen in Abhängigkeit von der verwendeten Sketchup-Version in unterschiedlichen Verzeichnissen abgelegt werden. Ist der DirectX-Exporter erst einmal im zur Sketchup-Version "passenden" Plugins-Verzeichnis abgelegt, ist die Handhabung sowohl bezüglich der unterschiedlichen Sketchup-Versionen als auch in Bezug zu der existierenden und der angekündigten Version des Modellbahn-Studios identisch. Ich bin auf Eure Eindrücke sehr gespannt. Viele Grüße BahnLand

Hallo Hans, Zu Frage 1: Bei den "Doppel-Fahrzeugen" ist immer eines die "Lok" und das andere der "Wagen", unabhängig davon, ob es sich bei dem "Wagen" wirklich um einen solchen oder in Wahrheit um eine zweite Lokomotive handelt. Diese wird aber dann nicht angetrieben, sondern nur von der anderen gezogen oder geschoben. Bei der aus den beiden V100 bestehenden Doppeltraktion ist die V100a die "Lok" und die V100b der "Wagen", und zwar unabhängig von der Fahrtrichtung. Es zieht oder schiebt also immer die V100a, während die V100b nie selbst fährt, sondern immer gezogen oder geschoben wird (es findet also kein Austausch der Rollen statt). Insofern ist V100a mit BR38 der Schlepptenderlok(-Konfiguration) und V100b mit deren Schlepptender BR38T direkt vergleichbar (auch da werden die Rollen nicht vertauscht). Die Einzellok V200 dagegen belegt sowohl die Rolle der "Lok" als auch jene des "Wagens". Die "Lok" referenziert grundsätzlich in der Objekt-Variable "Lok.Hinten" den "Wagen", wobei BR38.Hinten = BR38T und V100a.Hinten = V100b ist. Die V200 referenziert sich dagegen selbst: V200.Hnten = V200. Vielleicht hätte ich anstelle von "Hinten" die Objektvariable als "Anhängsel" bezeichnen sollen. Dann wäre es möglicherweise etwas klarer gewesen. Zu Frage 2: Dass V100a und V100b zum selben Loktyp gehören, ist nicht zwingend. Man hätte die Doppeltraktion aber auch aus verschiedenen Loktypen zusammensetzen können (hätte dann genauso funktioniert). Man hätte also die Doppeltraktion auch mit einer E10 als "Lok" und einer V60 als "Wagen" ausstatten können. Dann hätte man der E10 die Objektvariable E10.Hinten = V60 zugewiesen, die E10 wäre immer das angetriebene Fahrzeug gewesen, und die V60 wäre immer als passives Fahrzeug mitgeführt worden. Zu Frage 3: Heißt die Variable "Var", referenziert man deren Inhalt immer mit "$Var". In dem von Dir gezeigten Bild muss man die Lok, deren Name in der Variable Lok1 enthalten ist, also mit $Lok1 referenzieren. Beim Eintrag für die Geschwindigkeit greife ich aber auf den Inhalt einer Objektvariable zu, wobei das Objekt selbt ebenfalls über eine Variable referenziert wird. Hierbei muss das Objekt dann in runde Klammern gesetzt weden, um die Indirektion anzuzeigen: Wenn in der Variable Lok1 der Name BR38 hinterlegt und deren Geschwindigkeit zum "Herantasten" in der Objektvariable BR38.VTast abgespeichert ist, erreicht man diesen Wert, indem man über Lok1 zuerst die Lok BR38 identifiziert, und dann über die Klammer anzeigt, dass man auf die mit "." angehängte Objektvariable zugreifen möchte. Das dem gesamten Ausdruck vorangestellte $-Zeichen besagt dann schließlich, dass der Inhalt dieses Ausdrucks angezeigt werden soll. Also in "Einzelschritten" aufgelöst: Lok1 = BR38 und BR38.VTast = 20 => $(Lok1).VTast = Inhalt von (Lok1).VTast = Inhalt von BR38.VTast = 20 Die Schreibweise wird übrigens im Wiki unter "Variablen" erklärt. Findet man bei der Referenzierung einer Variablen einen Unterstrich vor, gehört dieser zum Bezeichner der Variable. Vorzugsweise besitzen die Bezeichner der vom Modellbahn-Studio bereitgestellten "System"-Variablen einen führenden Unterstrich. Beispielsweise ist _Trigger1 jene Variable, welche die beim den Ereignissen "Zug betritt/verlässt Gleis" der Auslöser ist identifiziert. Dabei kann man dann insbesondere auf die "vordefinierten" Objektvariablen _Trigger1._Name (Beszeichnung der auslösenden Lokomotive) und _Trigger1._CurrentSpeed (aktuelle Geschwindigkeit der auslösenden Lokomotive) zugreifen. Hat man der referenzierten Lok dann noch zusätzlich selbst eine Objektvariable "verpasst" (z.B. die Objektvariable V100a.Hinten ohne Unterstrich), so tritt auch bei deren Referenz kein Unterstrich auf (ist immer Teil des enthaltenden Variablen-Namens). Beispiele: Lok V100a mit der "Wagenlok" (dem Anhängsel) V100b löse ein Ereignis "Lok betritt Gleis" aus, wobei deren Name in der Variablen Lok1 hinterlegt würde. Dann sind die nachfolgende Ausdrücke wie folt zu interpretieren: Lok1 = $_Trigger1._Name = V100a _Trigger1._CurrentSpeed = V100a._CurrentSpeed = Objektvariable der Lok V100a, welche deren aktuele Geschwindigkeit enthält (Lok1)._CurrentSpeed = V100a._CurrentSpeed = Objektvariable der Lok V100a, welche deren aktuele Geschwindigkeit enthält $_Trigger1._CurrentSpeed = $V100a._CurrentSpeed = 160 (Wert der aktuellen Lok-Geschwindigkeit) $(Lok1)._CurrentSpeed = $V100a._CurrentSpeed = 160 (Wert der aktuellen Lok-Geschwindigkeit) _Trigger1.Hinten = V100a.Hinten = Objektvariable mit der Referenz auf das "Anhängsel" (Lok1).Hinten = V100a.Hinten = Objektvariable mit der Referenz auf das "Anhängsel" $_Trigger1.Hinten = $V100a.Hinten = V100b $(Lokk1).Hinten = $V100a.Hinten = V100b Zu Frage 4: Die Variablen Lok1, Lok2, Lok3 und Lok4 werden verwendet, um sich die Identität der Loks, die in Gleis 1 (Kopfbahnhofgleis), Gleis 2 (Gleisabschnitt vor Signal des Streckenblocks 2), Gleis 3 (Gleisabschnitt vor Signal des Streckenblocks 3) und Gleis 4 (Bereitschafsgleis(stummel) für "Ablöse"-Lok) eingefahren sind, zu merken. Die einmal dort hinterlegte Information wird erst dann neu überschrieben, wenn die nächste Lok in das betreffende Gleis einfährt. Dass es 4 solche "Gedächtnis"-Variablen, aber nur 3 Loks gibt (die V100b als "Wagenlok" zählt hierbei nicht), muss zwangläufig eine Lok immer in zwei dieser Varablen auftauchen. Ich hätte also anstatt "Lokx" besser schreiben sollen: "in Gleis x zuletzt eingefahrene Lok" (das war mir aber zu lang ). Jeder Lok im Modellbahnstudio ist über das Vorzeichen der Geschwindigkeit eindeutig die Richtung "vorne" (die Richtung, in welche die Lok mit positiver Geschwindigkeit fährt) und "hinten" (entgegengesetzte Richtung) zugeordnet. Entsprechend sind die Kupplungen der Lok in der Ereignisverwaltung (Aktion "Kupplung aktivieren/deaktivieren" mit der Kupplungs-Auswahl "Vordere Kupplung / Hintere Kupplung") gekennzeichnet. Da bei der Dampflok BR38 mit (nicht angetriebenem) Schlepptender BR38T die Ausrichtung "vorne/hinten" eindeutig vorgegeben ist, also die "Lok" sich "vorne" und der "Wagen" sich "hinten" befindet, und daher für das Entkuppeln die beiden Kupplungen "Lok-vorne" und "Wagen-hinten" deaktiviert werden, die anderen beiden Kupplungen "Lok-hinten" und "Wagen-vorne" aber aktiviert bleiben müssen, war die logische (und für den Algorithmus zwingende) Schlussfolgerung, beide Loks der Doppeltraktion in die gleiche Richtung auszurichten sowie die vordere Lok als "Lok" und die hintere Lok als "Wagen" zu verwenden. Da ich die vordere Lok mit V100a und die hintere Lok mit V100b bezeichnet habe, folgt hieraus, dass V100a die "Lok" und V100b der "Wagen" ist und daher die Bezeichnung V100b in der Objektvariable V100a.Hinten hinterlegt ist. Also: Mit den Bezeichnungen V100a und V100b werden verschiedene Loks (die vordere und die hintere der Doppeltraktion) gekennzeichnet, wobei jede Lok wie beabsichtigt einen eindeutigen Namen besitzt (die zweite Lok jedoch als "Anhängsel" ("Wagen") der ersten mitläuft). Viele Grüße BahnLand

Hallo fex, bei Sketchup ist das ebenfalls ganz einfach (im Prinzip analog zu Blender): Bilde aus den Fenstern, die Du beleuchtet haben möchtest, eine Gruppe und gib dieser einen Namen, der mit "_LS" beginnt. Das ist alles. Denn den Rest macht das Modellbahn-Studio, das anhand des mit "_LS" beginnenden Namens erkennt, dass es sich hier um ein Objekt, handelt, das im Schatten oder bei Nacht nicht abgedunkelt werden darf. Erschrick bitte nicht, wenn Du dann beim Hochladen der x-Datei in den Online-Katalog in der "Modell-Statistik" eine um 1 erhöhte Anzahl von "Materialien" findest. Denn "beleuchtete" und "unbeleuchtete" Flächen können nicht zusammen in einem Objekt verarbeitet werden. Auch wenn Du insgesamt nur eine Multitextur verwendest, wird diese für beleuchtete und unbeleuchtete Flächen jeweils als "separates" Material betrachtet. Schon deshalb muss der Überprüfungs-Mechanismus, der die "Qualität" des hochgeladenen Modells bestimmt, mindestens 3 Materialien zulassen, weil als drittes Material möglichereise noch jenes für (halb-)tranpsarente Flächen dazu kommt. So, nun hat mich Quackster mal wieder überholt. Ich lasse aber den Betrag trotzdem hier stehen. Viele Grüße BahnLand

Hallo EASY, das sieht ja schon sehr beeindruckend aus. Ich bin auf das Endergebnis schon sehr gespannt. Viele Grüße BahnLand

Hallo Schlagerfuzzi, es gibt verschiedene Möglichkeiten, einen Countdown zu vewenden. Hier ein paar Varianten aus meinem Anlagenbeispiel (Anfrage004.mbp): Klassischer Countdown-Aufruf mit bestimmter Zeitvorgabe (Gruppe "Kopfbahnhof Einfahrt"). Countdown-Start in Definition "Herantasten2", Countdown-Ausführung in Definition "Entkuppeln1" oder Countdown-Start in Definition "Aufrücken4", Countdown-Ausführung in Definition "Ausfahrbereitschaft4". In beiden Beispielen wird eine Aktion angestoßen, die erst nach Ablauf der vorgegebenen Zeit einmalig ausgeführt wird. Periodische Aktionsschleife mit Abbruch (ebenfalls Gruppe "Kopfbahnhof Einfahrt"). Countdown-Start in Definition "Herantasten2" mit automatischem "Neustart", Countdown-Ausführung in Definition "Herantasten2", die so lange wiederholt wird, bis das Abbruchkriterium in der Bedingung erfüllt ist. Dann wird der Countdown explizit gestoppt. Möglicher Anstoß derselben Aktionsfolge aus verschiedenen Definitionen heraus. Countdown-Start in Definition "Einfahrt3" (Gruppe "Streckenblock3") sowie in Definition "Freigabe Block2" ("Gruppe Streckenblock2"), Unmittelbare Countdown-Ausführung (Wartezeit = 0) in Definition "Zugstart3" (Gruppe "Streckenblock3"). Viele Grüße BahnLand

Sieht gut aus! Viele Grüße BahnLand

Hallo Schlagerfuzzi, wie Henry kann ich solche Herausforderungen nicht einfach an mir vorüber ziehen lassen, sondern muss selbst ausprobieren, was da alles geht. Henry war allerdings schneller, weil ich noch ein paar "Gimmiks" einbauen wolte. Doch nun ist auch meine Variante Deines Anfrage-Beispiels fertig. Ich habe in der Anlage die ankommenden bzw. abgehenden Gleisstränge miteinander verbunden und noch einen weiteren Zug darauf gestellt. Auf der freien Strecke gibt es zwei Blockabschnitte, die für die beiden Züge zusammen mit dem Kopfbahnhof-Gleisabschnitt (kurz "Kopfgleis") 3 Blockabshnitte ergeben, die von den Zügen im Blockverkehr hintereinander befahren werden. Im Kopfgleis wird die bisherige Zuglok wie bei Henry abgehängt und am anderen Ende des Zuges die Lok vom Bereitschaftsgleis angehängt. Nachdem der Zug mit der neuen Lok das Kopfgleis verlassen hat, fährt die unrsprüngliche Zuglok für ihren nächsten Einsatz in das Bereitschaftsgleis. Aufgrund des Zusammenfügens der bei beiden ursprüngklich freien Gleisenden vollziehen die Züge beim Umfahren des Kopfgleises eine 540°-Drehung, sodass die Loks nach einer Umrundung entgegengesetzt ausgerichtet sind. Daher sind die Loks den Zügen abwechselnd vorwärts und rückwärts vorgespannt, was sich auch auf das Vorzeichen der dem Triebfahrzeug zugewiesenen Geschwindigkeit auswirkt. Das Vorzeichen dieser Geschwindigkeit ist also eine variable Größe, die bei der Steuerung der Züge mit berücksichtigt werden muss. Weiters habe ich untershedliche Lok-Konfigurationen vor die Züge gespannt: Es gibt eine "einfache" Lok, eine Dampflok mit Schlepptender, der fallweise von der Lok hinterher gezogen oder voran geschoben wird, und eine Doppeltraktion aus 2 Lokomotiven als dritte Lok-Konfiguration. Sowohl bei der Dampflok mit Schlepptender als auch bei der Doppeltraktion sollen die beiden Fahrzeuge der im Kopfgleis auszutauschenden Lok-Konfigurationen nicht getrennt, sondern als zusammengehörende Einheit betrachtet werden. Trotzdem gibt es auch hier immer ein Fahrzeug, welches als das Triebfahrzeug ausgewiesen ist und damit als einziges in der Lok-Konfiguration eine Geschwindigkeit zugewiesen bekommt. Das "Zweitfahrzeug" wird als Wagen (Schlepptender der Dampflok) oder "Wagenlok" (zweite V100 der Doppeltraktion) mitgeführt. Die Zusammengehörigkeit wird dadurch gekennzeichnet, dass das Zweitahrzeug beim Triebfahrzeug in einer Objektvariable hinterlegt ist (<Lok>.Hinten, mit <Lok> als Platzhalter für das jeweilige Triebfahrzeug). Bei der Schlepptender-Dampflok ist der Tender immer "hinten". Bei der Doppeltraktion müssen beide Loks gleich ausgerichtet sein. D.h. bei beiden zeigt die "positive Geschwindigkeit" in dieselbe Richtung. Dann wird die vordere Lok als Triebfahrzeug und die hintere Lok als zugehöriges Zweitfahrzeug ausgezeichnet. Auch bei der "einfachen" Lok wird ein Zweitfahrzeug ausgewiesen. Nur wird hier die Lok selbst eingetragen. Dadurch ist es möglich, sowohl Einzelfahrzeuge als auch Lok-Konfigurationen aus 2 Fahrzeugen in der Ereignisverwaltung identisch zu behandeln (beim einfachen Fahrzeugen beziehen sich dann die Anweisungen für das zweite Fahrzeug einfach auf die Lok selbst). Wo wird nun der Bezug auf das Zweitfahrzeug benötigt? Beim Entkuppeln der Lok-Konfiguration vom Zug. Es darf nur die vordere Kupplung des Triebfahrzeugs und die hintere Kupllung des Zweitfahrzeugs deaktiviert werden, damit die beiden Fahrzeuge nicht voneinander getrennt werden. Damit auch beim zweiten Fahrzeug die "richtige" Kupplung als "hintere" Kupplung angesprochen wird, muss dieses dieselbe Ausrichtung wie das Triebfahrzeug besitzen. Beim präzisen Stoppen des Zuges über der Trennstelle im Kopfgleis, damit der Zug nach dem Abkuppeln der Lok-Konfiguration durch ein an dieser Stelle eingebautes "Sperrgleis" beim "Auffahren" der ablösenden Lok-Konfiguration "festgehalten" werden kann und nicht weitergeschoben wird. Diese Position des Zuges im Kopfgleis ist genau dann erreicht, wenn sich sowohl das Triebfahrzeug als auch das Zweitfahrzeug beim Überfahren des Sperrgleises nicht mehr auf dem davor liegenden "Haltegleis" befinden. Handelt es bei der in den beiden obigen Punkten betrachteten Lok-Konfiguration um eine einfache Lok, erreicht man durch die Identifizierung dieser Lok auch als "Zweitlok", dass diese Mechanismen auch dann mit denselben Algorithmen funktionieren. Doch nun zur Steuerung der Züge im Kopfgleis selbst. Grob gesehen ist es der gleiche Ablauf wie bei Henry's Realisierung. Im Detail ist sie jedoch etwas anders gelöst: Der Hauptunterschied ist das rote Sperrgleis (eine Weiche mit langem (durchgehendem) und kurzem (abgeschnittenem) Pfad. Steht die Weiche auf "lang", kann der Zug ungehindert darüber fahren. Steht die Weiche auf "kurz", wird der am "Eingang" der Weiche stehende Zug an der Weiterfahrt gehindert, weil es für den kurzen Pfad keine Fortsetzung gibt. Als es die Möglichkreit, die Kupplungen zu deaktivieren, im Modellbahn-Studio noch nicht gab, konnte man hiermit Züge entkuppeln, wobei der vordere Teil, der den "Eingang" in die Weiche bereits passiert hatte, nach dem Sperren weiterfahren konnte, während der hintere Teil durch die Sperre "festgehalten" wurde. Wenn der Zug hierbei jedoch nicht "ganz exakt" an der richtigen Stelle angehalten wurde, gab es beim Sperren unschöne "Bocksprünge". Deshalb wird nun für das Entkuppeln selbst die Eigenschaft der Kupplungs-Deaktivierung genutzt. Um zu verhindern, dass die auf der anderen Seite auffahrende "neue" Zuglok nach dem Ankoppeln den Zug so lange weiter schiebt, bis es eine Möglichkeit gibt, diesen über ein passendes Ereignis zu stoppen, wird das Sperrgleis trotzdem benötigt. Durch dessen Sperrung, nachdem die abgekoppelte Lok weggefahren, aber bevor die ablösende Lok aufgefahren ist, wird ein Weiterschieben des Zuges blockiert. Die restliche Logik entspricht im Wesentlichen jener von Henry, nur dass sie durch das Hinzufügen von Signalen und das Schließen des "Kreises" mit weiteren Blockabschnitten etwas "verfeinert" worden ist, und hierbei die unterschiedlichen Fahrtrichtungs-Ausrichtungen der Triebfahrzeuge und aus mehreren Fahrzeugen bestehende Lok-Konfigurationen berücksichtigt wurden. Die beigefügte Anlage wird mit dem Schalter rechts vorne gestartet und gestoppt. Nach dem Zurücksetzen des Schalters fahren die Züge noch weiter, bis sie - wenn auch möglicherweise in abweichender Fahrzeug-Anordnung - vor den Blocksignalen der Ringstrecke und im Bereitstellungsgleis für die "Ablöse"-Lok zum Stillstand gekommen sind. Ich wünsche beim Testen der beiliegenden Anlage und beim Studieren der Ereignssteuerung viel Vergnügen. Anfrage004.mbp Viele Grüße BahnLand

Hallo Quackster, oh jaaaaa! Meine Schwester hatte als (geschätzt) 7-8-Jährige eine sehr "intime" Bekanntschaft mit einem solchen Gefährt gemacht: Unser Vikar besaß eine Isetta. Eines Tages, als ich mit meiner Schwester unterwegs war, lief sie plötzlich unbedacht auf die Straße, als gerade unser Vikar daher "gebraust" kam. Glücklicherweise stieg der sofort "in die Eisen" (auf die Bremse), sodass die Isetta gerade so zum Stehen kam, dass meine kleine Schwester genau an der Stoßstange stand - die Arme "wie ein Engel" seitlich auf der Isetta-Tür ausgebreitet. Meine Schwester hatte dabei nicht einmal eine Schramme abbekommen. An den Schreck, der dem Vikar ins Geschicht geschrieben gewesen sein muss, und an die nachfolgende obligatorische Standpauke kann ich mich allerdings nicht mehr erinnern. Auch wenn mir damals - ich war ja selbst noch ein Kind - nicht bewusst war, welch einen riesigen Schutzengel meine Schwester gehabt hatte, und wie das Ganze auch anders hätte ausgehen können, ist mir dieses Szene - wenn auch etwas verblasst - bis heute in Erinnerung geblieben. In der Konfirmationszeit haben wir Konfirmanden unserem Vikar dann auch noch einen Streich gespielt: Das Gelände unserer Kirche war gegenüber der Straße etwas erhöht und durch ein kleines Mäuerchen abgegrenzt (dürfte etwa 60-80 cm hoch gewesen sein). Daneben gab es einen Parkstreifen, auf dem unser Vikar immer seine Isetta abgestellt hatte, wenn er in der Kirche war. Einmal nach dem Konfirmanden-Unterricht, als der Vikar danach noch in der Kirche zu tun hatte, ergiffen einige meine "Konfirmanden-Kollegen" die Chance, hoben die Isetta in gemeinsamer Anstrengung an und setzten sie - mit der Tür zum Mäuerchen gewandt - unmittelbar vor diesem ab. Und dann ab durch die Mitte .... ! Ich weiß bis heute nicht, wie der Vikar in seine Isetta kam. Jedenfalls war er am nächsten Tag wieder mit ihr unterwegs. Ja ja, das waren schon urige Gefährte, die da zu jener Zeit über unsere Straßen rollten. Da gab es noch das Goggo(mobil) (meine Tante hatte ein solches besessen), den Lloyd ("Leukoplastbomber"), den Messerschmitt Kabinenroller ("Schneewittchensarg") und den Janus von Zündapp. Letzterer besaß eine Front- und Hecktür ala Isetta, und die hinteren Passagiere saßen rückwärts im Auto. Ich freue mich schon auf das fertige MBS-Modell, das ganz bestimmt auch auf meinen Anagen zum Einsatz gelangen wird. Viele Grüße BahnLand