Hawkeye

Doch, der Text „ falsche Schlußfolgerung“ bezieht sich nicht auf vorherige Beiträge. Ich hatte noch einen Beitrag erstellt. Da hatte ich aber einen Denkfehler und habe in wieder entfernt. Löschen geht nicht, also musste etwas stehenbleiben. VG, Hawkeye

Sorry, falsche Schlußfolgerung. 🙄 VG, Hawkeye

Moin, um die Beobachtung von Bahnkater weiter einzugrenzen, habe ich die Testanlage erweitert. Die Gerade sind auf exakt +/-50mm verlegt und die Gesamtlänge ist auf ca. 90.000mm vergrößert. Kameratest_V2.mbp 1. Umlauf: Die Kamera ist am letzten Wagen verknüpft und folgt der Lok nicht. Hier bleibt der Y-Wert nach einem Umlauf erhalten. 2. Umlauf: Die Kamera ist am letzten Wagen verknüpft und folgt der Lok in den Kurven. Hier stellt sich nach einem Umlauf schon eine Verschiebung von 0,2mm ein. Es muss also einen Zusammenhang mit der Koordinatentransformation durch die Relativbewegung der Kamera geben. VG, Hawkeye PS: @Bahnkater: Die schnellste Lösung für dein Problem ist, das Verfolgen der Lok abzuschalten und ggf. den Blickwinkel zu erhöhen.

Hallo Eggu, das sehe ich auch so. Ich hab mal zum Testen eine ähnliche Anlage, in einer "normalen" Größe erstellt. (X-Werte ca. +/- 10.000mm). Die Geraden liegen auf +/- 50mm. Hier bleibt die Kameraposition am letzten Wagen mit dem y-Wert auf der Geraden immer gleich bei 50 mit einer max. Abweichung +/- 0,01 Die Anlage von Bahnkater ist aber gigantisch! x-Werte bim Bereich von +/-83.000mm! Ich vermute, je größer die Zahlen mit denen die Position errechnet wird, umso weniger Nachkommastellen werden berücksichtigt. Dadurch können solche Rundungsfehler entstehen. Die sich nach einer Weile auch aufsummieren und zu solchen Effekten führen. Kameratest.mbp VG, Hawkeye

Hallo Bahnkater, der erste Schritt war doch, erstmal aus deinen dünnen Informationen die Beobachtung zu bestätigen und zu reproduzieren. Das haben Götz und ich ja auch endlich geschafft. Sicherlich wird sich @Neo das auch ansehen. VG, Hawkeye

Das stimmt. Es lässt sich auch leicht nachweisen. An einer beliebigen, möglichst geraden Strecke die Kameraposition mit der Position des verknüpften Wagens abgleichen. Hier die Y-Position der Kamera auf die 57,67 des Wagens setzen. Nach ein paar Umläufen die Position der Kamera zum Wagen an etwa derselben Stelle wieder vergleichen. Ich denke, das wegen der Größe der Anlage Rundungsfehler bei der Positionsberechnung der Grund sind, die sich nach einer gewissen Zeit dann auch in der Verschiebung bemerkbar machen. VG, Hawkeye

Hallo @Bahnkater deine Kamera ist auf einem Wagen mitfahrend verknüpft, und folgt fixiert gleichzeitig der Position dem VT11 (Triebkopf). Deshalb erfolgt bei Kurven natürlich eine relative Bewegung des VT11(Triebkopf) zum Standort der Kamera in x,y-Richtung und somit bewegt bzw. dreht sich die Kamera, um weiterhin den Triebkopf VT11 im Visier zu haben. Ist das die Bewegung der Kamera die du meinst? Das hast du doch selbst so eingestellt. Da aber der Drehpunkt der Kamera nicht das Zentrum der Kamera ist, nimmt man eine seitliche Verschiebung war. Auf gerader Strecke dürfte aber alles wieder in der "normalen" Position sein. Ist bei mir zumindest so. VG, Hawkeye

Hallo Helmut, wieso ist der Radius mit R323 vorgegeben? Die normale Weichen haben einen Radius von 490. Und die Kreuzungsweiche von Henry aus dem Katalog hat den Radius 495,02 (siehe Beitrag von Little). Bei diesem Radius hat das gebogene Gleisstück bei einem Winkel von 13° in etwa die Bogenlänge von 112,8 und entspricht somit der Länge der geraden Gleisstücke. Deine DKW sieht so aus. Betritt eine Lok die Kreuzung schaltet die DKW auf Gerade , weil die Bogengleise nicht erkannt werden. Viele Grüße, Hawkeye

Hallo @helmutwes, bei der Kreuzung fehlen die Verlängerungen vom Radius zu den Enden der Kreuzung. Du kannst das prüfen, indem du auf „technische Zeichnung“ gehst. Rote Striche zeigen eine fehlende Verbindung an. VG Hawkeye PS: Die Geraden sind zu lang. Die Enden der gebogenen Gleisstücke müssen an den gleichen Stellen der Geraden enden.

