[HRQ] ES64U Taurus (1016/1116/1216)

Tut mir leid.
Vielleicht war meine Mail auch nicht überzeugend genug.
Ich dachte, ich hätte das Problem hinlänglich beschrieben und war auch erstaunt, dass man einen anderen Blickwinkel vertritt.
Vielleicht kann jemand, der sich im UKTS-Forum öfter herumtreibt einen Thread ausbuddeln (am besten mehrere), die das problem ebenfalls schildern?

Aber in einer Sache könnte er Recht haben, wenn ich das richtig einschätze:
Die ES64U2 und die ES64U4 greifen wohl auf gemeinsame Texturen (und Objekte?) zurück. Würde man diese 2 Loks voneinander abtrennen müsste der Kram doppelt auf Platte und in den Arbeitsspeicher, wenn ich das richtig verstanden habe. Z.B. gilt dies wohl bei Glasscheiben, Scheibenwischern, Pantos, etc...

Edit:
Nach dieser Logik düfte es demnach den Arbeitsspeicher betreffend NULL Unterschied machen, ob ich nun z.B. RSItalia aktiviere oder nicht, solange ich kein Objekt auf die Schienen stelle. Das wäre doch die Konsequenz daraus.

Edit2:
Demnach wäre das Aufsplitten der RSC-Inhalte seit TS2013 ja kontraproduktiv oder zumindest vollkommen unnötig

Zitat von Railworker12

Verstehe das auch nicht, was ist daran so schlimm die Ordentlich zu Strukturieren ?

Das Problem ist hausgemacht. Man erdenkt sich eine Struktur und muss diese dann beibehalten weil auch die Programm mit denen man die Modelle baut diese Struktur verinnerlicht bekommen müssen (zB bei 3dsMax). Das nachträglich zu ändern ist dann eben ein Aufwand den auch HRQ scheut. Einfach ein Planungsfehler oder eher keine Planung der zukünftigen Möglichkeiten das Produkt zu erweitern.

Aber wie siehst du das denn Maik?
Liegen dw-agency und einige andere, zu denen auch ich mich zähle, da einem Denkfehler auf?
Hat HRQ recht?

Und wenn HRQ da falsch läge, wie könnte man am besten argumentieren oder es am besten sogar anschualich "beweisen".
Ich überlege gerade, mehrere Tests zu machen, die dw-agency vermutlich schon 100x machte, aber diese sind halt nicht in Form von "Beweisstücken" dokumentiert.

Das ganze betrifft ja nicht nur HRQ, sondern es sind viele Provider, die da bedenklich sind, allen voran RSItalia. Es wäre daher schon sehr vorteilhaft, würde man etwas Handfestes haben, mit dem man argumentieren kann.

Wie würdest du das denn machen, gesetzt den Fall, unsere Vermutung ist richtig?

Ach, wie ich das sehe ist nicht relevant. Ich hab auch nur Theorien aufgestellt die auf meinen eigenen Beobachtungen basieren. Man müsste das eingehend testen. Es liegt aber schon nahe zu behaupten dass, je mehr Blueprintsets vorgeladen werden müssen, und das ist genau das was getan wird, es wird das Shema des Assets vorgeladen um es dann schneller in die Welt zeichnen zu können, um so mehr neigt der TS zum abstürtzen weil er eine Grenze erreicht. Worin diese Grenze nun genau liegt wird man kaum rausfinden ohne das ganze Ding debuggen zu können, was man bekanntlich als User nicht kann. Die Shematas werden defintiv geladen und im RAM vorgehalten, sonst wäre das Caching sinnlos. Wenn er erst das Shema lädt wenn ein Objekt auch verbaut wurde, brauche ich keinen Cache mehr weil ich dann eh alles neu zusammensuchen muss zur Laufzeit, bzw dann, wenn das Objekt in Renderreichweite ist, muss das Shema nachgeladen werden für das komplette Asset. Das macht so keinen Sinn, also wird es beim Start geladen. Das kann man auch sehen wen man mal den Rechner so zusammenbügelt dass er sehr langsam läuft und dann schaut was der TS beim Laden der Reihenvolge nach tut. Man muss dazu die Refreshrate irgendwie herunterregeln und das Game im Vollbild mit VSync laufen lassen. Und dazu ne Software die den RW Ordner überwacht und Änderungen aufzeichnet samt Timestamp (vorher den Cache löschen). Die ganzen Daten müssten dann gesammelt und verglichen werden. NUr warum sollten WIR das tun. RSC ist der Hersteller des Murks und sollen die sich doch kümmern dass ihre User zufrieden sind. Werden die nicht tun. So, who cares...

