Hatte ich gemacht, brachte aber nichts.
Habe dann eben etwas in den Einstellungen geändert, postprocessing auf niedrig, Wasser auf hoch und Shader auf Standard gesetzt
und schon funktioniert es komischerweise.
Was mir jetzt auch aufgefallen ist, das viele Objekte, die im Trainz+ Build:132284 Built-in sind, in der137335 nicht mehr auftauchen und
auch nicht von der DLS zu laden sind.
N3V-SP-7
-
-
Was mir jetzt auch aufgefallen ist, das viele Objekte, die im Trainz+ Build:132284 Built-in sind, in der137335 nicht mehr auftauchen und
auch nicht von der DLS zu laden sind.Die sind noch da, werden nur nicht angezeigt (unerklärlich), nach einer Weile tauchen besagte Objekte im CM als fehlerhaft auf. (Vgl.#16)
Das hat nichts mit der eigentlichen DBR zu tun. Solange der Launcher geöffnet ist, checkt Trainz weiterhin installierten Content. Das ist sichtbar in "Clientprotokolle anzeigen", da passieren dann die merkwürdigen, teilweise unliebsamen Überraschungen.....
Da das Protokollfenster so schnell arbeitet, ist ein Lesen der Inhalte kaum möglich. Tip: Mit dem Windows-Editor eine Textdatei erstellen und dort den Inhalt des zuvor markierten Protokollfensters kopieren. Dann hat man in der Betrachtung der Textdatei genügend Zeit den Inhalt zu analysieren.
Ich habe da herausgelesen, daß es ein Lokalisierungsproblem des Built-In-Contents gibt. ("Prebuilt"-Ordner) - Der Patch legt einen neuen Link zu dem Prebuilt-Ordner in C:\Users\Benutzername\AppData\Local\N3V Games\ an. In der vorherigen Trainzversion hatte ich allerdings jede voluminöse Contentanlage mit ausgelagert. Irgendwie kann die Fehlerüberprüfung diesen Umstand nicht erkennen. Daher wahrscheinlich die enorme Verzögerung der Anzeige des "neuen" Built-In Contents.
Fazit:
Ich glaube man muß vor dem Patch, den zuvor ausgelagerten Content, nach C:\\Users.... zurückholen. Dann wären diese Fehler garnicht passiert.
Ich glaube, der Patch erkennt die Verlinkung zum Auslagerungsordner nicht und installiert sich an anderer Stelle, was zu Dopplern führt.
-
Ich verstehe davon eigentlich nichts, aber ich habe mal im Ordner "resources" nachgeschaut
dort gibt es einen Ordner "Prebuild" da werden aber nach Instillation keine weiteren Einträge vorgenommen.
Check mal im Windows-Dateiexplorer Install+Änderungsdatum im Trainz-Stammverzeichnis (mit Unterordnern), bei mir sind alle Contentdateien zum Zeitpunkt des Patches verändert worden. Daher kann ich deine Feststellung nicht so richtig deuten.
Die neuen Einträge sind im UnterOrdner von C:\Users\Benutzername\AppData\Local\N3V Games\.... hinzugefügt worden. Ich habe da 4 Unterordner: Tane;TRS19;TRS22;TrainzPlus. In dem betreffenden Ordner fängt der Patch an zu arbeiten. Wenn der Patch abgeschlossen wird bleibt eine TrainzPatch.DAT Datei übrig, in der die lokalen Änderungen stehen. Schon daraus ist ersichtlich, daß der neu hinzugefügte Built-In Content nicht den alten Built-In Content (bei mir in der Ablage) ersetzt hat. Ich muß allerdings gestehen, das ich den neuen Installationsort der Built-In Dateien bisher noch nicht gefunden habe, weil ichdie technische Lokalisierung in der DAT-Datei nicht wirklich verstehe.
Ich bin aber überzeugt, das diese Dopplung, die von mir genannten Fehler zu verantworten hat.
Da ich TRS22PE erst eine Woche zuvor installiert hatte, hat sich noch nicht viel Zusatzcontent angesammelt. Ich werde die gesamte Prozedur wiederholen, ohne jedoch den Content auszulagern. Ich habe noch 80GB auf C: frei, das sollte für diesen Test reichen....
-
Zu früh gefreut, Programmierte Züge bleiben in interaktiven Stationen mit Ladebefehl stehen und fahren nicht mehr weiter - TrainzPlus 137335! Diesen Fehler konnte ich in 132284 mit dem älteren Fahrer-Setup beheben. Da jetzt die unmögliche Version -25:1580 Built-In ist, fällt mit dazu keine Lösung mehr ein.
Edit:
Gleiche Map, gleiche Aufgabe trifft obiges Problem auch bei TRS22PE Build 137315 zu....
-
primat VIELEN DANK an Dich und Beko für eure stets umfangreichen Tests bei neuen TRAINZ Updates.
Das spart einem selber viel Zeit und eigenen Ärger.
l.g. Christian
PS: Mein Trainz stürzt noch immer regelmässig ab nach kurzer Zeit, wenn im Baumodus durch die Bodentexturenauswahl scrolle. Hab noch keine Lösung gefunden wie ich das reparieren kann. Kann im Moment keine Map bauen. Leider zeigt die letzte Datensicherung den gleichen Fehler. Bin im Moment etwas ratlos.
-
Zu früh gefreut, Programmierte Züge bleiben in interaktiven Stationen mit Ladebefehl stehen und fahren nicht mehr weiter
Kann ich nicht bestätigen.
Habe in einem Test Kohletransport per Bahn und Schiff, Containertransport und Personenverkehr
alles mit be / Entladung und wiederholen durchlaufen lassen, keine Probleme.
Nachtrag:
Es gibt scheinbar nicht mehr die Funktion "delete missing assets"
-
Entschuldigung, ich habe mich etwas unpräzise ausgedrückt. Es geht um Passagierbetrieb. Wendezüge mit 2 und mehr Loks z.B. auch Triebwagenzüge verharren im Ladebefehl. So zumindest in einer Testmap+Session, die im TRS19 noch einwandfrei funktionierte. Ebenfalls in den TRS22 und Plus-Versionen 132284/285 mit einem älteren Fahrersetup -25:1534 z.B. - Der Fehler steckt meineserachtens im Fahrersetup -25:1580 welches die neue Fahrerkategorie KI-Lokführer beinhaltet. (Ich glaube es existieren Videos die den Unterschied der Lokführer-Setups in TrainzPlus zeigen, werde das mal raussuchen)
Als "delete missing assets" noch vorhanden war, führte dieser Aufruf bei mir zum Programmabsturz
Edit: Ich sollte euch noch mitteilen, daß ich solche gravierenden Fehler seit Anfang 2026 an N3V gemeldet habe
-
Nach den Patches kann ich nicht mehr den Editor 2.0 aufrufen. Die jeweilige Trainzversion friert sofort ein.
Ursprünglich wollte ich mir das Umlernen ersparen und mich garnicht erst mit dem neuen Editor beschäftigen. Deshalb hatte ich von Anfang an die Grundeinsterllung in den Standard-Editor geändert. Es gab aber eine Situation die mich gezwungen hat den Editor 2.0 zu verwenden. Siehe dieses Thema: "Änderung der Darstellungsdistanz von Gräsern & Co.". Die dortigen PBR-Texturen lassen sich ausschließlich nur mit dem Editor 2.0 bearbeiten.
Ich habe N3V bereits darüber informiert. Bleibt also Abzuwarten, ob der Finalpatch diese Problemlösung beinhalten wird.
Bin gespannt, wie die Lösung aussieht. Wenn ich mich erinnere, daß N3V nach der Fehlermeldung des asynchronen Auseinanderlaufens der Spielzeit zur Realzeit, die Sekundenanzeige aus dem Spiel entfernt hat, statt dem eigentlichen Problem auf den Grund zu gehen, wäre ich nicht überrascht, wenn der Fehler bestehen bleibt....
-
Beko
Zitat:Es gibt scheinbar nicht mehr die Funktion "delete missing assets"
Versteckt sich unter Routendaten validieren -
Danke für den Hinweis, das klappt.
Nach den Patches kann ich nicht mehr den Editor 2.0 aufrufen. Die jeweilige Trainzversion friert sofort ein.
Ich habe den 2.0 mal aufgerufen, bei mir läuft es normal.
-
Meine bisherigen Testergenisse zu sp7:
+ etwas bessere Performance,
- Nach installation des sp7 arbeitet TRS ohne Meldung, (Validierung?, Precache?), bei mir etwa 1 Stunde bei 100% CPU-Auslastung
unbehobene Fehler seit TRS19 sp4
- Portale: häufige Entgleisung bei Ausfahrt aus Portalen, Züge mit Steuerwagen oder mit Loks an beiden Enden fast immer
- SPAD: über 130 km/h bremsen die Züge nicht korrekt ab und überfahren rote Signale. -
Kann Euch nur empfehlen den Surveyor 2.0 als Editor zu benutzen.
Das sind vielleicht einmalig 14 Tage Umgewöhnungszeit, dann wollt Ihr nie mehr zurück zum Classic.
Allein die ganzen Möglichkeiten welche durch die SCRAPBOOK Funktionen entstehen beschleunigen den Mapbau enorm.
Klar, wer danach sucht und fündig werden will, der wird auch etwas finden was Ihm am Classic besser gefällt.
l.g. Christian
-
Build 137315 (TRS22PE) nach dem Ausbau der interaktiven Staionen, habe ich den Halt per Marker+Türöffnenbefehl geändert. Jetzt bleibt zwar kein Zug mehr hängen, jedoch schließen die Türen nicht mehr. Das trifft den gesamten Personenfahrzeugpark mit interaktiven Türen. Bevor Beko wieder erklärt, das bei ihm alles funktioniert, hier ein Screenshot aus der Testmap:
-
Welcher Halt+Türöffnenbefehl (KUID) ? Fehlt eventuell der Befehl zum Türschliessen vor der Weiterfahrt ?
Peter
-
Der den ich bisher immer verwendet habe, der bis jetzt auch immer funktionierte: "Lade Passagiere" KUID2:192081:5:2 von Brummfondel. Die Türen werden nach der im Kontextmenü ausgewählten Wartezeit geschlossen, dann geht die Befehlsverarbeitung zum nächsten Schritt. Da gibts keinen separaten Schließbefehl.
Bei mir Haltepunkt auf freier Strecke 10 Sekunden, Überholungshalt in Bahnhöfen mindestens 2 Minuten. Der im Screenshot sichtbare Zug kam aus einem Überholungshalt von 2 Minuten. Der Vorrausfahrende Schnellzug hielt 10s und fährt ebenfalls mit geöffneten Türen. Weitere Tests haben ergeben, das es generell so ist. Diese Session habe ich in 5.7 neu erstellt, da bei der Ursprungsversion 5.6 mit maßlosem Overspeed gefahren wurde. Diesen Fehler konnte ich mit der neuen Session beheben.
Was ich überhauptnicht verstehe, wie ein Tfz schneller fahren kann, als die Enginespec zulässt?
-
Kann Euch nur empfehlen den Surveyor 2.0 als Editor zu benutzen.
Das sind vielleicht einmalig 14 Tage Umgewöhnungszeit, dann wollt Ihr nie mehr zurück zum Classic.
Allein die ganzen Möglichkeiten welche durch die SCRAPBOOK Funktionen entstehen beschleunigen den Mapbau enorm.
Klar, wer danach sucht und fündig werden will, der wird auch etwas finden was Ihm am Classic besser gefällt.
l.g. Christian
Ergänze um die Zentimeter genaue Versetzung von Objekten (nicht da direkte Platzieren, sondern bei Versetzen)
-
Mein Senf dazu:
Ich nutze nur die Invisible-Station für Bahnhöfe und dort nur die einzelnen.
Heißt: Jedes Gleis hat seine Invisible-Station, der Vorteil ich kann jedes Gleis als Fahrziel angeben
und dort wird nur der belade Befehl erstellt. Soll ein Zug länger halten reicht eine Wartezeit.
Türen öffnen und schließen nach dem Beladen.
-
Fahren in deiner Session auch ca.20 Züge im Takt über diese von dir genannten Stationen? - Einzeln funktioniert alles meistens. Das Zusammenspiel mehrerer Abläufe im Mehrzugbetrieb bringt die Probleme. So ein Passagierwechsel-Halt kann 99x funktionieren und 1x nicht, Das zerstört dieses 1x die gesamte Session. Ich habe auf mehreren Maps Automatiksessions die immer gleich ablaufen müssten! Tun sie aber nicht. Es ist eine Willkür des Programms, Fehler an den verschiedensten Stellen passieren zu lassen. Tritt ein und derselbe Fehler mehrfach auf, habe ich ihn als Fehler benannt. An der Session kann es nicht liegen, wenn ich Glück habe, läuft auch mal alles fehlerfrei. Leider kann man die Ursachen sporadisch auftretender Fehler nicht finden. Man kann nur Vermutungen äußern, die man anhand von Erfahrungen angesammelt hat.
