Goetz

Mir gefällt die Änderung sehr gut

Trotzdem kann auch bei der originalen Lok der Wasservorrat eigentlich nicht in der Mitte dieses großen Zylinders gewesen sein. Man will ja nicht den kompletten Vorrat auf einmal verdampfen. Selbst eine Tenderlok hat den Vorratsbehälter hinter dem Führerhaus. Und da ist bei dieser Lok kein Behälter, wohingegen der Tender große Kästen hat, die viel Wasser aufnehmen können.

Klick auf das blaue Dreieck am Ende. Jetzt kannst du entweder mit dem Gismo die Straße freihändig biegen oder du kannst das Eigenschaftenfenster nutzen um dort Radius und Winkel einzugeben. Alle enthaltenen Spuren, also sowohl das Modell (für die Darstellung) als auch die enthaltenen virtuellen Fahrspuren, werden dabei gemeinsam verbogen.

Auf diesem Foto meine ich den Wasserschlauch vom Tender zur Lokomotive erkennen zu können: 9b280d6f-8f19-4f8c-bb2e-3ae3c24734ce-transcontinentalrail.jpg (1860×1200) Das spricht dafür, dass das Wasser im Tender mitgeführt wurde.

Hallo Adler_84, es gibt Denkansätze anderer User zu diesem Thema, die aber mindestens ebenso komplex wie deine Demo sind. Wegen der komplexen Logik, die eine Verkehrsregelung erfordert, stellt Neo meines Wissens Überlegungen an, ob er den Usern diese Mühe abnehmen und die Steuerung im Studio automatisieren kann. Auf der linken Seite ist in deiner Demo eine Verbindung unsauber. Deshalb bleiben dort alle Fahrzeuge vor dieser Nahtstelle stehen. Wenn man diese Verbindung korrigiert, läuft deine Demo sehr gut Viele Grüße Götz

Hallo Thomas, das Gerät der Wahl wäre hier ein 3D-Drucker und keine Fräse. Und unabhängig vom verwendeten Gerät eignen sich die Daten nicht ohne Weiteres für ein reales Modell. Denn eine virtuelle Hauswand hat keine Dicke. Sie ist nur eine Fläche, aber jede Hauswand eines realen Modells ist ein Quader. Es sind viele zusätzliche Arbeiten nötig, damit aus dem virtuellen Modell ein Datenpaket entsteht, welches für eine Fräse oder einen 3D-Drucker geeignet ist. Der Unterschied bei der Hauswand ist nicht das einzige Problem. Er soll dir nur deutlich machen, wie sehr sich die Datenpakete unterscheiden. Viele Grüße Götz

I doubt it very much, Howard to clarify: Your condition (as is) assumes that the variable "Vehicle Type" in the triggering vehicle holds an object. It then looks for another variable by the name of "Truck - W10" in that object, assuming that that variable holds another vehicle. And then it checks if that other vehicle is on the track that your triggering vehicle just left. I'm quite certain that this is far from what you actually want to achieve.

Sorry, but your assumption is wrong. The check if a variable exists looks like this (when converted to Lua): if object["VariableName"] ~= nil then -- do something with the variable end The sole purpose of this check is to avoid the "nil value" error and only use the variable when it has content. If only I could see what you actually did. Because whatever caused the error, it wasn't the check. It was something else. Like placing the command in the wrong field of the condition (the bottom half) or negating the check or god knows what! Here is how it should look in graphical form: I hope this helps? Goetz

Hello Howard, I figured that this might be what you do (and how you end up with unpredictable results). Instead of trying to grab the copy with your mouse, you may want to activate the gismo (shortcut: G) first and then use one of it's axiis to drag the copy to a new location. Another safe method to copy an item is to position the mouse over the original model hold down the left mouse button hold down the left Alt key too drag the model to its new location (this creates the copy, the original remains at its place) release the Alt key release the left mouse button kind regards Goetz

Hallo @Chris06, dieses kurze Blender Tutorial erklärt es sehr anschaulich: Viele Grüße Götz

When you duplicate a model, the fresh duplicate is always the active model. You can rename it, reposition it, change it's properties ... Just don't select it! Don't click on it! Because when you attempt to select it, you may accidentally grab the original instead.

What's the error message in this particular case, hmclay? It may hold that clue you're looking for. Without knowing what error you get when checking if the variable exists, it's difficult to guess what's going wrong.

