Beiträge von Maik Goltz

Ihr wisst aber dass man zum Nachbilden die Töne auch separat haben muss? Wer es schafft den Turbolader der Ludi ohne laufenden Motor hochzukurbeln und das erzeugte Geräusch entsprechend brauchbar und loopbar aufzunehmen, bekommt Geld dafür. Gleiches gilt für die Luftkühler und Fahrmotoren der Ludi, die man zum ordentlichen Nachbilden auch separat aufgenommen braucht, was recht schwer werden dürfte wenn die lok sich nicht bewegen darf dazu. Die anderen Geräsuche die man auch solo braucht, lassen wir mal aussen vor. Eine Diesellok im Sound nachzubilden ist sehr schwer weil die meisten Geräusch organisch sind und nicht synthetisch wie bei vielen Eloks.

Du nutzt aber dann hoffentlich ein externes Mikrofon für den Ton, denn der hörbare Lüfter bei diesen Modellen ist ein eklatanter Designfehler.

Beim nächsten kauf eines Spiels solltest du dich VOR dem Kauf informieren was es ist. Was du da gekauft hast ist eine Varianet von EEP (EisenbahnExeProfessional). Das wird hier im Forum nicht behandelt. Hier geht es um den Trains Simulator 2013 von Railsimulator.com. Was du früher bei deinem "Kollegen" gespielt hast war wieder was anderes, warscheinlich der Microsoft Trainsimulator. Das sind alles unterschiedliche Spiele die alle unterschiedlich funktionieren.

Wegen der Scipts wird es eher so sein, dass der die Speicherbereiche nicht immer frei räumt. Wenn er die Varaiblen dann erneut an der selben Stelle schreiben will, gibt es eben einen Konflikt mit der Speicheraddresse und das führt unweigerlich zur Ausnahme. Dagegen tun kann man im Script aber nichts. Auch kann es nicht mit dem Abrüsten zusammenhängen, denn die Variablen werden nur geändert aber nicht entfernt. Alle Variablen in den EL scripts werden initialisiert und bleiben über die Laufzeit auch bestehen. Es wird keine Variable entfernt so dass da keine Voraussetzuungen vorhanden wären die so ein Verhalten provozieren. Generell kümmert sich im RW Script leiner darum Speicher wieder frei zu geben indem man die Variablen oder Objekte zerstört. Das ist auch gar nicht so einfach in LUA sowas zu tun. Man müsste alle auf NIL setzen und hoffen dass der Interpreter und die Garbagecollection den Mist wegräumen. Es gibt aber zB gar keine OnGameEnds() Funktion in der man sowas realisieren könnte. Also daran kanns nicht liegen.

Zitat

RSC muss einfach mal den Mut haben und sagen : Sorry Jungs, dieses Jahr gibts kein großes Update, wir räumen stattdessen mal den Kern auf.

So lange bei RSC ein Börsenmensch das Sagen hat tut sich gar nichts.

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

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 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.

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

Ich tendiere dahin zu sagen dass es nicht zu retten ist. Der Grund dafür ist einfach, du hast die Strecke mit den fehlenden Infos offenbar abgespeichert. Anders lassen sich die fehlenden Einträge der TRs nicht erklären. Die darfst du dann alle per Hand wieder eintragen und das ist auch mit Optimismus nicht machbar (sei denn du hast nur eine einzige TR verwendet).

Zitat von Puma50XX

Irgendeine Chance, das zu umgehen?

Aus den Panto Controllern die AnimationID rausnehmen dann bewegt sich das ding nicht mehr hoch. Das kann aber zu Problemen führen wenn der Panto vom Script animiert und abgefragt wird. Da man die Scripte nicht einsehen kann, musst du das probieren.

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...

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.

Zitat von mwoehrer

wer sie zum Laufen bekommt hat was riesiges gut bei mir

Also mit 137 aktivierten Produkten in der RouteProperties solltest du eher sagen "wer sie am Laufen behalten kann bekommt nen Gummipunkt". Und wie soll das denn bitte Jemand testen wenn er sich erst die 137 Assets besorgen muss?

Seine Spacetaste am Handy hat einen Komma-Komplex

