Goetz

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

Meines Wissens heißen die Ankerpunkte für Fahrspuren "Wheelset". Die sitzen wie Stifte in einer Rille in der Mitte der Fahrspur. Und man kann davon pro Fahrzeug maximal zwei haben, weil maximal zwei Stifte bei jeder Krümmung der Fahrspur immer in der Rille bleiben können. Optional können diese Wheelsets auch in Richtung der (Tangente zur) Fahrspur gedreht werden, um Drehgestelle oder Räder in Kurven auszurichten. Für die starren Radachsen und die starre Deichsel von Axels Wohnwagen oder Chris' Anhänger ist diese Option unpassend.

Wenn man beim Anhänger das vordere Wheelset genau unter den Ring an der Deichsel setzt und beim Fahrzeug das hintere Wheelset genau unter die Kupplung, dann bleiben diese beiden Punkte bei Kurvenfahrten in der Mitte der Fahrspur und somit auch zusammen. Das sagt mir zumindest mein allgemeines Geometrieverständnis, ohne reale Erfahrungen im Modellbau.

Und das scheint mir sehr glaubwürdig zu sein.

Ich bin aber auch begeistert, was für ein Gespür du für diese Kleinigkeiten hast. Das sieht alles sinnvoll und stimmig aus. (Bis auf die Weichenlaterne - da stimme ich Roter Brummer zu, dass die an der Stelle unpassend wirkt.)

And the answer is still the same: The 3D-Train Studio isn't the right software for you!

Save yourself the expense, Leslie. The 3D-Train studio isn't the right software for you.

Demanding and stingy - why am I not surprised?