Hallo wkh, für mich wird vor allem deutlich, dass es nicht ratsam ist zwei Methoden zu vermischen. Alles, was du mit deinen Anhängseln an den Namen der Kontakte erzielst, kannst du ebenso gut mit Objektvariablen in diesen Kontakten erreichen. Die hätten dann - im Gegensatz zu deinen Anhängseln - aussagekräftige Namen. Das alleine würde die Lesbarkeit deiner experimentellen Anlage schon merklich verbessern. Diese Anhängsel lösen keins deiner Probleme, verursachen aber unnötige Komplikationen. Nimm zum Beispiel die Parkzeit: Wenn der Kontakt eine Variable Parkzeit enthielte, dann könnte in dieser Variablen der Wert als Zahl stehen. Damit sparst du dir schon die zweifache Umwandlung. Du prüfst, ob die Variable vorhanden ist und verwendest dann den Wert aus der Variablen für die Verzögerung. Fertig. if contact.Parkzeit ~= nil then -- Fahrzeug wird geparkt, Richtungswechsel - Vehicle will be parked, drive direction change vehicle.engine.active = false vehicle.drivingDirection = -vehicle.drivingDirection vehicle.target = GetNewDestination(vehicle) -- Weiterfahrt nach Wartezeit - Route to be continued after waiting time $("ParkingSlotExit"):invoke(contact.Parkzeit, vehicle) return end Anstelle des Kontakts übergibst du gleich den Wert der Variablen an das Ereignis ParkingSlotExit (und benennst den Parameter entsprechend): if not deferredCall then defer(Parkzeit, "Delay") elseif deferredCall == "Delay" then -- ... end Schon ist alles viel schlanker und lesbarer. Wenn du eh schon Objektvariablen einsetzt, dann bleibst du meines Erachtens besser konsequent dabei. Viele Grüße Götz

Hallo wkh, dennoch ist es bei dir immer nur ein Buchstabe an der siebten Stelle im Namen. Der könnte ebenso gut in einer Objektvariablen stehen. Wie du diese Information dann an unterschiedlichen Stellen im Programm auswertest, ist davon ganz unabhängig. Ganz allgemein haben alle Objekte im MBS eine Liste an Eigenschaften. Mit Objektvariablen kannst du diese Liste nach deinen Wünschen erweitern. Deshalb sind die das richtige Mittel für solche Unterscheidungen. Namen sind unzuverlässig und das Zerlegen des Namens ist unnötig umständlich. Du kannst übrigens in jedem Objekt eine beliebige Anzahl an Variablen haben. Und sie können Informationen ganz unterschiedlicher Art bereithalten: Zahlen, Strings, Objekte, Zeiten, Listen, Tabellen, Fahrstraßen, Ereignisse ... Jedes Objekt, also Fahrzeuge ebenso wie Kontakte, Signale, Gleisstücke usw., kann Objektvariablen speichern. So kannst du Informationen immer dort hinterlegen, wo sie logisch hingehören. Viele Grüße Götz

Hallo wkh, wenn du dafür die Schaltfläche in der Kopfleiste deiner Antwort benutzt, ist der Code dank Syntax Highlighting im Posting besser lesbar: if string.sub(contact.name, 7, 7) == "I" then if HasVehicleRoute(vehicle, contact) == false then return end end print("Weiter") -- Zielkontakt - Destination contact? if vehicle.variables["Contact"] ~= contact then return end -- Dieser Kontakt ist der Zielkontakt - This contact is the target -- Fahrtunterbrechung ohne Richtungswechsel - Driving break without direction change if string.sub(contact.name, 7, 7) == "B" then vehicle.engine.active = false -- Weiterfahrt nach Wartezeit - Route to be continued after waiting time $("BreakEnd"):invoke(contact, vehicle) return end Und wenn du deine Kontakte unterscheiden willst, empfehle ich dir eine Objektvariable anstelle des siebten Zeichens im Namen. Die Variable nennst du immer gleich - z.B: Typ - und darin hinterlegst du einen Buchstaben oder eine Zahl. Eine Zahl hätte dann noch den Vorteil, dass du die als Index verwenden kannst, um direkt aus einer Liste die zugehörige Funktion zu holen. Das ist besser als mit einer Reihe von Vergleichen alle eventuellen Möglichkeiten abzuklappern. Falls du lieber bei deiner Variante mit dem Namenszusatz bleiben willst, lies ihn einmal aus und lege ihn in einer lokalen Variablen ab. Denn du brauchst dieses siebte Zeichen ja mehrfach. Nämlich für jeden der Vergleiche. Da lohnt es sich, wenn du den Namen nicht immer wieder neu auslesen und zerlegen musst, sondern auf die lokale Variable direkt (= im Prozessor-nahen Cache) zugreifen kannst. Viele Grüße Götz

