[AS] Durchs Moseltal (Koblenz - Trier mit Bullay - Traben-Trarbach)

Coole Arbeit das PDF, fehlt nur noch die Framerate, letztendlich hängts natürlich auch am verwendeten Rollmaterial welches das Fass zum Überlaufen bringt ... vielleicht könnte man Performancefresser ein rotes Lable verpassen, wie bei den Energiesparlampen ;-)) Die können sich dann die Nietenzähler besorgen, die wirklich nur in ihrem Lieblingsfahrzug auf die Strecke wollen, soll s ja geben. Die framerate umgekehrt zeigt einem wo besonders "komplex" gebaut (bzw. auch kritische Kacheln) wurde und wo eben die schon genannten Kalorienbomben in den Texturen lagen (die ja nun offensichtlich etwas entschärft wurden).

Ganz nüchterne Feststellung: QD startet mit Railworks 3,4 GB aufn Tacho im Task Manager und zwei Minuten später war Feierabend (3,5 GB).
Die Nachtfahrten laufen jetzt aber normal

Hatte mir ein KI-loses QD gebaut für die erste Version der Strecke.
Jetzt nochmal von Trier nach Koblenz gefahren auf maximalen Einstellungen und Angekommen!!!
Vorher immer bei Bengel rausgeflogen (Vertex Buffer).
Werde mal ein paar KI züge von TTB aufstellen und sehen ob Ich noch bis Koblenz komme.

Bis jetzt läuft es einwandfrei - es sieht auch gut aus und die Einstellungen habe ich voll auf. Nur mit QD bekomme ich es nicht hin!
Trotzdem Danke an die gute Arbeit!!

QD von Koblenz bis kurz vor Ehrang einwandfrei, bei stabilen 30 FPS (zuvor undenkbar), nur dann kam der Kohlezug entgegen, das war dann zu viel des guten Aber riesen lob an das Team zur Überarbeitung! Läuft jetzt wesentlich besser als davor

Ja, es läuft flüssiger aber immer noch nicht mit allen Reglern nach rechts.
Ich lasse es mal so wie im Bild und fahre ich andere Strecken muß ich ja nur den oberen Regler nach rechts schieben.
Die unteren Regler denke ich machen nicht so sehr viel in der Qualität aus.
Jetzt müßte man mal ein von euch erstelltes Szenario testen.

Zitat von hansdampff

Coole Arbeit das PDF, fehlt nur noch die Framerate, letztendlich hängts natürlich auch am verwendeten Rollmaterial welches das Fass zum Überlaufen bringt ... vielleicht könnte man Performancefresser ein rotes Lable verpassen, wie bei den Energiesparlampen ;-)) Die können sich dann die Nietenzähler besorgen, die wirklich nur in ihrem Lieblingsfahrzug auf die Strecke wollen, soll s ja geben. Die framerate umgekehrt zeigt einem wo besonders "komplex" gebaut (bzw. auch kritische Kacheln) wurde und wo eben die schon genannten Kalorienbomben in den Texturen lagen (die ja nun offensichtlich etwas entschärft wurden).

Servus hansdampff,

die hatte ich sogar zu Beginn drin. Aber dann merkte ich schnell, dass bei tollen Strecken (Moseltal) die Framerate an komplexen Stellen (Güterbahnhof mit viel Oberleitung, bewegte KI-Züge) bei mir nie unter 40 - 50 sank. Die Abstürze kamen alle bei hoher Framerate. Ein sehr enormer Framedrop ist bspw. auf Köln-Koblenz. Wenn man von Koblenz-Lützel kommt und die erste Kurve im Gbf erreicht, lädt er nach, es geht runter auf 20 FPS, aber auf dem zweiten Bildschirm zeigt Process Explorer lediglich 2.850 RAM-Belegung. Und das ist völlig normal für diese Strecke. Anders auf Berlin-Wittenberg, die bei weitem belastbarste Strecke was RAM-Belegung angeht. Dort gibt es einige heftige Ruckler, die RAM-Belegung bleibt jedoch stabil bei max. 1.850, auch mit 20 KI-Zügen.