Klingt wie total plausibel, was du da sagst und deckt sich auch mit meinen Beobachtungen.
Ma gucken, vielleicht lass ich mal nen Ram-Monitor mitlaufen.

Zitat von Maik Goltz

NUr warum sollten WIR das tun. RSC ist der Hersteller des Murks und sollen die sich doch kümmern dass ihre User zufrieden sind. Werden die nicht tun. So, who cares...

Weil WIR mit den Problemen zu kämpfen haben und weil WIR schöne Addons möglichst schadlos benutzen möchten.
Weil WIR nicht nur den vorgekauten minderwertigen Kram von RSC wollen, sondern schnuckelige Sachen von vR (die ja hier glücklicherweise außen vor sind) und anderen Herstellern/Entwicklern guter Addons

Sorry für die derpressive Haltung aber ich muss jeden Tag aufs neue lernen dass ich eine Stufe zurückschalten muss um überhaupt noch Ergebnisse in diesem TrainMurks zu bekommen. Gestern hats die CabCam erwischt. Ich hab nun endlich rausgefunden wann diese Jelly-Cam kommt und die Lösung ist einfach: nicht an der Cam rumspielen sondern das standard Gewackel so lassen. Ist nur blöd, wenn man dann mit 200 über eine Stecke fahren muss die wie Hagen-Siegen gebaut ist. Das sind dann 3 Stufen zurück. Kennt jemand den Film "The Curious Case of Benjamin Button", da werden wir enden

Scrapix:
Du bist doch IT-Spezialist.
Also müsste es bei dir klingeln, wenn du dir verinnerlichst:
- 32-Bit-Anwendung
- Speicher-Limit
- Adressraum

Und?
Hat's geklingelt?

Dein Win7 benötigt nur 320 bis 480 MB Ram (2-3% von 16GB)?
Inkl. Dienste, Grafikkartentreiber und allem Zipp und Zapp?
Das will ich auch haben.

Leider ist beim TS bei 4GB Endegelände.

Und der Vergleich mit der GeForce4MX ist etwas *hust* abwegig.

Ich glaub dass die CPU auslastung gemeint ist ^^. die ist bei mir auch zwischen 0-8 %
Ansonsten hab ich ne "durchschnittliche" RAM auslastung im "leerlauf" von 3,8 von 8 GB

Zitat von Scrapix

Nur weil der Pfad auf der Platte ein X86 behinhaltet gehe ich heute dennoch davon aus dass alle neuentwickelten Porgramme heutzutage auch 64Bit fähig sind!

Wissen und meinen zu wissen, ein großes Problem generell. Ein schneller Blick in den Taskmanager zeigt dir auf, dass Railworks ein 32bit Programm ist. Und es wird eben als solches in der 32bit Schicht von Windows ausgeführt. Wäre Windows ein reines 64bit System ohne diesen 32bit Layer dann würde RW nicht starten. Ich glaube zu meinen dass es eine Freakversion von Windows gibt die diese 32bit Schicht nicht mehr hat und da kannst du das ausprobieren. Da passiert dann genau nichts ausser ner hübschen Fehlermeldung dass es nicht ausgeführt werden kann.

Zitat von Prelli

Leider ist beim TS bei 4GB Endegelände.

Das wäre toll, aber dahin kommt er nicht. Ich erwähnte ja shcon mal dass bei einem Speicherverbrauch von mehr als ~1300mb der RW kurz vor dem Absturz steht. Im normalem Betrieb gönnt er sich um die 1120-1250MB. Im Editor zB kann man sagen dass man speichern und beenden sollte wenn 1200 überschritten wird. Man kann auch schön sehen, wenn man eine Strecke beendet und ins Menü geht dass er statt auf den 430mb Startumfang auf 830 bleibt und das wiederum sorgt dafür dass beim direkten Laden einer neuen Strecke/Aufgabe der Speicherverbrauch über die magische Grenze rutscht und somit ein SBH nicht weit ist, nein sogar provozierbar wie bei scriptlastigen Fahrzeugen (der Grund warum man mit EL Fahrzeugen nicht ein weiteres Szenario starten kann ohne den TS neu zu starten). Hier liegt offebar ein Speicherverwaltungsproblem des TS-Core zugrunde. Man muss aber auch dazusagen, dass der Core aus 2006 ist. Und seit dem hat am eigentlichen Kern keiner was gemacht. WIr aber stopfen den TS immer mehr mit Zeugs zu und wundern uns dann dass nix mehr geht. Denkt an die Grenzen des MSTS. Die waren auch klar und deutlich und sind es immer noch weil der Kern nicht mehr das kann was heute zur Verfügung steht.

