Posts by Maik Goltz

    Das stört mich auch bei den Einheitsloks, von vR, die fahren zu "weich" das Schaltwerk kann nur Stufen, das ist keine Ost-Lok mit Überleitungen und co, sprich die Zugkraft soll springen und zwar wirklich SPRINGEN und nicht hochlaufen, real "springen" 110, 111, 151 und deren Familien auch.


    Kurz, wenn das Schaltwerk sagt (anzeige im Führerraum), Stufe ist eingelaufen, dann ist sie das auch und die dementsprechende Spannung am Fahrmotor liegt auch an, womit auch die Zugkraft SOFORT anliegt.

    Tun sie eigentlich alle auch. Ist minimal "ausgerundet" der Vorgang, damit die Lok nicht springt als wäre sie aus Pappe. Woran siehst du, dass die Stufen nicht "hart" einlaufen? Am Ammeter? Der ist nur Fassade und dient nur der Soundsteuerung und Anzeige, aber er zeigt nicht den tatsächlichen Strom an den Motoren an.

    Es geht um die Relevanz. Es ist doch vollkommen irrelevant was zuerst kommt. Der gesunde Mensch kauft doch nicht nach der Prämisse ein, sondern danach, was er gern haben möchte. Also echt. Was ist nun, wenn beide am selben Tag erscheinen? Hast du dann ein unlösbares Problem, das dich in tiefe Depressionen oder schlimmeres stürzt? :rolleyes:

    Das ist kein Schatten, das ist der sichtbare Alphakanal. Scheinbar den Alpha falsch gewählt oder falscher Shader. Der Alpha muss 1bit sein, also schwarz oder weiß, keine Graustufen. Graustufen-Alpha machen bei diversen Shadern Problem (ist oft abhängig von der Blickrichtung zum Objekt).

    Wenn man die drei Positionen auswertet kommt man etwa auf eine Kachel im Bereich Rummelsburg-Karlshorst und Lichtenberg (dieses geografische Dreieck). Die Freeze Positionen decken sich mit der Idee des Kachel Nachladens, denn sie liegen alle nahezu perfekt an einer Kachelgrenze, welche das Nachladen triggern. In Strausberg das erklärt sich jetzt nicht, aber das ergibts sich eventuell von selbst, wenn man den Fehler findet.


    Ich würde es mit dieser hier versuchen:

    Wenn man zwischen Ostbahnhof und Warschauer Str

    Dem Berliner ist zwar klar wo das ist, aber im Kern nutzt diese Positionsangabe jetzt gar nichts. Es ist abhängig davon wo der Origin der Strecke in Relation zum Fehlerort sich befindet.

    Der Fehler tritt nicht auf, wenn das Szenario direkt im Ostbahnhof startet und man bis Ostkreuz das Gegengleis befährt. Wenn man jedoch weiter westlich startet, tritt er auch auf dem Gegengleis auf, und zwar an der gleichen Stelle, an der man auch auf dem Regelgleis den Freeze bekommt.

    Das sagt mir als Laie, dass es eine Kachel in der Gegend OK - FI sein muss. Wird die Kachel beim Start direkt geladen, was bei Start in OSB der Fall wäre, dann scheint sich der Fehler nicht bemerkbar zu machen. Wird sie erst im Laufe der Fahrt geladen, kommt der Fehler zu tragen. Das sagt jetzt noch nicht viel aus, aber es grenzt extrem ein. Ein erstes Indiz wäre jetzt zu ergründen, was genau sich an der Stelle wo der Freeze passiert, befindet (in Relation zum Kachelgitter mit Blick auf die Sichtweiteneinstellungen und die Tatsache ob DT verwendet wird oder nicht).

    Einen weiteren derartigen Freeze gibt es auf den Ferngleisen stadteinwärts kurz hinter Charlottenburg.

    Ich habe auf der gesamten Strecke noch keinen Freeze westwärts bekommen, egal auf welchem Fahrtweg. Sie scheinen nur in Richtung Osten aufzutreten (möglicherweise nur Zufall).

    Definitiv kein Zufall. Das ist ein Muster was sich abzeichnet. Was ist wenn man in CHS startet? Kommt der Freeze dann auch bei Fahrt Richtung Osten? Wenn nicht, greift die Theorie eines Kachel gebundenen Objects schon mal. Um die genaue Kachel zu finden, müssen entsprechende weitere (nervige) Tests angestrengt werden.


    Ich habe ja mittlerweile die Stadtbahn V3.11 upd4 weiter gebaut . Der freeze kommt da im Außenring S42 vor Storkower Str. vor und wenn

    ich auf dem gleichen Gleis in Richtung Südkreuz fahre, vor Hermannstr .

    Mit diesen Angaben hast du doch einen perfekten Satz Koordinaten zur "Triangulation" der anfälligen Kacheln.

    Die Strecke für die Tonne, oder kann man da noch was machen.

    Die Frage lässt sich so nicht beantworten. Dazu müsste sich Jemand mit der Strecke beschäftigen und den Fehler suchen. Dass das eher unmöglich erscheint, dürfte klar sein, aber man kann ja nie wissen.


    Du musst auf jeden Fall mehr generische Tests machen. Du scheinst mir immer nur bestimmte Szenarien zu fahren. Ich hab hier nicht alles gelesen, aber bist du mal nur mit einem einzigen einfachen Fahrzeug da lang gefahren? Also nicht die 481 oder sowas benutzen, sondern was super einfaches. Da würde man zumindest schon mal rausfinden, ob das an den Fahrzeugen liegt oder an der Strecke. Danach, wenn der Fehler bleibt, würde ich alle Assets, die nur Optik sind, entfernen aus den Ordnern (verschieben), auch die Gleise (aber nicht die Trackrules). Ist der Fehler dann weg, Stück für Stück diverse Gruppen von Assets wieder reinschieben und testen. Anders bekommt man das nicht raus.

    Hier wird ja vll. was rumspekuliert. Das größte Problem der Diskussion ist, dass die Spekulanten sich gar nicht mit dem TS auskennen. Alles nur Mutmaßungen, ohne Gehalt.


    Die Schilderungen von Mumphi deuten darauf, dass es nur an drei Dingen liegen kann. Entweder ist ein Script nicht 64bit tauglich (was durchaus sein kann, wenn darin "sonderbare" Dinge verwendet werden), oder ein Asset mit Sound verursacht es. Dass es nur in eine Richtung auftritt, oder je nach Richtung an unterschiedlicher Stelle, sagt mir direkt, dass es ein Asset auf einer Kachel sein muss (vor allem dann, wenn keine anderen Züge rumstehen oder fahren). Da Kacheln unterschiedlich geladen und entladen werden, kommt es zu dieser Verschiebung je nach Richtung. Es werden mehr Kacheln in Bewegungsrichtung geladen als hinter einem entladen werden. Und wenn man die Sichtweite oder ein paar andere Settings verstellt, verschiebt sich das Problem abermals. Rauszufinden auf welcher Kachel genau das passiert, ist sehr mühsam.


    Da der Freeze auch auftritt, wenn alle Objekte entfernt wurden (so hab ich das verstanden) liegt wohl aber Fall drei vor, ein Defekt in der Gleisanlage, der sich nur in 64bit bemerkbar macht. Auch das kann vorkommen, wenn die Gleise, in dieser Menge und wharscheinlich über Jahre hinweg mit vielen Änderungen, verlegt wurden. Das verhält sich wie mit Szenarien, an denen man zu lange rumbaut und zu viele Änderungen in der Zeit an verwendeten Assets passieren. Das ist zwar im Grunde unlogisch, da sämtliche Assets ja eigenständig und stets neu geladene Dinge darstellen, aber es ist eben doch so. Wo und warum das passiert, ist bis heut ein Rätsel. So ein Szenario kann man nur wegschmeißen und neu bauen. Das "könnte" auch für die Gleisanlage gelten.


    Ja, alles auch nur Spekulation, aber aus Sicht eines durchaus versierten Entwicklers (jaja, das sehen manche anders).

    Das muss man differenzieren bevor man es an den Pranger tackert. Es gibt zwei Methoden die Geräusche in Drehgestelle zu verbauen (für Schienenstöße aber nur eines). Man hängt die Sounds in den dafür vorgesehenen Bogie Sound-Proxy (nur hier gehen Schienenstöße generell), diese werden aber durch das View-Frustum im Ein- und Ausschalteverhalten gesteuert, was zum abhacken führt wenn man aus bestimmten Winkeln auf den Zug schaut oder er vorbei fährt. Die andere Methode ist, alle anderen Sounds, abseits von Stößen, in separate "normale" Proxies zu packen und wie anderen Sound zu steuern. Diese werden nicht durch die Sicht gesteuert, sondern nur durch die angegebenen Parameter (Activation distance, Attenuation, Volumes).

    Es darf kein 3000 € High-End-Gamer-PC vorrausgesetzt werden, um grafische Basisfunktionen flüssig darstellen zu können.

    Lass dir sagen, dass auch ein High-End HEDT Rechner Lotus nicht zum rennen bekommt. Das ist absolut nicht Rechner abhängig, das ist ein Engine-Problem. Ich wage zu behaupten, dass die TS1 Engine, die viele als veraltet ansehen, deutlich besser ist als Lotus und vor allem besser skaliert. Was Kuju damals programmiert hat ist schon gewaltig und gut. Und nicht vergessen, die TS Engine ist nicht mal fertig und dennoch besser als so viele andere "Simulations-Engines". Ich habe auch mal an Lotus geglaubt und es auch am ersten Tag gekauft. Aber die Ernüchterung kam schnell, sowohl beim Spielen als auch beim Versuch die Editor-Tools zu verwenden, die einfach unterm Strich extrem unpraktisch sind.

    "Problem" ist halt, aus Entwickler-Sicht, dass diese Aufrüstvorgänge zu implementieren mehr Zeit braucht, als alles andere zusammen. Es ist nur umständlich machbar, mit all den kleinen Texturschnipsel-Fetzen die man ein und ausschalten muss (die auch alle im RAM hängen, ob sichtbar oder nicht), dann die Logik die man in Lua dafür programmieren muss (LUA im TS ist wegen vieler fehlender extra APIs nicht wirklich gut dafür geeignet). Der TS bietet nur marginale Debugging-Möglichkeiten an (kein Debugger an sich). Das macht die Fehlersuche in so einem Konstrukt fast unmöglich. Und Fehler passieren bei sowas immer. Locker 50% der Zeit bei der Entwicklung solcher Features im TS gehen drauf für Debugging von "unerklärlichen Vorgängen" weil der TS es nicht mitmachen will, oder es schlicht nicht kennt. Vom Rest der Zeit gehen dann 50% drauf für Testerei (sofern man denn testet). Bleiben also 25% der Entwicklungszeit für die anderen Dinge wie Fahrverhalten, Sound, Modell und Texturen über. Prominente Beispiele für dieses Missverhältnis sind RSSLO Advanced Fahrzeuge, der Railjet (meiner Meinung nach), die 146.2 von Niclas und viele andere "Feature packed" DLCs. Es gibt aber auch Beispiele die halt überhaupt aufzeigen, was man machen kann, wenn man Jahre an Zeit hat oder generell keine Fertigstellungsterminziele. Und im TSW ist das alles nicht anders. Der TSW kennt noch weniger im Kern als der TS. Man kann halt alles irgendwie herstellen, aber auch das braucht sehr viel Zeit und das ist ja der Punkt hier überhaupt. Es braucht Zeit die auch Matthias nicht gewillt ist einzusetzen, da es sich für ihn nicht auszahlt. Etwas das ich ja schon immer, zum Unmut Aller, predige, wenn auch gegen dicke Wände. Die meisten User setzen sich da rein und wollen losfahren. Die wollen nichts aufrüsten, die wollen einfach nur fahren. Dass Aufrüstvorgänge ein Problem sind, zeigte sich mir damals mit der 103. Ulf kam damit nicht zurecht und "meckerte" halt rum, dass das zu kompliziert ist. Nur deswegen gab es dann die Schnellaufrüstung (eigentlich nur für Ihn da eingebaut, damit er mal damit fahren konnte). Letztlich drinnen geblieben auch für die Kunden. Aber der Mehraufwand, diese Schnellaufrüstung jedes Mal an die neuen Fahrzeuge anzupassen, ist einfach immens gewesen. Deswegen flog der Krempel dann mit der 101 endgültig raus. Sonst hätte man kein DLC mehr fertig bekommen.


    Viel Gerede (meinerseits) und für einige sicher wieder nur Zitat "Bullshit", aber was solls. Was gesagt werden will muss gesagt werden.

    Aber das habe ich schon richtig verstanden, dass davon nur die guten Gleise betroffen sind?

    Mit "gut" hat das wenig zu tun. Das liegt bekanntlich im Auge des Betrachters. Die HK-Gleise sind eben etwas aufwändiger in der Geometrie wegen der KPO6 Dinge. Ein Ribbon-Container kann nur eine gewisse maximale Anzahl von Geometrie-Scheitelpunkten verarbeiten (warum auch immer). Dieser Wert wird aber überschritten, wenn das Ribbon länger als 500m wird, weil die Holzgleise so viele Scheitelpunkte haben durch den ganzen Kleinkram da drinnen. Der Fehler oben "vxCount < VX_BUFFER_SIZE" sagt das quasi. VX = Vertex. Die Abfrage ist gegen den Buffer maximal Wert. Quasi ein If(VertexCount < MaxVertexCount). Die wird ein false und da der TS keine sonderbar integrierte Fehlerbehandlung hat, schmiert er dann eben mit einer unhandled Exception ab.

    Definitiv ein Problem mit der Ribbon-Länge. Ein Ribbon hat im TS nicht länger als 500m zu sein. Im Normalfall sollte der TS auch nach 500m selbsttätig trennen. Leider gibt es hier und da "Legetechnicken" die das umgehen, um vll. schneller bauen zu können und Zeit zu sparen. Das birgt aber diverse Probleme. Dabei gibt es dann oft einen Render-Bug im Gleis (eine nicht schließbare optische Lücke). Und der Vertices-Count im Ribbon Container steigt über das Limit, wenn die Gleise üppig gebaut sind, was hier dann das eigentliche Problem ist. Die Gleise funktionieren einwandfrei, wenn man die Grenzen einhält. Das ist eines der Dinge, die ich damals als erstes gelernt habe, bei der Nutzung dieser Gleise. Und die waren damals auf der Mosel viel fetter als sie es heute sind. Dennoch war es kein Problem damit zu legen. Tauschen ist eh kein Vorgang der vorgesehen ist. Das kann, muss aber nicht funktionieren.