Die werden vom Hersteller auch nicht mit Stroh ausgeliefert. Aber neben den Katalogbilder gibt es auch eine Vielzahl von Lehrvideos auf YouTube. Da sieht man dann den typischen Gebrauch.

Aber nicht beim Pferdeanhänger. Da sind die Achsen tatsächlich meist so weit hinten. Aus gewichtigen Gründen, sozusagen ... 105908.jpg (1499×1080) Viele Grüße Götz

Genau das funktioniert leider nicht und das wollte ich dir mit meiner Erläuterung zum $-Zeichen verdeutlichen. In der Klammer steht nichts, was du zum Adressieren des Objekts verwenden kannst. In der Klammer steht nur eine Rückmeldung vom Studio. Deshalb eignet sich die $-Schreibweise nicht zur dynamischen Adressierung von Objekten.

Hallo wkh, kennst du mein Video zu diesem Thema? Den Link dazu findet du in meiner Signatur. Die Anlage zum Video hat die Content-ID 20F2B5B8-FAC2-403A-A063-DC084515941A Selbst, wenn es noch weit von dem entfernt ist, was dir an generischer Prozedur vorschwebt, könnte das eventuell als Diskussionsgrundlage dienen? Und wenn du die EV in Lua umwandelst, siehst du schon eine ganze Reihe nützlicher Schreibweisen. Die Schreibweise mit dem vorangestellten $-Zeichen ist eine Besonderheit im Studio. Dahinter verbirgt sich eine Objekt-ID. Der Name in den Klammern soll dir nur zeigen, um welches Objekt es sich handelt. Du kannst das Objekt sogar umbenennen und wirst dann im Skript entsprechend den neuen Namen wiederfinden. Das heißt aber im Gegenzug, dass Objekte bei dieser Schreibweise nicht mit ihrem Namen angesprochen werden. Viele Grüße Götz

Geh es doch logisch an, Walter: Das entscheidende an einem Kontaktpunkt ist der Punkt in der Mitte. Das Drumherum ist nur da, weil man einen Punkt alleine nicht sehen und nicht anfassen kann. Also gehört der Punkt in der Mitte des _CP Objekts auf die Kante des Modells, wenn zwei Modelle mit ihren Kanten aneinander andocken sollen. Damit kannst du Möglichkeit 2 ausschließen. Bleibt die Frage der Ausrichtung. Um die herauszufinden, kannst du den Kontaktpunkt aus dem Katalog nehmen und an ein geeignetes Katalog-Modell andocken. Dann siehst du, wie die Ausrichtung bisher gehandhabt wird. Und diesen defacto Standard kannst du für dein Modell übernehmen. Ich hoffe, dass dir diese Erklärung ein wenig weiterhilft Götz

Ja, das war unangebracht. Und was die Position der Hebelbänke in Stellwerken angeht, hat mich meine Erinnerung getäuscht. Tut mir leid! Götz

Hallo Thomas, setz ein Leerzeichen vor FB, zwei Leerzeichen vor TB und noch einmal ein Leerzeichen vor die Zahlen, dann passt es.

Oh, dann muss ich mich entschuldigen. Solche Hebel kannte ich bisher nicht.

Hallo @rainer.kreuzer, das wäre völlig unrealistisch. Solch ein Signal (zweiflügelig, ungekoppelt) wurde mit zwei Hebeln bedient, je einer für die beiden Flügel. Dein Diorama zeigt zwar, dass du wenig Wert auf Realismus legst. Du verstellst die Fenster mit Hebelbänken, die eigentlich in die Raummitte gehören. Du stellst ein riesiges Reiterstellwerk dorthin, wo keine einzige Weiche zu sehen ist und nur ein einzelnes Flügelsignal. Dafür bekommt der Streckenabschnitt, den jeder Lokführer auch bei schlechtesten Sichtverhältnissen sicher befahren könnte (weil es eh nur geradeaus geht) eine teure Festbeleuchtung ... das ist alles hübsch, aber ziemlicher Mumpitz. Das ist natürlich alles deine Sache und du kannst deiner Fantasie da freien Lauf lassen. Ich bezweifle nur, dass ein Modellbauer, der im Gegensatz zu dir Realismus schätzt, solchen Blödsinn bauen wird. Diese Hebel kennen nur zwei Stellungen. Weil damit ein Seilzug bedient wird. Da gibt es keine halben Sachen. Viele Grüße Götz

Aber nur, wenn die Spur ein kontinuierlicher Kreis ist. Dort, wo eine Gerade in eine Kurve übergeht, wird das so nicht der Fall sein (falls der Anhänger nur ein Wheelset hat) Klasse, Axel! Dein Konstrukt funktioniert hervorragend