Neo

Es gäbe auch eine Skript-Bedingung. Aber generell ist der Zugriff auf die Zielliste etwas problematischer in der grafischen EV, weil sich hinter dem Ziel entweder ein einzelner Gleiskontakt, oder eine Liste von Gleiskontakten befinden können. Das kann die grafische EV aktuell nicht abbilden. Ich kann auch nur noch einmal betonen, dass ich selber den Anspruch habe, Straßenverkehr im Studio soweit zu automatisieren, dass solche komplexen EVs für das Steuern von Autos in Zukunft nicht mehr notwendig sind. Viele Grüße, Neo

Das Ziel ist in der Eigenschaft "target" eines Fahrzeugs enthalten. Viele Grüße, Neo

Nein, dieser Fehler steht damit nicht im Zusammenhang, hier arbeite ich noch an einer Lösung.

Für solche Zwecke empfehle ich andere Mittel, z.B. das Verschmelzen von Bodenplatten oder Grundkörper/Objekte zum Verdecken.

Hallo, aktuell ist das Setzen einer beliebigen Farbe geplant, eventuell löst das auch deine Probleme. Viele Grüße, Neo

Das erscheint mir als eine sinnvolle Verbesserung.

Eher nicht, die Aktualisierungen fanden nur zu bestimmten Zeitpunkten statt, z.B. beim Laden oder bei neuen/gelöschten Objekten.

Hallo, ich konnte durch eure Testanlagen sehen, dass verknüpfte Objekte sowohl beim Laden als auch bei der normalen Anlagenbearbeitung unnötig oft aktualisiert worden, was der Auslöser für die Abweichungen war. Das Verhalten konnte ich jetzt korrigieren, sodass nur noch dann Aktualisierungen bei verknüpften Objekten stattfinden, wenn das Referenzobjekt tatsächlich auch bewegt wurde. Die unnötigen Aktualisierungen fanden auch auf meinem System statt, allerdings gab es hier keine negativen Auswirkungen. Der Unterschied liegt im verwendeten Prozessor. Mein Entwicklungssystem arbeitet mit einer AMD-CPU, während die Probleme bisher bei Intel-CPUs beschrieben wurden. Die CPUs verwenden unterschiedliche Implementierungen beim Berechnen von Gleitkommazahlen, die sich dann in solchen Abweichungen "am Ende des Zahlenstrahl" bemerkbar machen können. Das Problem wird mit dem nächsten Update behoben sein. Viele Grüße, Neo

Hallo, ich habe neue Infos: Auch Hawkeyes verknüpfte Gleise zeigen bei mir auf Windows 11 keine Probleme, auch nicht auf einer Windows 10 VM. Ich kann das Problem aber auf einem Laptop reproduzieren, auf dem Windows 10 nativ läuft. Damit kann ich arbeiten. Der Vollständigkeit halber, könnt ihr mir bitte eurer Betriebssystem, verwendete CPU und Grafikkarte mitteilen? Viele Grüße, Neo

Hallo Hawkeye, ist es dir möglich, eine Videoaufzeichnung von dem Verhalten anzufertigen? Viele Grüße, Neo

Hallo, danke für eure zusätzlichen Experimente. Leider haben sie mich noch nicht weiter gebracht. Wenn ich die Anlage "Verknüpfte ZS3 - nach 20mal neuladen.mbp" von Hawkeye im Studio öffne, stehen alle Signale an der korrekten Position: Ist das bei euch anders? Viele Grüße, Neo

Hallo, noch ein zusätzlicher Hinweis: Ich habe Thomas gebeten, einen öffentlichen Beitrag zu schreiben, weil sich seine Anlage bei mir nach seiner Anleitung anders verhält als bei ihm. Nach mehrmaligen Speichern und Neuladen gibt es bei mir keine Verschiebungen. Es scheint daher noch andere Umstände zu geben, die zu dem Fehler führen, weshalb ich mich freuen würde, wenn auch andere Thomas' Anleitung folgen und ihre Ergebnisse hier mitteilen. Das könnte mir bei der Fehleranalyse helfen. Dass die Genauigkeit am "Ende des Zahlenstrahls" abnimmt ist soweit nicht schlimm, aber ich kann aktuell nicht die Situation reproduzieren, bei der Objekte nach dem Speichern und Laden eine andere Position einnehmen. Einmal positionierte Objekte sollten dort verweilen, bis sie explizit verschoben werden. Hier gibt es noch ein Problem, das behoben werden muss. Viele Grüße, Neo

Es handelt sich um eine optische Täuschung, im Modelleditor kannst du die einzelnen LOD-Stufen genauer betrachten. Viele Grüße, Neo