Hallo @RoniHB, ob das Nichtandocken von Straßen an Kreuzungen ein Fehler ist, kann ich nicht beantworten. Aber den Grund, warum die Straßen nicht an Kreuzungen andocken, den habe ich gefunden. Straßen haben eine Spur 0 als Spline der Kategorie "Nur 3D-Modell" definiert. Kreuzungen haben diese Spur nicht! Alle Spuren sind vom Typ "virtuell" in der Kategorie "Straße". Deshalb vermute ich, das man mit dem Gizmo (gelbes Quadrat) am Anfang oder Ende einer Straße auch nur an ein Modell der gleichen Kategorie und dem gleichen Typ andocken kann. Ändert man in der Straße die Kategorie von Typ "Nur 3D-Modell" auf "Straße" dann erfolgt zwar ein Andocken, aber an der falschen Stelle. Vielleicht hilft das erstmal als Begründung und Erläuterung. Viele Grüße, Hawkeye

Hallo Easy, eine schöne Erläuterung. Wenn ich z.B. das folgende Ereignis ausführe, ist klar, das der ICE auch sofort losfährt. Jetzt baue ich eine Verzögerung von 10 s ein, damit genau dieser Zug, den ich ja genau hier definiert habe, verzögert abfährt. Und jetzt erwartest du, das ich mir darüber absolut im Klaren sein muss, das vielleicht doch ein anderer Zug zu dem Zeitpunkt losfährt, weil die Variable ja in der Zwischenzeit während der Verzögerung überschrieben werden könnte. Echt jetzt? Viele Grüße, Hawkeye

Hallo Easy, das ist doch mal eine interessante Information, die man erst mal realisieren muß! Nur dumm, wenn einem der Wert, den man benötigt, nicht als Auslöser zu Auswahl angeboten wird und man deshalb auf eine Variable in Verbindung mit einer Verzögerung zurückgreifen muß. Dann darf man sich über ungewollte Effekte auch nicht wundern. Ich denke, die meisten Nutzer hier haben sich darüber bisher kaum Gedanken gemacht. Gruß, Hawkeye

Hallo Neo, da hast du wohl recht, am Auslöser scheint es nicht zu liegen. Das stimmt aber nur bedingt, es hängt damit zusammen welchen Variablen-Typ man in Verbindung mit einer Verzögerung verwendet. Bezieht man sich auf eine "Objektvariable", bei der das Objekt auch der Auslöser im Ereignis ist, dann geht es. Wird jedoch eine Verzögerung in Verbindung mit einer Modulvariablen verwendet, dann können diese Variablen während der "Verzögerungszeit" überschrieben werden. Zur Verdeutlichung hier ein Beispiel mit 4 Variationen und 2 gleich erscheinenden Ereignissen. 5 Signale werden um 2s zeitversetzt auf "Fahrt geschaltet. Die Loks fahren nach der eingestellten Verzögerungszeit (Voreinstellung = 4s) los, um eine Überlappung der Verzögerungen zu erreichen. (Diese Einstellung der Verzögerungszeit kann mit (+)/(-) variiert werden.) Zum Schalten der Signale kann aus 4 verschiedenen Steuerungsvarianten ausgewählt werden, die eigentlich alle das gleiche Schalt-Ergebnis liefern sollten. Dazu gibt es 2 Ereignisse, um den Unterschied zu verdeutlichen. "Beispiel 1" mit Verwendung einer Objektvariablen und "Beispiel 2" mit Verwendung einer Modulvariablen. (Welches Ereignis benutzt wird, kann mit dem "schwarzen Taster" umgeschaltet werden.) Erwarten würde ich, das alle 8 programmierten Varianten das gleiche Ergebnis liefern. Das tun sie aber nicht. Hier das Beispiel. Test Verzögerungen.mbp Nur wenn keine Verzögerung (Verzögerungszeit = 0s ) existiert, dann verhält sich das Ereignis mit der Modulvariablen genauso wie das mit der Objektvariablen. => Modulvariablen in Verbindung mit Verzögerungen sind mit Vorsicht zu verwenden. Viele Grüße, Hawkeye

Hallo Sintbert + Neo, ja, um so einen Effekt geht es. Es scheinen dabei Variabeln irgendwie überschrieben zu werden. Ich versuche mal etwas einfaches reproduzierbares zu erstellen, ist aber nicht so leicht. Viele Grüße, Hawkeye