Bei Framerate-Drops taktet der Lüfter der Grafikkarte unmittelbar hoch, zumindest bei mir. Das sind also zweierlei Phänomene bzw. Gründe. Ich bin gerade bei Hamburg-Hannover, dann folgt noch die neue Moseltal-Version, und dann kann ich die PDFs - zumindest für meine Strecken - mal beibringen.

Gruß
Morphin

Nachtrag 1:
Ich habe eine Strecke begonnen, 50 km Länge, Kacheln 5x5, Google-Maps eingebunden, und ich beobachte parallel, was mit der RAM-Belegung passiert. Geht also nicht um die Strecke oder die Veröffentlichung oder so was, sondern darum, was der RAM macht, wenn ich die vielen Streckenbau-Addons dazuschalte; also jeweils einen dazu, Zeug drauf packen, beobachten, wieder löschen und so weiter. Auch da lassen sich mit Sicherheit Kandidaten finden, die man besser weglassen sollte. Und ab und zu guckt mal die Familie zur Tür rein, ob ich noch atme ...

Nachtrag 2:
Das erste QD-Szenario aus der PDF mit HRQ-Taurus und 8 IC-Coaches, Trier nach Wittlich, läuft durch auf STANDARD-Einstellungen. Die RAM-Belegung ist zwar im Grenzbereich, aber ich kam durch. Übrigens kann man durchaus sagen, dass die Taurus von HRQ einen großen Anteil an der RAM-Belegung hat. Die Lok ist nicht ohne und hat bisher die meisten Dumps erzeugt in Kombination mit eh schon wenig belastbaren Strecken.

Hallo Allerseits,

ich habe mich nun auch dazu entschlossen die Strecke zu kaufen. Gleich beim ersten gespielten Szenario, IC 132 nach Trier tut sich nichts..... Das Szenario läd und dann warte ich.Es kommen mir zwei Züge entgegen und dann warte ich vergeblich auf mein grünes Signal. Ich habe dann nach 10 Minuten abgebrochen, Cache geleert und das ganze abermals versucht, leider wieder kein grünes Signal.

Hat vielleicht jemand den gleichen Fehler und eventuell eine Lösung?

Gruß Jörg

Zitat von DRV110319

Aufgabe: IC 132 nach Trier
Nach Aufgabenstart erhalte ich die Fehlermeldung, dass das Gleis durch einen RB blockiert sei. (War auch schon in der alten Fassung bei mir der Fall).

Hatte ich hier bereits schon angesprochen. Ich habe jetzt die Abfahrtszeit des RB 12235 um eine Minute vorverlegt sprich von 18:10 auf 18:09 Uhr da war die Fehlermeldung dann weg.
Auf UKTS meine ich war auch zu lesen das man den Zugverband löschen soll was ich aber für Stuss halte.

Zitat von 1216.210

Eines hätte ich zu beanstanden. Bin grad das Szenario Geschmischtwarenladen gen Norden 2 gefahren und es war finster, also richtig finster.
Was ich damit sagen will? Keine Bahnhofsbeleuchtung und keine Beleuchtung von Häusern.(Zeitraum zwischen 17 und 18 Uhr)

Ebenfalls schon mal hier und hier angesprochen. Mit den TimeOfDay von H-H zb funktioniert das einwandfrei von daher können die Dateien von AS nur fehlerhaft sein.

Zitat von Jogibär

Hat vielleicht jemand den gleichen Fehler und eventuell eine Lösung?

Ja, habe ich auch, da steht der Fahrweg falsch. Da kann ich nicht helfen.

Zitat von 1216.210

Eines hätte ich zu beanstanden. Bin grad das Szenario Geschmischtwarenladen gen Norden 2 gefahren und es war finster, also richtig finster.
Was ich damit sagen will? Keine Bahnhofsbeleuchtung und keine Beleuchtung von Häusern.(Zeitraum zwischen 17 und 18 Uhr)

Hallöchen,

nun, soweit ich weiß schaltet der TS das Licht ja nach der Urzeit an und nicht nach der Dunkelheit.
Jetzt ist es so, dass bei Sonnenuntergang das Licht angeschaltet wird. Wenn jetzt ein sehr dunkles Wetter festgelegt ist, ist es eben schon vor Sonnenuntergang sehr dunkel. In Real würden die Lampen angehen, nur im TS nicht.

