Beiträge von nobsi

hmmm ... vielleicht darf ich mal an die TS-Realität erinnern? Die drückst sich u.a. auch im Thread Welche-Strecke-braucht-der-Train-Simulator-noch aus
Einige Leute scheinen ja zu wünschen, Hersteller wie RSSLO durch Boykott aus dem Markt zu kicken. Ok, denken wir das mal weiter. Wer bleibt über? Jan Bleiss. Sonst noch wer? Aerosoft bzw Pad Labs? Noch. Aber so weit ich mitbekommen habe, will Aerosoft sich zurückziehen, weil man bei den derzeitigen TS-Streckenpreisen eh nicht überleben kann. VR? Nee, die gibt's als Streckenbauer nicht. Konstanz-Villingen wurde im Grunde von einem "Privatkonsortium" geschaffen, die weit mehr Aufwand reingesteckt haben, als sie jemals als Erlös zurückbekommen.

Die meisten User wünschen sich die Strecke vor ihrer Haustür. Wenn man RSSLO und ähnliche "verbannt", steht den ca. 10000 Streckenwünschen ein Output von maximal 1 Strecke im Jahr gegenüber ... also darf der durchschnittliche User 5000 Jahre auf "seine" Strecke warten.

Hersteller, die Masse statt Klasse produzieren, sind für die meisten User die einzige Chance, überhaupt jemals einen Wunsch erfüllt zu bekommen.
Und deswegen werden solche Strecken gekauft - manchmal verbunden mit der Hoffnung, dass irgend jemand was dran verbessert.

- glaubt etwa irgend jemand, dass, wenn man eine existierende RSSLO Strecke X nicht kauft, jemand anders dieselbe Strecke nochmal besser baut?
- glaubt tatsächlich jemand, dass, wenn man RSSLO "erfolgreich" aus dem Markt katapultiert hätte, jemand anders dieselben Strecken besser bauen würde? Ich sehe keinen. Stefan sicher nicht, SHG ist kein Streckenbauer, Jan Bleiss baut sicher keine ÖBB Strecken, und außerdem war da ja noch das Ding mit "Klasse statt Masse", weswegen ohnehin nur ein Bruchteil raus käme.
- oder träumt etwa irgend jemand davon, RSSLO durch Boykott zu besserer Qualität nötigen zu können? Ha ha ha, selten so gelacht. Mehr Qualität braucht mehr Kohle, nicht weniger.

@AlpenoStrand mir scheint, du hast meinen Beitrag nicht verstanden. Vielleicht hilft es, wenn du ihn nochmal liest? (ich meine lesen, nicht überfliegen)

Zitat von lol515

Es war nicht einmal der Tonfall irgendwie frech!