Hallo @Neo, In der EV werden Verzögerungen, die im gleichen Ereignis stehen, zur Unterscheidung mit einer (Zahl) ergänzt. Auch wenn man das nicht in der grafische EV sehen kann, so wird es bei der Umwandlung in Lua deutlich : Bei der Automatisierung von Abläufen mit Verzögerungen in der EV kommt es aber immer wieder vor, das "längere" Verzögerungen mit gleichem Namen wieder aufgerufen werden, bevor die zuerst aufgerufene Verzögerung mit dem selben Namen abgelaufen ist. Dadurch wird die erste Verzögerung überschrieben und es fährt z.B. ein ganz anderes, als das gewollte Fahrzeug los. Das zu verstehen, bis man diesen Fehler gefunden hat, dauert lange! Hier würde ich mir wünschen, das Verzögerungen intern zusätzlich automatische eine längere Zufallszahl verpasst bekommen, so das auch bei Aufruf des gleichen Ereignisses für andere Fahrzeuge innerhalb der Verzögerungszeit eine Unterscheidung bestehen bleibt. Oder alternativ, das man in der grafischen EV selber einen eigenen Verzögerungsnamen mit einer selbst gewählten Variablen (z.B. dem Fahrzeugnamen) setzten oder ergänzen kann, ohne auf Lua zurückgreifen zu müssen. Damit wäre eine Unterscheidung auch sichergestellt. Viele Grüße, Hawkeye

Hallo @BahnUropa, deine Texturdatei hat wohl eine falsches Dateiformat. Im deinem Verzeichnis liegt sie als .jpg vor. Viele Grüße, Hawkeye

Hallo Bahnland, das ist im Moment ja auch möglich. Interessant was dieser Einwand wieder für Wellen schlägt. Ich wollte mich mit meiner Anmerkung auch nur auf ein schon mal geführtes Thema beziehen. Ob diese Zukunftsvision von Neo möglich ist, wenn in Fahrzeugen bei der Definition der Seiten unterschiedliche Logiken angewandt werden, wage ich aber dann doch zu bezweifeln. Viele Grüße, Hawkeye

Hallo Bahnland, diese Logik ist aus deiner Sichtweise auch verständlich. Ich wollte nur darauf hinweisen, das bei den bisherigen Triebwagen anderer Modellbauer die Seite "links" immer aus der Cockpit-Ansicht definiert wurde und danach auch die EV-Steuerungen zum Öffnen von Türen programmiert sind. Bei diesem Modell und deiner Logik muss man jetzt die Seiten in der Fahrzeug -Variablen vertauschen. 1 = "Türen rechts" und 2 = "Türen links" , sonst geht die falsche Seite auf. Es liegt dann also nicht an einem Fehler in der Programmierung, sondern an der Reihenfolge der in diesem Steuerwagen definierten Variablen. Das sollte man dann auch wissen, damit man es (an der richtigen Stelle) auch berücksichtigen kann. VG, Hawkeye

Hallo @BahnLand, schönes Modell. Ein kleiner Punkt ist mir aber noch aufgefallen. Die Animationen der Seiten für die Einstiegstüren sind gegenüber anderen Modellen (auch deinen Personenwagen) vertauscht. Bisher war immer von der Cockpitansicht aus links das links, jetzt ist rechts das neue links. Viele Grüße, Hawkeye

Dann bleibt nur vor der Umwandlung eines Ereignisses in den Lua-Code eine Kopie zu machen und das kopierte Ereignis zu deaktivieren. Dann kannst du jederzeit auf die Kopie zurückgreifen. VG, Hawkeye

Hallo Thomas, doch das geht. Aber nur über einen kleinen Umweg. Erzeuge ein neues Ereignis und erstelle eine beliebige grafische Anweisung. Verschiebe diese Anweisung in das Ereignis, das du auf Lua umgestellt hattest und öffne es erneut. Dann ist es wieder in der grafischen Ansicht und du kannst die „Hilfsanweisung“ wieder löschen. Voraussetzung ist aber, das du vorher in Lua keine Veränderung am Skript vorgenommen hast. Viele Grüße, Hawkeye

Hallo, dann tippe ich mal darauf, das das Gleis (oder das an das du anschließen möchtest) in sich verwunden ist. Eine Verwindung wird im Fenster „Positionierung“ nicht angezeigt. Lösche solche Gleise und zieh dir Neue aus dem Katalog. Das geht schneller und ist sicherer, als zu versuchen eine Verwindung an Gleisen rückgängig zu machen, da du an jedem Gleis beide Seiten kontrollieren mußt. Gar nicht empfehlenswert ist, mit verwundenden Gleisen über das „+“ weiterzubauen. VG, Hawkeye

Hallo Brummi, warum immer nur „Marken“-Unternehmen? 🤔 Eine Variante in „Alt“ und „NoName“ wäre doch auch nicht schlecht. 😉 VG, Hawkeye

Hallo Walter, Ja, habe auch wieder was dazu gelernt. 😁 Aber zeig doch mal ein Bild, was du damit vorhast. Klingt auf jede Fall interessant. Lass uns an deiner Idee teilhaben. Viele Grüße, Hawkeye

Hallo Walter, Da irrst du dich. Dein Ziel ist es laut deinen Angaben, die Z-Position von 11,4 auf 12,8 also um 1,4 von den bestehenden Z-Position zu verschieben. Setze für die „10“ in Easy‘s Beispiel deine gewünschten „1,4“ ein und du hast dein Ziel ohne eine Maßstabsumrechnung erreicht. VG, Hawkeye