Wenn man das Szenario also bei klarem Wetter fahren würde, dann wäre auch der Zeitpunkt des Licht Einschaltens passend.

Sollte ich irren und es weiß einer das es anders geht, und wie es anders geht .... ihr wisst wie ihr mich erreicht

Das Licht richtet sich nach dem was in den TOD-Daten die in der RouteTemplate bzw in der Route-Properties angegeben ist.
Das Datum des Szenarios stimmt mit der Jahreszeit zusammen: 24.11.2014 und Herbst, wäre mal OK.
Jetzt Rechnet der TS den Sonnenstand ja aktuell nach diesen Daten und den Streckenkoordinaten.
Startzeit des Szenarios 17:16 h
Im TOD für Herbst ist der Sonnenuntergang für 19:25 angegeben.
Wenn jetzt der TS auch die Helligkeit nach Datum, Uhrzeit, Koordinaten rechnet, könnte der SU im TOD etwa zu spät sein.
Hier das Datum 24.11.2014 und den Ort (Koblenz) eingeben: http://www.datum-und-uhrzeit.de/?calculate=true
Damit wäre der SU um 16:31.
StS

Zu beachten gilt, dass das Szenario das 3D Wetter verwendet und somit die ToD Einstellungen der Strecke selbst zum Teil unwirksam werden. Leider wird die Zeit, wann das Licht eingeschaltet wird, wohl nicht beeinflusst.

Das mag so ja richtig sein, aber meines Wissens kann man nur pro Jahreszeit die Sonnenauf- und -untergangszeiten definieren. Und da ist für Herbst der Mittelwert von 19:25 Uhr gewählt.
Offensichtlich ist einfach das Datum ungünstig gewählt.

Meines Erachtens einfach eine Unzulänglichkeit des TS.

Mittelwert 19:25 ???
Lt. dem Programm für Koblenz:
Herbsbeginn: 21.10. : SU 17:24
Winterbeginn: 21.12.: SU 16:24
ich würde da 16:54 für den Herbst eintragen.
StS

Herbstbeginn ist aber am 21.09., nicht erst im Oktober. Trotzdem würde sich die Zeit dann maximal auf etwa 17:25 Uhr ändern, da gebe ich dir Recht.

Ich habe es mal auf meine Liste geschrieben, wir können da sicherlich nochmal was ändern.

Herbstbeginn ? Ich wollte nur den Sommer verlängern,
Falls Du wirklich nochmal was tun willst, Ich habs Dirs schon mal als Mail mit Bild geschickt, vermutlich Überlesen.
Vor allem in Koblenz extrem auffällig.
Die Marker gehen bis ans Gleisende und liegen unterm Prellbock. Damit überfahren KI-Züge den Prellbock,
die fahren immer bis Markerende! Sei froh, dass die Prellböcke keinen Kollisionskasten haben, sonst gäbs dauernd Zug ... hat die Strecke verlassen. So siehts nur doof aus.
Dann zusätzlich kontrollieren: die Links der Rangierzwerge liegen ebenfalls auf Markern. Das kann zu Problemen führen, Zug fährt bis Markerende und blockiert sein eigenes Signal. Marker auch da kürzen. (Editor: 8x Leertaste und man sieht grüne Linien auf gelben Markern enden).
StS

Ich hab da gestern was entdeckt ...

Ich habe gestern ein Szenario gemacht, in dem ein IR in Bullay - von Koblenz kommend - auf das Gegengleis (Bullay Gleis 1) fährt, um eine RB zu umfahren, die auf Bullay Gleis 2 wartet. Auf diesem wartet VOR der Einfahrt nach Bullay eine RB aus Traben-Trarbach. Der IR fährt also auf die Weiche (Uest Bullay Sued) zu, um wieder auf sein Regelgleis zu kommen, und die BR628 (will zu Bullay Gleis 7) steht so knapp vor der Kreuzungsweiche, dass es zu einer Kollision kommt. Grund: Das Gleissperrsignal sitzt ZU KNAPP vor der Kreuzungsweiche.