Beiträge von Maik Goltz

Discord Einladung
Trete unserem Discord-Server bei (klicke hier zum Beitreten).

    Ah wat, das ist doch allet keen Problem. Paar Gleise hingefummelt (irgendwas ausm Kuju Ordner), paar Signale drangestellt, Häuser und Bäume aufs Grün gepinselt und ab dafür. Dauert nur 2 Wochen, egal wie lang. Dass die Strecken alle immer 2-4 Jahre brauchen um fertig zu werden liegt nur daran, dass die Kaffeemaschine so langsam ist.

    Da hast du eben einfach Glück gehabt. Ich habe nun schon mehrfach Fehler entdeckt. Gerade erst wieder, wo ich dran bin in jeder Kachel der Rollbahn diverse Änderungen außerhalb des TS mit XML-Tools vorzunehmen. Es passiert also sogar beim bearbeiten von Scenery. Die Fehler sind selten und entstehen scheinbar auch aus unterschiedlichen Situationen heraus. Genau ist das nicht zu erkennen. Aber sie passieren und zerstören zumindest diverse Szenarientypen inkl. QDs und eben auch Tracks und Scenery. Wobei das bei der Scenery nicht auffällt, da der TS nicht ladbare Knoten einfach übergeht, also verwirft. Bei Dingen die von der Track-Infra abhängen aber geht das nicht und er stürzt sofort ab. Alles meine Beobachtungen seit es die 64bit Version gibt. Er zerschießt sogar quasi on the fly Gleisanlagen, die im TS2018 erstellt wurden und nie im TS2019 bearbeitet worden sind.

    Warum das denn ? Der alte Microsoft Train Simulator hat es geschafft. Da wird doch allemale der TS das auch schaffen.

    Naja, im MSTS war eine Kachel eh auf 1000 Objekte begrenzt. Damit würde man jetzt aber keinen hinterm Ofen vorlocken. Wenn man so baut, wie das jetzt möglich ist, dann kann man das Ruhrgebiet vergessen. Da stößt man großteils schon an die Grenzen wenn man noch an der Bahninfrastruktur ist. Da mag ich gar nicht erst an Häuser und Bäume denken. MAn müsste sowas extrem ausgedünnt bauen, um überhaupt ein benutzbares Ergebnis zu erzielen und das gefällt den Leuten dann sowieso nicht, weil zu schlicht ausgestaltet. Also eher unwahrscheinlich dass sowas gebaut wird, zumindest nicht als Payware. Der Wupperexpress für den MSTS kam auch erst, als die PayWare Era schon am Ende war und braucht dann auch noch Jahren um halbwegs fertig zu sein. Bin damals selbst auch darauf rumgefahren und fand die Ausmaße der befahrbaren Gleise schon üppig. Aber genau weil ich den Wupperexpress kenne, kann ich sagen, dass man das im jetzigen TS nur schwerlich bauen kann. Maximal in verminderter Qualität.

    Da kannst du nichts machen. Das Szenario ist defekt. Ein neues Problem seit dem TS2019. Wenn du das Szenario auch nur einmal im 64bit TS gespeichert hast, dann kann das passieren. Hatte ich jetzt schon mehrfach. Es passiert nie sofort. Es dauert, bis sich der Fehler manifestiert. Deswegen momentan nur in 32bit Szenarien bauen. Fahren kann man die dann meist auch in 64bit ohne Probleme. Aber bauen in 64bit ist zur Zeit gefährlich.

    Mir ist auf gefallen, dass alle Strecken von RSC diese merkmale aufweisen. Alle anderen funktionieren. Dieses Problem hatte ich schon letztes Jahr gehabt.

    Würde dafür sprechen, dass es was mit den AP Dateien zu tun hat. Eventuell ein Programm installiert, dass bissel zu restriktiv Dateizugriffe blockiert?


    Wenn man die AP entpackt, sollte man danach natürlich die AP löschen, sonst greift er dennoch darauf zu und wenn der Zugriff blockiert wird, dann ist das Ergebnis eben nicht anders.

    Ein Flirt sollte der entsprechenden Regelung nicht unterliegen. Bei den Loks geht es da ja eher um Anpressdruck auf kurzen Wege. Hebt man 2 Stromabnehmer zu nah beieinander, dann drückt es den Fahrdraht weiter hoch und eben auch schnell zur Seite, was mit der herabgesetzten Geschwindigkeit vermieden werden soll. Beim Flirt sind die Stromabnehmer im Zweifel mehr als eine Kettenwerk-Länge (>80m) auseinander und somit eher unproblematisch (zumindest in Deutschland).

    Momentan ist es aber nun mal so, dass die 64bit Version erhebliche Probleme aufweist und alles was mit der Gleisanlage zu tun hat, irgendwann auch zerstört. Szenarien haben auch was mit der Gleisanlage zu tun. Nämlich in erster Linie die Positionen auf selbiger. Weichen diese zu stark ab, aufgrund von Prezisionsfehlern im Code, dann kommt es im Dispatcher nun mal zu Fehlern bis hin zum Versagen, womit das Szenario nur noch in Abstürzen endet. Wie bereits gesagt, DTG weis darum und arbeitet wohl auch wieder daran, diese Fehler zu beheben. Abwarten und Tee schlürfen. Momentan ist das alles eher ein unschöner Zustand für alle Beteiligten.


    Die roten Balken haben damit aber nach wie vor nichts zu tun. Erkärung, was diese bedeuten, steht jetzt schon mehrfach hier drin und daran wird sich nichts ändern.

    Sehe ich nicht so! Da ja Schuster Signale verbaut wurden, werden falsch platzierte Signale und Trigger, die verbaut wurden, mit einem roten Balken gekennzeichnet!!!! Siehe Bild. Die Strecke ist voll davon..... :thumbdown:

    Rote Türmchen sagen gar nichts aus. Nur weil davon ein paar erscheinen, heist das absolut nicht, dass da was falsch verbaut ist. Diese roten Türme sagen lediglich aus, dass ein Link um mehr als +-90° zum Ursprung des Objektes ausgerichtet ist. Das passiert auch in engen Kurven mit normalen Signallinks, wenn die Kurve eben mehr als 90° verbogen ist. Die Türmchen die du da siehst, gehören zu den GPA und LZB-Triggern, nicht aber zu den Signalen.

    Besagte stelle lässt mich keinen Zweifel daran haben, dass dort alles korrekt verbaut/gebaut wurde. Auch die Gleisanlage lässt keinen Fehler erkennen. Was also soll das denn nun auslösen? Ich gehe immer noch davon aus, dass das ein Fehler des TS selbst ist. Ein willkürlicher Fehler, der an bestimmten Stellen in einer Strecke zum tragen kommt. Ist garantiert wieder so ein Float-Precision Problem. Da kommt es bei bestimmten Zuständen einfach zu einer "Verschiebung" oder gar "Auslöschung" von Informationen/Parametern und das löst am Ende das Problem aus. Stellt euch das so vor, dass der Link des Signals intern eine UUID4 hat, oder eine normale 8 stellige ID. Gerät diese aus dem Gefüge, weil eine Zahl in einer Speicheradresse falsch behandelt wird, dann ist diese ID ungültig und wird wohl vom TS Dispatcher ignoriert. Somit ist es so, als wäre der Signallink an der Stelle nicht existent. Die anderen Links des Signals aber schon und somit kommt es da zur Blockade der Signalnachrichten, da Link0 eventuell fehlt und die Signalnachricht verschluckt wird. Klar, das muss man mal debuggen. Ich befürchte aber, dass uns das nicht weiterhilft, ausser die Erkenntnis zu bringen, was wir eh schon wissen. Nämlich dass der TS Fehler macht.

    Also die funktionieren in der 64bit bestens und zerschießen einem garnichts.

    Das stimmt eben so leider nicht 100%. Es passiert nicht so oft, aber es passiert. Warum und wann genau ist schwer auszumachen. Alles was man in 64bit macht und das irgendwie mit der Gleisanlage zu tun hat (Szenarien, QD, Signale und eben deren Trigger in einem Szenario), kann diese Fehler verursachen. Das haben wir nun schon genug festgestellt. Es ist traurig, ja, aber nicht zu ändern momentan. DTG weis ja um die Problematik. Ob man sie auch lösen wird/kann, weis von uns auch keiner. Alles was auch nur irgendwie die Gleisanlage betrifft, sollte man zur Zeit grundsätzlich nur in 32bit machen.

    Wer nicht so gerne wartet, löscht den Cache nur, wenn er selbst was in den Daten des TS reinkopiert oder was verändet hat.

    Selbst dann ist es normalerweise nicht nötig. Denn der Cache wird seit dem TS2015 (soweit ich das mitbekommen habe) automatisch erneuert, wenn Änderungen detektiert wurden. Es kommt vor, dass eine Änderung nicht erkannt wird, vor allem, wenn Daten älteren Datums rein kopiert werden. Dann sollte man den Cache des Ordners per Hand entfernen, also .pak Datei des Produkt-Ordners löschen, nicht alle von allen Produkten.

    (für die Performance kann man nix mehr tun bei einer 32-bit Anwendung

    Zur Performance:
    Die aktuellen EA-Versionen laufen nur auf 32-Bit, es wird aber zum Release auch zu 64-Bit gewandelt.

    Nur, um es nochmal in die Erinnerung zu holen. Performance hat mit der Bit-Architektur der Anwendung nichts zu tun. Die Probleme werden auch bei 64bit bleiben. 10k Draws bleiben auch in 64bit 10k Draws und müssen von der CPU einzeln behandelt werden. Optimierung beginnt auf einem anderen Level als der Bit-Architektur.

    werde mal @bahnjan schreiben.

    Ja und Jan schickt es zu mir. Also isses doch einfacher mir hier zuzuhören? Die Signale sind korrekt verbaut. Der TS macht seit dem TS2019 (32 und 64bit) irgendwas anders/falsch und daher kommt das Verhalten. Was genau es ist, das kann ich dir nicht sagen. Mehr als die Signale technisch korrekt einzubauen, können wir auch nicht leisten. Entweder DTG räumt den Ranz endlich auf, oder das bleiben eben so. Alternative, Strecke ohne Signale :)

    Das Problem mit dem Ausfahrsignal Lengerich Gleis 3 Richtung Osnabrück hatte ich auch. Das ging aber mit dem Signal-Fix von Maik weg - Siehe Post 181 in diesem Thread.

    Dieser Fix ist in der 1.1 der Strecke bereits integriert. Warum der Dispatcher die Blöcke nicht immer freigibt, ist mir ein Rätsel. Aber das scheint seit dem TS2019 eben ein neues Problem zu sein. Die Signale sind jedenfalls nicht falsch eingebaut.

    Hieß es nicht vor wenigen Monaten noch, daß der TSW noch so in den Kinderschuhen stecken würde, daß man sich keine Sorgen zu machen bräuchte, man hätte mit vR-Produkten für den "alten" TS viel Geld in ein totes Pferd investiert?

    Gilt auch nach wie vor. Der TSW ist noch am Anfang und der TS1 wird deswegen noch eine Weile leben. Sorgen würde ich mir da nicht machen. Und die gekauften Produkte verschimmeln ja nicht. Die kannst du weiter benutzen. Und ich denke auch nicht, dass Ulf jetzt aufhört für den TS1 zu bauen. Er braucht ja stets planbare Stabilität und die gibt der TSW nicht her. Mich aber stört das nicht. Ich stürze mich sehr gern in das halbfertige Konstrukt und werde versuchen, so wie ich es immer tat, ein paar nette Ergebnisse zu erzeugen. Das geht aus meiner unbedeutenden Sicht nicht, wenn man noch 2 Jahre wartet. Der TSW ist, wenn der Editor raus ist, sehr viel offener und lockt sicher auch viel mehr Leute (die was von UE4 verstehen) aus den Löchern, so dass man da nicht warten sollte, wenn man etwas erreichen will. Kann auch alles schief gehen. Bisserl Risiko ist eben einzusetzen. Ich denke das lohnt sich, für die Entsprechenden Entwickler und auch für die User, die die Ergebnisse dann nutzen.

    Ja, geht und ist nett, aber birgt ein großes Problem, vor allem bei so einem "fetten" Zug. Man trägt alle Varianten mit sich rum, egal ob die angezeigt werde oder nicht. Also alle Meshes und Texturen die da diese Funktion ermöglichen. Der CarCreator umgeht das Problem gut.

    T muss man immer drücken, um die Fahrscheinbesitzer in Wallung zu bekommen. Alternativ kann man ein externes Programm, das per API (Raildriver.dll) angebunden ist, das T für sich drücken lassen, wenn ein bestimmter Controller-Zustand eintritt (zB Taster für Freigabe der Türen). Direkt aus dem Script im TS geht das leider nicht, was reine Ingame-Lösungen immer zu der Doppelbedienung zwingt, oder man legt den Freigabetaster direkt auf T, dann drückt man ja T eh. Nur geht das dann wieder nur mit einem einzigen Taster (Tastenbefehl). Alles nur halb machbar und deswegen meiner Meinung nach kaum zu gebrauchen.


    Was mich etwas irritiert ist die Ansteuerung der Leistung/Bremse. Rückwärtsgang zum Bremsen? Echt jetzt? Man hat doch die E-Bremse als Mittel der Wahl zum elektrischen Bremsen.

    Schlimmer ist, das der Herr Goltz ALLE hier immer über einen Kamm schert. Thema z.B. die Preispolitik. Da sind vllt ein bis zwei Handvoll Leute die sich hier im Forum darüber auslassen, aber nein...wenn man die Beiträge von dem Herrn so ließt, gehören ja ALLE und jeder hier zur Meckerfraktion.

    Ich verstelle mich nicht um wer anderes zu sein. Ich bin eben so und entweder du lebst damit, oder eben nicht. Davon ab muss ich jetzt ja die Preise nicht mehr verteidigen :) Und du glaubst gar nicht, was für eine Befreiung es ist. Ich habe halt, genauso wie du in deine Aufgaben, sehr viel mehr Mühe in die Fahrzeuge gesteckt, als es andere je tun würden und verteidigte eben nur meine Arbeit, die ja auch den Preis ausmachen müsste. Da ich an den Preisen nie was machen konnte, musste ich eben meine Arbeit auch verbal verteidigen, wenn es schon nicht über höhere Preise machbar war. Legitim, oder? Läuft jetzt aber auch anders, wenn ich mal nen Preis wo dran mach. Deswegen bin ich da doch sehr entspannt eingestellt gegenüber dieser deiner "Ermahnung" :)


    Was den Werdegang der G6 angeht. Es gibt keine andere Lösung, als die Lok bei Steam neu zu vermarkten. Und dort muss diese in einen anderen Ordner, weil sich sonst der Kopierschutz (diese tollen wirren Dreiecke) auf die nicht bei Steam erworbenen Loks auswirkt und diese unbenutzbar macht. Selbiges ist bei der 018 von Eisenbahnwerk passiert. Die kann also nicht in den gleichen Ordner rein. Bei Strecken ist das eine Ausnahme. Die bekommen den Kopierschutz nicht, da DTG dafür alle Sources benötigt und diese eigentlich nie zur Verfügung stehen. Viel mehr oder weniger steckt da nicht hinter.