Keine Ahnung wo bei euren System der Hase Schicht macht, aber ich habe hier schon 3.5 GB RAM in einer Route für Railworks in Benutzung gehabt. Glaube auch nicht das der Taskmanager oder mein MEM Tacho lügt. Die meisten Strecken liegen meist bei bis zu 2.5 GB RAM im Bedarf.
SBH habe ich so wie fast nie. Kommt man aus einen Scenario sollte man nicht sofort auf "Wiederholen" drücken sondern einmal kurz ein anderes Scenario anklicken. Dann kann man ohne SBH das selbe Scenario noch einmal fahren. Oder eben ein anderes.

g'ice

SBH habe ich auch fast nie. Aber, ich habe im RW stets eine Speicherbenutzung von eben meinen genannten Werten. Geht er darüber, und das kann man teilweise eben provozieren, dann nimmt er sich nicht mehr Speicher sondern kontert mit einem SBH. Interessant daran ist vll noch zu erwähnen, dass diese "magische" Grenzen genau dem zugesicherten Speicherplatz in der Auslagerungsdatei entspricht für diesen Prozess. Ich komme aber bei keiner Strecke beim ersten Start über 1200mb. Habe eben den Marias Pass und eine andere Strecke geöffnet, die beide sehr hungrig sind, und es bleibt identisch. Steht alles auf Maximum, lief zwar im Fenster aber das ist dabei völlig egal. Auch im Vollbild kommt das selbe bei rum. Wenn man ohne den TS neuzustarten gleich ein weiteres Szenarion lädt, egal auf welcher Strecke, gibt es beim Laden extrem viele Page Faults, die dann, sofern der TS nicht schon abgenippelt ist, wieder verschwinden. Das ist also schon was derbst im argen mit der internen Speicherverwaltung des TS. Programme mit massven Page Faults neigen dazu relativ schnell abzustürtzen. Und genau das macht der TS dann eben auch. Mir scheint so ein wenig dass er im Kern darauf optimiert ist eine bestimmte Speichernutzung nicht zu überschreiten. Das würde sich auch so ein Bissel damit decken was 2006 an RAM im Rechner bezhalbar und üblich war.

Edit: hier würde im Übrigen das Thema mit dem Chache auch reinpassen. Die Dateien sind nicht groß, aber 130 Stück sind im Zweifel eben 50-xxx MB und wenn diese Grenze wirklich da ist, dann zählt jedes Byte.

noch ein Edit: die pak Dateien werden im Speicher garantiert entdrahtet und das XML Schema abgebildet. Ich gehe der Annahme dass auch hier die Serz.exe ihr Ding tut. Nehmt euch ne Bin die so groß ist wie eine der .pak Datein, serzt sie, und ihr wisst was er da wirklich laden muss. Das ist wie im PS mit jpg Dateien. Auf der Platte ist ein 10mp aus einer 1d3 etwa 5mb klein, geöffnet im PS hat es dann 50mb im RAM. Das gleiche passiert mit Text und eine XML Struktur ist Text.

Zitat von Maik Goltz

(...)Das wäre toll, aber dahin kommt er nicht. Ich erwähnte ja shcon mal dass bei einem Speicherverbrauch von mehr als ~1300mb der RW kurz vor dem Absturz steht. Im normalem Betrieb gönnt er sich um die 1120-1250MB. Im Editor zB kann man sagen dass man speichern und beenden sollte wenn 1200 überschritten wird.(...)