jein.
Also erstmal ist der Hinweis von @AlpenoStrand natürlich begrüßenswert (wenn er sachlich richtig ist, was ich nicht weiß).
Dumm nur, dass dieser sachliche Hinweis dann gleich mit einer Forderung nach Nachbesserung erweitert wurde. Vielleicht fällt jüngeren Generationen die Wortwahl gar nicht groß auf (könnt' ich mir zumindest vorstellen, wenn ich so beobachte, wie die sich oft gegenseitig anfauchen, scheinbar ohne es böse zu meinen). Aber für ältere kommt es unverschämt rüber.

Zitat von Gainmaster

Langsam könnte wirklich mal wieder eine Altbaulok von Vr kommen (BR141 oder BR150).

nix für ungut, aber unter "Altbaulok" versteht man eigentlich die Loks vor den "Einheitsloks" (zu denen BR 141 und 150 gezählt werden). In Beitrag 85 wurden einige genannt.
Aber ansonsten bin ich deiner Meinung

Zitat von Maschinenreiter

Weiss jemand, was beim aktivieren eines Developers im "blauen Quader" - Menü geladen wird? Muss man da schon aufpassen oder zählt es erst, wenn das Fahrzeug auf der Strecke steht?

Zunächst einmal nur der "Cache" (blueprints.pak) des jeweiligen Produktes (nicht Developers!).
Weiteres erst dann, wenn es auf die Strecke gestellt wird.

Zitat von Maschinenreiter

Dass der Speicher nicht mehr benutzter Kacheln nicht freigegeben wird, ist natürlich richtig schlecht. Das heisst ja wohl auch, dass der TS nicht nur ein 32bit Programm ist, sondern ein schlecht geschriebenes noch dazu

Das stimmt so nicht. Es ist sogar eigentlich gut geschrieben:
wenn die Sachen sofort wieder freigegeben würden, müssten sie vielleicht 2 Kacheln später wieder neu geladen werden. Das würde unnötig Nachladeruckler erzeugen, und es bestünde Gefahr, durch Fragmentierung den nutzbaren Speicher zu verringern.
Daher gibt der TS nicht mehr benötigte Assets nicht sofort, sondern erst nach einer gewissen Zeit wieder frei. Das kann man gut sehen, wenn man nach einem Memory-Peak mal auf Pause geht, und den Speicherverbrauch beobachtet.

Problematisch ist es vor allem, wenn man z.B. mit einem ICE full speed durch dicht bebautes Gebiet fährt: dann schafft der TS mit Mühe das Nachladen, aber nicht mehr das freigeben, so dass sich bis zum nächsten Bahnhofshalt (oder PAUSE!) alles im Speicher ansammelt.

voll krass @TrailDogRunner1909 ... back to the roots (oder auch: Beschränkung auf das wesentliche) ...
da muss die Reise hingehen im TSW!
Schließlich können die Gamer keine 300 € für ein Addon abdrücken!

@RW1969 KA-MA-Quickdrive hatte im Original etliche Probleme. Schonmal meinen damaligen Patch (im Download-Bereich) probiert? Vielleicht hilft er noch.

Albula Gleise verwendet das Kuju TrackBedRumble.
Albula Tunnel z.B. HS_Tunnel

@maku38 wie kommst du darauf? Allein in diesem Thread wurden schon jede Menge Strecken in NRW genannt.

Mal davon abgesehen, dass es viele User gibt, die das nicht alles zum 1001. mal wiederkäuen, nur weil mal wieder jemand einen wünsch-dir-was-chat gestartet hat, weil die vorhandenen ja nicht "neu" sind.

Hallo @Schoenbiehl

tja, Verständnisschwierigkeiten tauchen immer wieder mal auf.

Zunächst einmal wurde schon geschrieben, dass die mit serz aus .bin Dateien erzeugten xml Dateien immer noch zur "Asset"-Domäne und nicht zur "Source"-Domäne gehören. Der BPE bearbeitet nur Blueprints in der Source-Domäne, mit den Asset-xml Dateien kann er nichts anfangen.
Aus asset-Dateien erzeugte xml-Dateien sind nur nützlich, um abzulesen, welche Dateien man im BPE in neu erstellten Blueprints vermutlich eintragen müsste.

Zitat von Schoenbiehl

Immer dieselben Fehlermeldungen:

- Referenced provider does not match the provider of this file
- Referenced blueprint under different provider will not be exported

Du musst schon Fehler und Warnungen unterscheiden (siehe z.B. Beitrag 11)
Diese Warnungen sind vollkommen normal, und man legt es vielfach auch darauf an.
Als Hobbyist wird man für eine neue Strecke nicht gleich ALLES selbst machen wollen, sondern auch fremde Teile verwenden.
Z.B. kann man in einer eigenen Route Template natürlich zunächst ein Standard-Wetter aus dem Kuju Bestand eintragen.
Genau dann kommen diese "Fehlermeldungen" als Hinweise:
1. der Provider des Wetters (nämlich Kuju) ist nicht derselbe wie der Provider der Route Template (nämlich du).
2. aus diesem Grund wird der BPE, wenn er dein RouteTemplate exportiert, gar nicht erst versuchen, auch das Wetter im Kuju-Ordner exportieren
Wenn du auch ein eigenes Wetter-Blueprint erstellst (im selben Provider-Ordner wie die Route-Template, Produkt-Ordner kann unterschiedlich sein), würden diese Hinweise natürlich nicht erscheinen, und der BPE würde beim Export der RouteTemplate mit F7 auch gleich das Wetter exportieren (bzw überprüfen, ob es seit dem letzten F7 geändert wurde, und in diesem Fall exportieren).

Was den Zeitbedarf angeht (worauf auch @bernd_NdeM oben schon anspielte)
- als mit dem TS 2013 Quickdrive rauskam, habe ich monatelang getüftelt, was man tun muss, um das in eigenen Strecken verfügbar zu machen, und dabei auch in DTGs eigenen Strecken (die zu dem Zeitpunkt mein einziger Anhaltspunkt waren) grobe Fehler festgestellt.
Kurz bevor mein erstes Quickdrive (als Bestandteil der 3-Country-Corner-Route) rauskam, brachte DTG eine Erweiterung des Szenario-Editors, die das deutlich erleichterte und von meiner bereits begonnenen Anleitung konnte ich einen Großteil einstampfen.
- ich habe über ein Jahr an einem Bodentexturset gearbeitet, das einerseits für die vollständige Texturierung des gesamten Areals zu Beginn des Streckenbaus geeignet ist (für mich ein sehr wichtiger Punkt), und andererseits reibungslos mit der Distant-Terrain-Generierung funktioniert. Beides ist bis heute mit den meisten Textursets nicht der Fall.

Es ist vollkommen klar, dass sich jemand, der eine erste Strecke bauen möchte, nicht mit jahrelangen Vorarbeiten aufhalten will, bevor er die ersten Meter Gleis sieht. Aber die Erstellung einer eigenen Route Template in einen eigenen (Source-)Streckenordner mit dem BPE ist ein sinnvoller erster Schritt, der nur wenig Aufwand bedeutet, und gleichzeitig der eigenen Strecke eine sichere Basis gibt, an der man auch später noch leicht Änderungen vornehmen kann.

Zitat von Schoenbiehl

Dabei bin ich auf wesentliche Unterschiede zwischen beiden tools gestoßen [ ... ]

Treffend festgestellt.

Ist letztlich wie in der Entwicklung regulärer Software auch:
Wenn ein Programm korrigiert bzw. erweitert werden soll, nehmen professionelle Entwickler die erfoderlichen Änderungen in den SOURCE-Dateien vor (die auch in einem Versionierungsystem wie Git archiviert werden), kompilieren, testen, und liefern die neu compilierte .exe Datei aus. Sie fummeln nicht mit einem Hex-Editor an der alten .exe-Datei rum.

In gleicher Weise werden bei der Entwicklung für den TS die Blueprints im BPE bearbeitet. Der BPE hat immer den vollständigen Zugriff auf die Blueprint-xml Dateien, die hier auch ähnlich wie oben erwähnt in Git versioniert werden können. Der BPE hat auch - ähnlich wie allgemeine Software-Entwicklungssysteme - eine "Make" Funktionalität (F7), die auf Tastendruck gleich für eine ganze Ordnerhierarchie genau die Dateien neu konvertieren und von /Source nach /assets exportieren, die seit dem letzten Makt geändert wurden. Das spart enorm Zeit, wenn man tatsächlich einen echten eigenen Strecken-Source-Ordner hat. Außerdem ist z.B. die Änderung von Farben mittels RGB-Schieberegler (z.B. für die Farbe der Morgendämmerung oder der Distant Terrain Color) im BPE doch wesentlich anschaulicher als die Änderung von nackten RBG-Werten in serz-konvertierten Asset-Dateien.

Genau wie Hacker mit einem Hex-Editor in einem Programm für das sie keine Source-Dateien sondern nur die ausgelieferte exe Datei haben, manche Änderungen machen können (wenn auch oft nicht ohne Kollateralschäden), können auch TS-User, die von fremden Assets nunmal keine Source-Dateien haben, sondern eben nur die ausgelieferten "compilierten" Assets, mit einem Hex-Editor bzw einer Handvoll Utilities wie serz, rsbintool und einem xml-Editor einiges an den vorhandenen Assets anstellen.

Da hat Mike Simpson in den Jahren schon einiges geleistet, mit viel Trial and Error dieses "TS-Hacking" so zu verpacken, das recht viele User damit einige Wünsche umsetzen können. Aber eben immer auf der binary Seite (den Assets), den genau das war ja der Sinn: der normale TS-User hat ja keinen Zugriff auf Source-Dateien der Entwickler. Dieser Ansatz verdeulicht auch gleichzeitig, wozu RWTools gedacht war: für Änderungen an "fremden" Assets für den eigenen Bedarf. Denn man man keine Source-Dateien hat, ist das ja in den meisten Fällen ein Zeichen dafür, dass man auch keine Urheberrechte hat, die geänderten Assets weiter zu geben.

Zitat von Schoenbiehl

Schade, wenn es wieder mal nur mit try and error gehen muss, ...

stimmt so nicht ganz.

Es stimmt, dass die genannten DevDocs den TS Stand vor/maximal bis TS 2012 repräsentieren.
Spätere Erweiterungen sind in jeder Railworks-Installation im Ordner railworks/dev/docs dokumentiert.

Das betrifft sowohl die UI-Erweiterungen, als auch viele neu hinzgekommene Blueprints.

Zitat von Broflugo

einerseits heulen, dass man in ner Nische sitzt und nicht genug Kohle macht,

hier heult aber nicht vR, sondern einige User heulen, dass sie nicht genug Kohle haben

Zitat von Broflugo

Dann stellt halt persönliche Interessen zurück und macht den verdammten ICE EL, der wird sich verkaufen wie geschnitten Brot.

Schon mal im Forum Kommentare zu Neuerscheinungen gelesen? Da wird oft über "fehlendes Herzblut" gemeckert. "Herzblut" gibts aber nur bei Dingen die einem am Herzen liegen, und nicht bei solchen, die man widerwillig macht, um Kohle in die Kasse zu schaufeln.
Daher wäre es mir lieber, vR bleibt soweit irgend möglich bei Dingen, von denen sie überzeugt sind.

Bedauerlich.
Auch für mich, ich hatte mich auf speziell diese Lok sehr gefreut. Muss ich halt mit einer privaten "Pappschachtel" vorlieb nehmen. Ok.

Was ich aber ganz gruselig finde, ist, wie nun "alle" wie die Aasgeier über diese Facebook Gruppe herfallen, in der Hoffnung, eine Lok, die natürlich, wäre sie vollendet worden, Geld gekostet hätte, für Lau abzocken zu können .. der Tod sei gepriesen!

Eine geschlossene Facebook-Gruppe hat doch wohl vornehmlich den Sinn, auf eine - wie auch immer geartete - Fertigstellung hinzuarbeiten?
Die meisten die jetzt post mortem versuchen, Zugang zu erlangen geht es aber wohl nicht darum, sondern nur ums abgreifen. Jedem Trittbrettfahrer per Zugang zur Facebook Gruppe die Lok zu schenken, bedeutet die Entwertung der Arbeit des Verstorbenen (außer natürlich, es gibt begründete Indizien, dass er es so wollte). Ich wünsche dem Eigner der Gruppe eine glückliche Hand bei de Auswahl der Neuzugänge.

Zitat von Madison

Warum wird das eigentlich hier besprochen und nicht in der elitären Gesichtsbuch Gruppe? Updates sind doch ohnehin nur da zulässig da braucht man hier doch nicht mit anfangen.

Wohl wahr. Da wollen wohl einige mit ihren "Beziehungen" kokettieren (hey, ich konnte im offenen Sarg wühlen).

Zitat

Klar könnte man jetzt sagen, das vR vllt ein Rabatt machen könnt wenn man beide Paktete kauft

Könnte man, muss man nicht. Beide sind, jeder für sich ein vollwertiger Zug.
Es gibt keinen echten Grund, "alle" Varianten haben zu müssen, nur weil es sie gibt.
Wer Schuhe in passender Farbe zu jeder Hose haben will, muss halt viele kaufen. Wer das Geld nicht hat, kauft die Version, die ihm am besten gefällt.

Zitat von Gambrinus

Eigentlich keine gute Idee von VR, wenn ein Download nur funktioniert wenn man völlig ungeschützt ins Internet geht.

Muss man ja auch nicht ...
funktioniert z.B. mit Firefox und Kaspersky vollkommen problemlos.

Letztlich kann VR wenig daran ändern, wenn sich User selbst (gewollt oder ungewollt) austricksen.

achja: schööööner Zug
ich hab natürlich die LH-Version genommen. (Von der IC-Version hätte ich ohne die ganzen Diskussionen hier im Forum nicht mal gewusst , dass es sie gibt ...)

Zitat von Madison

Ehrlich gesagt gefällt mir der Kollege @Schoenbiehl [...]

treffend bemerkt, er ist einer der wenigen, bei denen man echtes Interesse am TS wahrnimmt.

Zitat von Schoenbiehl

Ich bin erstmal bedient von der Software RWTools - auch wenn sie semiprofessionell ist -

ich gratuliere, dass du recht früh in deiner Beschäftigung mit dem TS zu dieser Erkenntnis kamst.
Unter "semiprofessionell" verstehe ich allerdings etwas anderes (womit ich keineswegs die Verdienste des Entwicklers geringschätzen will).
Die meisten, die ernsthaft was im TS anstellen, werden RWTools nur an den TS lassen, um auf die schnelle irgendwas zu überprüfen, aber nicht um etwas zu bearbeiten.

Um auf das Thema zurückzukommen:

Mit dem Blueprint-Editor (kurz: BPE) kann man keine Strecke untersuchen. Der BPE ist das Werkzeug im TS, mit dem man Assets erstellt.
Als Input verwendet er 3D-Modelle (erzeugt mit Blender oder 3dsMax), Audio-Dateien (.wav Format), Texturen (.dds Format) und .csv-Dateien. Diese Dateien werden in einem im BPE erstellen Blueprint eingetragen, in dem man außerdem beschreibt, wie der TS mit diesen Rohstoffen umgehen soll. All diese Quelldateien liegen im (railworks/)source Ordner. Beim Export eines Blueprints mit den darin referenzierten (Modell/Audio/Textur) Dateien erzeugt der BPE ein gleichnamiges Asset im (railworks/)asset Ordner.

Beim Streckenbau werden nur diese fertigen Assets verwendet. Daher braucht der Benutzer einer Strecke auch nicht die originalen Source-Dateien. Aber man kann mit dem BPE auch keine fertige Strcke untersuchen: es gibt keinen "Export rückwärts". Man kann mit dem TS-Hilfsprogramm "serz"
zwar die aus den Blueprints erzeugten Asset-.bin-Dateien wieder in ein in einem Texteditor lesbares .xml-Format konvertieren, aber diese rück-übersetzten xml-Dateien entsprechen inhaltlich nicht den in den BPE-Blueprints verwendeten .xml Dateien.
Diese rückübersetzten Dateien erlauben den Benutzern einer Strecke allerdings, bestimmte Änderungen vorzunehmen, obwohl sie nicht über die ursprünglichen (BPE-)Source-Dateien verfügen.

Der Punkt "Strecke direkt erstellen" in RWTools mag am Anfang hilfreich sein, hat aber auch böse Fallen.
Besser ist es auf jeden Fall, im BPE eine neue Route Template anzulegen (Add - New Item - Blueprint - Route blueprint).
Wenn man sich das einfach mal im BPE anguckt, wird man einiges wiedererkennen, was in den RWTools-Dialogen auftaucht.
Vergleich mit den Route Templates existierender Strecken (Rück-Konvertierung mittels serz) zeigt, wo es lang geht.

Zitat von Matze L

Aber ergonomische geformte Sitze sind nun mal besser als eine gerade flache Fläche.

du vergisst: der Passagier kann die Sitze nicht anpassen. Geformt Sitze passen nur denen, die die Körperstatur/größe des Vorbilds haben. Für alle anderen sind sie schlechter als "gerade flache" Sitze.
Da kann ich durchaus "ein Lied von singen", da meine Bandscheiben auch nicht mehr "jugendfrisch" sind
- die dicken weichen Sitze in den 1.Klasse Wagen der ÖBB sind für mich grausam.
- die Sitze im ICE 2 gut
- die Sitze im ICE 3 grenzwertig
- die Sitze in den DoStos des RE 5 angenehm
- die Sitze im RE 1 grausam
...
die Sitze im 420 fand ich angenehm ... ist aber auch schon viele Jahre her dass ich öfters zwischen München Hbf und Flughafen gependelt bin.

was die Fahne ("Flag") betrifft: entweder man nimmt ein eigenes Markierungsobjekt (wozu man aber zumindest ein klitzekleinwenig 3D-Bau machen muss), oder man trägt die Kuju-Flag ein. Die ist in einem anderen Provider-Ordner, und macht deshalb beim Export keine Probleme.
Statt der Kuju-Flagge kann man aber auch einen Kirchturm, Haltestellenschild oder sonstwas eintragen. Ist ja nur, damit man im Editor sieht, wo der Marker ist.

bevor du solche Panik-Aktionen startest:

Leg eine neue Strecke an auf gleiche Weise wie die um die es hier geht (ich nehme an, du weisst noch, welche Startkoordinaten du verwendet hast)
Nimm den kompletten "MapProjection" Teil (den ich oben schon mal gezeigt hab) aus der neuen RouteProperties und überschreibe damit denselben Teil in den RouteProperties der aktuellen Strecke

Dann guck ob es passt.