Zitat von Christopher Lange

Ich bin jetzt wieder darauf in der Bedienungsanleitung zum BR294-PlusPack von TrainTeamBerlin gestoßen. Dort wird diese Einstellung nämlich empfohlen.

Darin sehe ich aber keine Notwendigkeit. Was steht denn dazu warum das so sein soll? Die Framrate im TS zu begrenzen hat nur Sinn wenn man sich auf leeren Strecken rumbewegt und so die Framesprünge im Editor und vor allem die sinnlose Auslastung der Grafikkarte zu vermeiden. Aber im Spiel selbst ist das nicht nötig denn die Frameraten steigen selten so hoch dass man sich fürchten muss.

Ich habe die Lok extra umgebaut für die Herren Inselbewohner und das war dann umsonst.

Zitat von Reviersprinter

Der Pantograph müsste als Childobjekt definiert sein und könnt gegebenenfalls durch die entsprechende .xml Datei entfernt werden.

Der Panto ist kein Child (im Sinne der Blueprints). Die Animationen sind immer im Hauptmodell integriert und lassen sich nicht entfernen (optisch).

Das kommt drauf an was man betrachtet. Sinnlose Gimmicks die nicht von dem Parametern des TS2013 abhängig sind, die kann man theoretisch zu Hauf umsetzen. Aber simulationsspezifische Sachen sind bereits jetzt am Ende. Es ist auch derbe demotovierend, wenn man ständig nicht weiterkommt, weil der TS einem den Riegel vorschiebt und keine Lücke für eine Lösung offen lässt. Da kann man noch so tolle Ideen haben, sie sind einfach nicht umsetzbar in so einer beschränkten Umgebung. Viel mehr als bei der 143 oder 111 ist nicht mehr drin. Zumindest keine nutzbringenden Sachen. Die Neuentwicklung für die 120 kostet mich den Verstand. Die 103 wird wohl dann erst mal auf der Basis der 111 gebaut weil man so eher ein brauchbares Fahrzeug bekommt. Die wirklich wichtigen Dinge wie eine vernünftige Bremsansteuerung oder EBuLa sind fast unmachbar. Der Aufwand übersteigt den Nutzen vollkommen.

Da bei dem Fahrzeug keine Aufgaben (Szenarien) und keine QuickDrive Kompatibilität vorhanden sind, ist es seit der TS2013 Version auch nicht mehr in irgendeiner Liste sichtbar. Erst wenn eine Aufgabe installiert ist, in der das Fahrzeug vorkommt, kann man sie in der Einszespiler Listen sehen. Auf der vR Shopseite gibt es einen Aufgabenbereich in dem auch Aufgaben für die 120 zum Download bereitstehen. Auch hier im Downloadbereich gibt es Aufgaben für dieses Fahrzeug. Die Aufgaben werden auch mit dem Utilities.exe Programm installiert. Man kann natürlich auch eigene Aufgaben mit den Fahrzeugen bauen. Dazu sind aber unbedingt die Anleitungen des TS2013 zu lesen und zu verstehen.

1500€ tun es auch. Dicke fette Graka rein (für alle Fälle halt, wirklich was bringen tut sie nur wenn man das SSAA auf volle Pulle stellt), 4-Kerner mit 8 Threads (also ein i7, wer noch Lust drauf hat nimmt einen für den 1366 und enstrechende RAM Anbindung), schnelle SSD für Spiel und System, viel RAM (ab 8Gb, bei 1366er auch unbedingt als tripple Kits), und natürlich alles in 64bit und kein XP/Vista sondern 7 oder 8. Dan kommt sowas auch nicht zustande. Bis auf wenige Streckenabschnitte läuft es damit überall wie geschnitten Brot. Zwar langsam aber ohne Ruckler. Die wünschenswert hohen Framraten bekommt man mit keinem System bei aufwändig bebauten Strecken. Das liegt nicht am Rechner sondern am Core des TS der da eine eigene Leistungsgrenze hat. Daran könnten die Briten aber durchaus noch was ändern, sofern sie die nötigen Stellen im Quellcode ohne Doku finden (fähige Coder vorausgesetzt).