Ich weiß ja nicht, welche Strecken bei dir laufen, aber anspuchsvolle Routen i.S.v sehr vielen verwendeten Assets, wie z.B. die Routen von Keith Ross, belegen schon in Standardszenarien oder QD an die 2GB Ram, bei den von mir erstellten Free-Roams sind es auch schon mal fast 3GB! Nur wenn es auf diese 3GB zugeht, muss ich vorsichtig sein. Aus dem Spiel heraus gibt es bei mir keinerlei Probleme mit Abstürzen, nur ein Druck auf F12 oder Kamerawechsel KANN bei solchen Auslastungen zu Abstürzen führen, was ich aber auch auf meine nur 4GB Arbeitspeicher zurückführen möchte. 1120-1250MB sehe ich eher als Ausnahme denn als Regel - und wenn selbst das zu Abstürzen bei dir/euch führen sollte, scheint etwas anderes im Argen zu liegen!

Eine weitere Erkenntnix nach der seichten Analyse der .pak Datei eines Assets (eine Strecke) zeigt auf, dass es nix weiter ist als die Zusammenfassung aller .bin Dateien des Produktverzeichnisses in einer Datei. Alles drin und selbe Gesamtgröße + ein bissel Overhead. Die Sache dient also lediglich dazu die Zugriffe auf den Datenträger zu reduzieren, und das nur beim Start. Diese Zusammenfassungen werden aber mit 99.99%er Warscheinlichkeit komplett in den Speicher geladen und dort entpackt und vorgehalten. Wenn man sich im Perfmon die Dateizugriffe wärend des Fahrens eine Weile anschaut, sieht mann schön das AssetStreaming. Dazu dient diese Cache Sache hauptsächlich. Er kann so entscheiden wann er welches Asset laden muss und wieder entladen kann. Eigentlich eine tolle Sache. Man darf nur die Grenzen nicht überschreiten.

Zitat von RavenDark

Ich weiß ja nicht, welche Strecken bei dir laufen, aber anspuchsvolle Routen i.S.v sehr vielen verwendeten Assets, wie z.B. die Routen von Keith Ross, belegen schon in Standardszenarien oder QD an die 2GB Ram........1120-1250MB sehe ich eher als Ausnahme denn als Regel - und wenn selbst das zu Abstürzen bei dir/euch führen sollte, scheint etwas anderes im Argen zu liegen!

So ist es aber nun mal hier und ich fummel nicht erst seit Gestern mit dem TS rum. Das war schon seit ich darin rumbastel der Fall. Die WCML und auch die neue Strecke von Keith tuen genau das selbe. Hier ist auch nix im Argen. Ich habe grundsätzlich keine Probleme mit dem TS. Es gibt ein paar Stellen wo er sich ganz ohne SBH ins Nirvana begibt, aber das lassen wir mal aussen vor. Das könnte auch mit der Grafikkarte zu tun haben. SBH habe ich nur wenn ich zu lange im Editor rummache, oder eben ein Szenario direkt nach einem anderen lade, aber auch nur wenn vR EL dariin vorkommen (hier scheint der LUA Interpreter nochmal einiges oben drauf zu packen damits schneller zum SBH kommt).

EDIT: ok, noch ein Zusatz. Ich habe alles immer mit nur einem Zugverband getestet. Also stets gleiche Voraussetzungen. Und da ist es absolut unerheblich welche Strecke man lädt. In einem richtigen Szenario ist der Speicherverbrauch tatsächlich höher. Ich bekomme sowas nicht mit da ich eigentlich nur baue und teste und nicht spiele. Auf dem Marias Pass aber zB ist es nicht. Da ist bei jeder Aufgabe der Verbrauch gleich. Würde natürlich bedeutet dass bei vielen ungleichen Fahrzeugen der Verbrauch schnell nach oben schwappt. Und da ist dann natürlich auch schnell Ende im Gelände. Aber mit den SBHs hat das meiner bescheidenen Meinung nach nichts zu tun, ausser wenn man die 3.5Gb überschreitet die eine 32bin Anwendung haben darf. Das Grundverhalten das ich rauslesen kann ist aber immer das gleiche. Eventuell ist es auch nötig die Bereiche Strecke und Szenario dabei zu trennen. Zu viele .pak bei einer Strecke führen auch ohen Fahrzeuge zum SBH. Zu viele .pak bei einem Szenario führen auch bei guter Strecke zum SBH. Ist beides nicht gegeben, und man stellt zu viele Gleich Fahrzeuge in ein Szenario, ist eventuell der Dispatcher dann der Schuldige. Man sieht das Ganze müsste kleinlich sortiert und ergründet werden. Wer Zeit dafür hat, bitte