Beiträge von Maik Goltz

Es wird die selbe 60 Ziele ZZA wie bei der 145 und 146. Mehr geht technisch erst mal nicht. Wenn die Liniennummer separat eingestellt werden soll, reduziert sich die Anzahl auf 30 Ziele. Eine selbst beschriftbare ZZA würde unendlich Ziele ermöglichen, aber maximal 28 Stellen und feste Abstände und den Aufwand erhöhen, was die Entwicklungszeit verlängert, was den Preis erhöht...

Kann man, aber ich halte das nicht für nötig und es ist ein extra Aufwand. Dazu kommt der dann doppelte Speicherverbrauch der ZZA. Immer dran denken, alles was die ZZA anzeigen kann wird beim Szenariostart in den RAM geladen. Mag jetzt bei der 64bit Version halbwegs egal sein, aber auch Leute mit 32bit wollen das Ding spielen. Und zwei Versionen werden nicht gebaut. Also bleibts bei einer Farbe.

Das geht auch einfacher, aber es bleibt eben ein eingeschränktes System. Man kann dennoch nicht alles nach belieben da hinschreiben und die Zeichenabstände sind fix.

Nein, bisher wurden Stereo-Sounds genau so wiedergegeben wie sie auch in einem anderen Programm wiedergegeben werden würden. Da hat sich nichts dran geändert. Ich nutze das schon länger in den Führerständen der vR Loks und das hat immer funktioniert. Was nie funktionierte und auch jetzt nicht funktioniert, ist die Positionierung im 3D Raum. Da fehlt einfach die Komponente in der Sound-Engine, die die Stereobasis verschiebt (nicht gleichzusetzen mit Panning). Deswegen klingen Stereo-Sounds bei sich bewegenden Dingen auch so, als würde sich eben nichts bewegen. Es wird nur lauter oder leiser, aber die Basis verschiebt sich nicht auf Grundlage der Position zum Audio-Listener (Kamera, Spieler). Außerdem haben Stereo-Sounds noch immer das Problem, dass man mit ihnen kein Qued-Loop machen kann.

Stereo-Sounds klingen wie immer. Es gibt auch einfach nur sehr wenig, da die im TS schon immer blöd einzusetzen waren. Um Stereo-Sound auch für andere Dinge als den Fst zu nutzen, müsste die Sound-Engine des TS ein bissel mehr drauf haben. Was ihr da als "stereo" wahrnehmt ist einfach nur Mono-Sound der nun exakter im Raum positioniert ist. Die Attenuation Curve ist viel steiler, was den "Bauch" so dünne macht, dass jede Sound-Source nun exakt zu orten ist. Ich finde es nicht gut, weil das andere Probleme bringt.

Nein Jürgen, das hat da mit gar nichts zu tun. Auch ist da kein neuer Stereo-Sound im TS dazugekommen. Was da in der 64bit Version passiert, ist eigentlich ein Fehler, der zu dieser Wahrnehmung führt. Problem ist, dass die Attenuation nicht richtig funktioniert und somit die Start- und End-Dist der Attenuation so kurz beisammen sind, dass die Sounds nun extrem positioniert klingen. Das will man nicht unbedingt immer so haben (siehe Bogie-Sound Positionierung). Also it's not a feature, it's a bug.

Zitat von Rin Satsuki

Immer wieder lese ich von dem Problem mit den fehlenden Programmbibliotheken (.dll). Ich gehe fast davon aus, TS erkennt einen fehler und will diesen über die Debugroutine ausgeben, aber die dafür benötigte .dll fehlt und es kommt zum absturz. Bei mir läuft das ganze ohne probleme, hab aber auch da ich Visual Studio 2010 besitze eben jene Programmbibliotheken.

Diese besagte .dll wird aber nur vom CrashReporter moniert und nicht vom TS. Es passiert also erst nachdem der Crash schon passiert ist. Der Reporter würde wohl nur noch die Fehleranalysedaten bei bedarf speichern oder irgendwohin schicken.

Wurde ja alles schon x-fach probiert und drüber gegrübelt, was es nun sein könnte. Am Ende ist es etwas, das wir nicht beheben können. Und DTG scheinbar auch nicht. Die hatten ja auch schon solche Probleme auf ihren Strecken. Die beste Erklärung ist ein Shader-Problem oder noch besser ein Z-Sort Fehler. Man kann die Folien nicht konfigurieren, nur einbauen. Wenn die Folien mal einen Z-Index höher als das Gelände und mal niedriger als das Gelände bekommen, weil eben der Z-Index nicht festzulegen ist, dann kann sowas passieren. Machen kann dagegen von uns keiner was.

Und das hängt garantiert damit zusammen, dass die Tracks.bin außerhalb des Editors bearbeitet wurde. Etwas wovon ich schon immer abgeraten habe.

Richtig, mit Assets die dem Steam-Client nicht bekannt sind, passiert im allgemeinen nichts.

Kann beides sein. Es gibt aber Berichte, dass die Gleisanlagen zerstört werden, wenn man bestimmte Dinge tut. Nur wird das keiner von euch getan haben. Das letzte Log sieht ja verdächtig nach zerstörten DKWs aus. Aber wie die sich zerstören steht da natürlich nicht. Eventuell doch ein Core Bug.

EDIT: ich habe da noch einen zusätzlichen Verdacht warum das passiert. Wurde die Gleisanlage mit der Serz.exe deserialsiert, bearbeitet und dann wieder serialisiert? Da sind schon immer komische Sachen passiert und es werden values auf eine bestimmte Precision gesetzt die in der 64bit Version möglicherweise zu erheblichen Problemen führt. DAs nur so ein Gedanke.