Hallo Hawkeye, die LOD-Umschaltung hängt vom Betrachtungspunkt ab, aber auch von der Modellgröße und einem kleinen Zufallsfaktor, damit gleiche Modelle sich ein wenig unterscheiden. Zu bedenken ist auch, dass der Bus fast 9 Jahre alt ist. Damals gab es noch ein anderes LOD-System im Studio, weshalb der Bus in heutigen Studio-Versionen solche Unschönheiten besitzt. Das Modell bräuchte eine Überarbeitung. Viele Grüße, Neo

Abgesehen von den Kopiermöglichkeiten in der EV solltest du beim Duplizieren auch die Möglichkeit in Betracht ziehen, Aktionen und Bedingungen soweit zu vereinheitlichen, dass sie gar nicht dupliziert werden müssen. Das wird dir helfen, die EV schlank und übersichtlich zu halten.

Das Löschen der mittleren Detailstufe geht mit einem Performance-Verlust einher, weil der Bus doch recht detailliert ist. Ich würde gern noch etwas abwarten, ob sich nicht vielleicht doch ein Modellbauer findet, das wäre letztendlich die bessere Option, weil dann das Modell auch mit der neuen Beschriftungsfunktion ausgestattet werden kann. Viele Grüße, Neo

Hallo Hawkeye, die LOD-Stufen schalten soweit korrekt um, hier hat wie Karl schon erwähnt der Modellbauer etwas zu stark optimiert. Im Programm lässt sich das Problem leider nicht beheben, weil die LOD-Stufen "standardisiert" sind, d.h. die anderen Modellbauer verlassen sich darauf, dass die Stufen in bestimmten Entfernungen umschalten. Hier kann leider nur das Modell selbst angepasst werden, @fmkberlin baut soweit ich weiß aber keine Modelle mehr. Als Notlösung könnte ich die mittlere Stufe entfernen, aber vielleicht hat ja ein anderer Modellbauer Lust, den Gelenkbus nachzubauen. Viele Grüße, Neo

Zur Info: Wenn du die Maus kurz auf der Auswahlliste für den Auslöser pausierst, wird dir eine kleine Erklärung angezeigt.

Hallo, der Timer steht bereits als Auslöser zur Verfügung. Da es sich bei einem Timer aber um ein zusammengesetztes Objekt handelt (aus historischen Gründen), besteht ein Timer eigentlich aus zwei Auslösern, nämlich dem Timernamen und dem dazugehörigen Ereignismodul. Du musst daher die Option "Timer (Erweitert)" wählen. Viele Grüße, Neo

Hallo Phrontistes, kann ich mir das Verhalten in deiner Anlage anschauen? Viele Grüße, Neo

Hallo Hawkeye, bin zwar nicht Götz, aber ich kann genau so schlau tun if not vehicle.variables["Wartezeit"] == true then ist nicht das gleiche wie if vehicle.variables["Wartezeit"] == false then denn wenn eine Variable nicht existiert, ist sie nil, und nicht false. Du kannst mit false nicht auf die Existenz einer Variable prüfen. Der erste Ausdruck funktioniert, weil: Eine nicht existierende Variable ist nil not nil wird zu true true == true Um deine Variable zu initialisieren, falls sie noch nicht existiert, solltest du folgende Zeile nutzen: if vehicle.variables["Wartezeit"] == nil then Viele Grüße, Neo

Ja, diese Strecke existiert, sie ist aber statisch, d.h. sie wird nur einmal bei der Zuweisung eines neues Ziels generiert. Der Startpunkt der Strecke verändert sich nicht mehr, wenn das Auto weiterfährt.

Hallo Hawkeye, das Problem mit so einer Funktion ist, dass sie potentiell eine unendliche Laufzeit hat, nämlich wenn es keine Verbindung zwischen beiden Kontakten gibt oder die Strecke dahin durch viele Abzweigungen zu komplex wird. Bei den Fahrstraßen gibt es entsprechende Abbruchbedingungen, wie z.B. die berühmten maximal 7 Abzweigungen, aber es kann bei langen Strecken entsprechend auch mal die eine oder andere Sekunde dauern, bis eine Fahrstraße aufgebaut ist. Für eine dynamische Steuerung in Echtzeit wäre das System nicht gut geeignet. Wenn dir der geometrische Abstand ausreicht, so wie von Phrontistes vorgeschlagen, wäre das die schnellere Lösung. Viele Grüße, Neo

Hallo, danke für die Meldung, ich werde den Fehler mit dem nächsten Update beheben. Viele Grüße, Neo

Eigentlich ist ja alles schon gesagt, inaktive Ereignisse unterscheiden sich beim "Kompilieren" nicht von aktiven Ereignissen, aber zumindest die Fehlermeldung kann ich in diesem Fall etwas verbessern, sodass auch bei Skriptfehlern das entsprechende Ereignis in der Protokollierung direkt aufrufbar ist. Viele Grüße, Neo