Im Editor sind viele Dinge abgeschaltet oder laufen nicht an weil die ScenarioTime nicht voranschreitet. Da kann man also nix dran ablesen. Aber man kann es wohl auf falsch platzierte Signallinks zurückführen bisher. Da muss also derjenige der das gemacht hat, nochmal durch.

Zitat von alias203

Ich kann mir beim besten Willen nicht vorstellen, dass der TS oder Steam irgendwelche Dateien löscht.

Doch, das hat es schon immer getan. Wenn man die Assets aus der AP holt, in den Ordner etwas verändert, dann die Dateiüberprüfung angestoßen wird, dann bleiben die Ordner zwar stehen, aber die Inhalte sind weg und die AP Datei ist zurück. Da läuft irgend ein komischer Algo der zweifelhaft die Dateien überprüft. Das ganze System mit den AP läuft nicht so ganz rund würde ich sagen. Immer schön Backups machen wenn da drin rungefummelt wurde. Kann man DTG auch gar nicht vorwerfen, denn wenn man nicht fummelt, dann passiert auch nix.

Passiert denn der Absturz auch wenn gar keine Fahrzeuge drin sind, oder nur ein einziges simples ohne dicke Scripte? Bei dem Log würde ich auf 3 Sachen tippen.

1. Die Railtraction Plastekiste (nicht vorhandene Animationen per ExternalGeometryOutput ansteuern ist ein Garant für Abstürze)
2. die vermurkste Gleisanlage der Strecke ("ARGH" sagt alles )
3. die Assertions zu den Bogies, sowas mag der TS nicht und stürtzt ab (scheinen vom Lint zu kommen) .. (nicht die fehlenden Acheinträge ala bo01wh01, die sind ok und normal bei Jakobs-DG)

Gibt keine neuen Regeln für die Scripte. Wer bisher nicht sauber programmiert hat, der hat es auch bisher falsch gemacht. Gibt es leider viele von. Oft sind es nur kleine Schusseligkeiten, die dann eben jetzt zum tragen kommen können. Hat denn mal jemand den LogMate mitlaufen lassen wenn der Fehler auftritt? Ich würde es ja machen, aber diese Download-Arie um dieses "Update" zu installieren tue ich mir nicht an.

Klingt für mich einfach nach Fehler im Script selbst. Können wir natürlich nicht nachprüfen ohne Source. Der alte LUA Interpreter hat die meisten Fehler im Script ignoriert per Instanz und nur seine Fehlermeldungen abgespult. Die Sachen liefen dennoch weiter, nur halt im Hintergrund mit einer nicht sichtbaren Fehlerausgabe per Frame. Nun wird das in der neu kompilierten Interpreter Version für 64bit anders laufen. Der Hängt sich auf wenn zu viele Fehler in den Scripten stecken. Ziemlich einfache und logische Erklärung für mich. TSC ist hier also nocht nicht raus aus der Nummer Aber auch Schuster nicht. Es gilt nun beide System zu debuggen und den/die Fehler zu finden.

Das mit der max. Anzahl an Scriptinstanzen ist aus meiner Sicht Unsinn. Das werden andere Probleme sein, die in den Scripts selbst zu suchen sind. Es hat sich halt definitiv etwas geändert. Float wird nun als double behandelt und hätte ich nicht eine Woche lang krampfhaft auf DTG rumgehämmert und haufenweise synthetische Tests gemacht, dann würde eure Gesichter noch viel weiter runter hängen, denn es würden viele Fahrzeuge nicht korrekt arbeiten. Dennoch kann es zu "Vorkommnissen" führen, wenn "ulkige" Dinge im Script gemacht werden. Das kann bis dahin führen, dass der Interpreter eben aussteigt zur Runtime.

Zitat von nobsi

Also von 'nem vorher aufgenommenem Video? Das ändert die Sachlage ...

Nicht zwingend. Die Screenshots von Beriner079 zeigen das Zeug genau so, wie es wirklich aussieht im TS. Hier steht ein kalibrierter OLED als Bildschirm und die Farben in den meisten Screenshots, die man hier im Forum sieht, sind schrecklich verdreht, zu dunkel und allgemein hat es zu viel Kontrast. Das geht bis hin zu fast schwarzen Bildern die im Screen-Thread erscheinen. Das sah im TS2018 genauso aus wie im TS2019, weil sich die Änderung des Silverlining Wetters nicht auf die K-V auswirkt.

Die gibt es auch auf dem Desktop seit es Intel-CPUs mit eigener Grafik gibt. Wer dann vergisst im Bios die Intel-Grafik abzuschalten, der hat dann eben 2 Grafikkarten wie in den Notebooks. Nich wundert nur, dass der Treiber für ein Spiel die integrierte Grafik wählt. Da wird wohl etwas fehlen in der 64bit exe des TS, dass die Erkennung erleichtert.

Zitat von Seven of Nine

Sieht einfach bombastisch aus. Weiter so. Ich freue mich auf den ET425. Mit 64 Bit hat man sicher viel mehr Funktionen.

Nur weil wir jetzt bei 64bit float mit double precision haben (die keiner wollte) heist das nicht, dass wir auch double Zeit haben. Wie kommst du also darauf? Die Bit-Architektur war noch nie ein Maßband für Funktionsvielfalt im TS und wird es auch nicht sein.