Dafür sind vR EL Loks auch keine Funktionskrüppel und bekommen 23847892383 Updates die einen Fehler beseitigen und 20 weitere einfügen.
Ich weiß nicht, woher du deine Updates beziehst, aber bei mir wurden die Loks danach stets besser 
Edit: Missverständnis
Huch, grad zufällig reingesehen.
Ein Patch? Super!
Hab ich direkt mal installiert und getestet.
Die Map der besagten/beklagten Strecke, die sich bis eben nicht mehr darstellen ließ, wird nun korrekt angezeigt.
Im Logging-Fenster werden aber 2 Signal-Blueprints angemeckert:
20:38:54.751 [ForkJoinPool-1-worker-1] WARN ch.tkl.rw.routes.BlueprintCache - Not a valid blueprint: AbsoluteBlueprintID(PillePalle/Ballerburg-Dreuselsee/RailNetwork\Signals\German HV\DEs_HV_HS3VS3_10T.xml)
20:38:54.749 [ForkJoinPool-1-worker-7] WARN ch.tkl.rw.routes.BlueprintCache - Not a valid blueprint: AbsoluteBlueprintID(PillePalle/Ballerburg-Dreuselsee/RailNetwork\Signals\German HV\DEs_HV_HS3VS3_11T.xml)
Ich werd mir die 2 Signale mal ansehen.... vielleicht finde ich ja ein Fehlerchen...
Danke für den schnellen Patch!
Edit:
Ich hab die 2 Fehler Dank RWInfo finden können. Klasse Tool, wirklich!
Beide Signale hatten eine korrupte/kaputte chcRMatrix4x4, man beachte die aus der Reihe tanzende 4. Datenzeile:
<cHcRMatrix4x4>
<Element>
<e d:type="sFloat32" d:alt_encoding="000000000000F03F" d:precision="string">1</e>
<e d:type="sFloat32" d:alt_encoding="0000000000000000" d:precision="string">0</e>
<e d:type="sFloat32" d:alt_encoding="0000000000000000" d:precision="string">0</e>
<e d:type="cDeltaString">0</e>
<e d:type="sFloat32" d:alt_encoding="0000000000000000" d:precision="string">0</e>
<e d:type="sFloat32" d:alt_encoding="000000000000F03F" d:precision="string">1</e>
<e d:type="sFloat32" d:alt_encoding="0000000000000000" d:precision="string">0</e>
<e d:type="sFloat32" d:alt_encoding="0000000000000000" d:precision="string">0</e>
<e d:type="sFloat32" d:alt_encoding="0000000000000000" d:precision="string">0</e>
<e d:type="sFloat32" d:alt_encoding="0000000000000000" d:precision="string">0</e>
<e d:type="sFloat32" d:alt_encoding="000000000000F03F" d:precision="string">1</e>
<e d:type="sFloat32" d:alt_encoding="0000000000000000" d:precision="string">0</e>
<e d:type="sFloat32" d:alt_encoding="0000000000000000" d:precision="string">0</e>
<e d:type="sFloat32" d:alt_encoding="0000000000000000" d:precision="string">0</e>
<e d:type="sFloat32" d:alt_encoding="0000000000000000" d:precision="string">0</e>
<e d:type="sFloat32" d:alt_encoding="000000000000F03F" d:precision="string">1</e>
</Element>
</cHcRMatrix4x4>Hab das nun nach sFloat32 korrigiert und HokusPokus, RWInfo meckert nicht mehr.
Ich werde das Signalteam dahingehend informieren, dass es vielleicht sein könnte, dass auch bei anderen Signalpaket-Signalen vielleicht die chcRMatrix4x4 kaputt ist. Ich glaube jedenfalls nicht, dass ich das war 
Danke
Damit überschreibst du natürlich das bestehende Gelände.
Falls du ein backup hast kannst du gezielt die alten Geländekacheln einzeln zurücksichern.
Du findest sie im Terrain-Ordner in deiner Strecke (GUID per NameMyRoute.exe oder direkt im TS erfragen).
Die kachelnummer erfährst du im TS.
Die Alten einfach über die Neuen drüberschreiben.
Die Performance ist dem TS nach dem Import egal, weil er generell immer die 1024 m²-Terrainkacheln in 8-Meter-Segmenten ablegt, egal welche Geländedaten man importierte oder mit der Hand modellierte.
Sie haben immer dieselbe Größe.
Ja, das ist recht einfach.
Man muss nur seinen DEM-Ordner mit den nötigen Breiten-Längengrad-Dateien füttern, getrennt nach Aster und SRTM.
Das Gelände fügt sich dann um die eigene Kameraposition ein, also mit dir in der Mitte.
Bei Aster muss zwingend die "2" im Dateinamen gelöscht werden, sonst findet der TS die Aster-Dateien nicht.
Steht auch irgendwo in unserem Wiki, übrigens...
Auch wenn das immer wieder behauptet wird, auch auf UKTS oder jetzt auch hier, es gibt SRTM-Daten mit einer echten Auflösung von 1" (1 Bogensekunde) nur von den USA.
Die 1"-Auflösung der anderen Regionen, die es z.B. bei viewfinderpanoramas.org gibt, sind lediglich umgewandelte Daten aus anderen/ungenaueren Quellen die im Anschluss auf 1"-Auflösung geglättet wurden, aber die deswegen natürlich noch lange nicht eine echte Auflösung und damit eine Authentizität von 1" aufweisen.
Man kann das vergleichen mit einem Bild in einer bestimmten Auflösung:
- Das normale SRTM ist ein Bild, sagen wir mit 320x320 Pixeln.
- Das USA-SRTM ist ein Bild höherer Auflösung mit mehr Details, sagen wir 1280x1280 Pixel.
- Das hier vorgebrachte 1"-SRTM für andere Regionen außerhalb der USA ist jedoch nur das vergrößerte Bild 320x320 hochskaliert auf 1280x1280, über das man anschließend ein Antialiasing drüberbügelte. Man hat aber deswegen nicht mehr Details, sondern eine noch weichere Geländestruktur als so schon.
In der Praxis kann ich das auch bestätigen. Die Geländedaten sind trotz ihrer ca. 10-fachen Dateigröße trotzdem ungenauer und damit schlechter als das herkömmliche 3"-SRTM.
viewfinderpanoramas.org/schreibt dazu selbst:
ZitatNASA has only released 1" SRTM data for US territory. I have created HGT files with a resolution of 1" for some parts of Europe from topographic maps. For most of the Alps and the most rugged parts of the Pyrenees, these were created from the most detailed sources, and should be accurate. Elsewhere, I have 1" SRTM data for Great Britain, Ireland, France (excluding Corsica), Germany, Benelux, Denmark, Norway, Sweden and north east Spain. But these were created from Russian maps of scale 1:100,000, which are less accurate than SRTM. Consequently, for these areas, where 3" SRTM data is available from this page or from SRTM, they should be generally better than the 1" data, despite the lower resolution.
Quelle: http://www.viewfinderpanoramas.org/dem3.html#hgt
Kurz: das erhältliche 3" SRTM ist genauer, trotz der niedrigeren Auflösung, als das für diese Bereiche erhältliche 1".
Außerhalb der USA gibt es keine echte 1"-Auflösung. Tut mir leid.
Das ist die richtige Einstellung.
Das ist nämlich alles keine Magie, kein Voodoo und irgendwelche Beschwörungsrituale benötigt man auch nicht 
Mal kurz auf die Piste, mit der Lok meiner Wahl auf einer Strecke meiner Wahl auf einem Streckenabschnitt meiner Wahl in meiner Lieblingsjahreszeit und meinem Lieblingswetter zu meiner favorisierten Tageszeit.
Ich mag QuickDrive wirklich sehr.
Auf Türkisch heißt er Konstanz Gölü, auf italienisch Lago di Constanza und die Niederländer sagen Bodenmeer 
Ich finde das wirklich interessant, weil man teils sehr gut die Sprachverwandschaften und gleichen Sprachherkünfte erkennen kann. So heißt es in afrkaans ebenfalls Bodenmeer, vermutlich wegen der niederländischen Sprachwurzeln.
Die Römer sagten zunächst zum Obersee Lacus Venetus und zum Untersee Lacus Acronius, und später dann zum gesamten See Lacus Raetiae Brigantinus.
Aber vermutlich muss man sich für Sprache interessieren, um das interessant zu finden 
.... Ich bin schon wieder weg!
Ich lese daraus, dass vR seit jahren stets bemüht war und ist, tolle Sachen einzubauen, die aber leider teils nicht komaptibel sind zu der Szenario-Speicherfunktion. Diese wird aber seitens DTG gefordert, wenn man das Produkt über Steam anbieten will.
Wenn ich daran denke, wie oft Maik Goltz darüber geklagt hat, dass DTG irgendwelchen Verbesserungswünschen stets uneinsichtig gegenüber stand* und kaum oder sogar garnichts davon am TS umsetzte, ist das nun die logische Konsequenz.
DTG baut Hebel-Vor-Loks und erzwingt dies auch von den Drittherstellern, wenn sie diese Produkte über Steam anbieten wollen. DTG hat da nunmal die Hoheitsrechte, was in den Steam-Laden kommt oder nicht, und wenn denen etwas missfällt, muss man halt abspecken.
Ich sehe die Schuld da eher bei DTG weil die einfach nicht in der Lage sind, vernünftige Schnittstellen zwischen Rollmaterialkomponenten einzubauen oder eine Speicherfunktion anzubieten, die der Lokhersteller frei mit Werten füttern kann UND verlässlich wieder szenariobezogen auslesen kann.
Ich meine, mal irgendwo gelesen zu haben, dass man als Lokomotive nicht mal erkennen kann, auf welcher Strecke oder in welchem Szenario man sich befindet.
So wie ich das sehe, hat man einen ziemlich steinigen Weg beschritten, aus dem nun DTG eine Sackgasse machte, ob dies nun aus Unfähigkeit passierte oder aus Unwillen (irgendwas zu verändern/verbessern) oder aus sonstigen Gründen.
So ist jedenfalls meine Sicht der Dinge, wenn ich die Geschehnisse der letzten Jahre und die Kommentare einiger Leute rekapituliere.
*) Bestes beispiel ist der altbekannte Jelly-Cab-Bug
Ganz einfach, dir FEHLEN die Bodentexturen.
Da hast du seither irgendwas verändert/gelöscht/umbenannt.
Oh, noch ein Fachmann... super!
Und sogar ganz neu im Forum! Herzlich willkommen und danke, dass du dich extra für diesen Beitrag hier angemeldet hast.
Ok... ich sehe ein, dass die Stumpfgleise in Bahnsteignähe mit Gleissperren wohl kaum mit Hp2 signalisiert werden können/sollten/dürften.
Insofern ist wohl auch ein Zs1 völliger Quatsch.
Man kommt da wohl nur rangierend rein, so wie ich das sehe...
Muss ich also umbauen.
Das wird wohl die beste Lösung sein, die der Realität am nächsten kommt.
Allerdings gibt es da ein kleines Problemchen:
Wenn ich die Links in diese Stumpfgleise wirklich ausspare, dann schaltet das betreffende Hauptsignal automatisch auf Zs1/Zs7 um, wenn die Fahrstraße in ein nicht von diesem Signal verlinktes Gleis führt. Das konnte ich schon öfter beobachten, wenn ich mal versehentlich beim Testen eine Fahrstraße in ein nicht verlinktes 10 m lange Flankenschutzgleis einstellte. Das Hauptsignal machte dann ein Zs1/Zs7.
Und so wird es dann auch hier sein.
"Was tun...?" sprach der arme Tropf, und strich sich mit der Hand über'n Kopf...
Ich weiß nicht, wie Andere das sehen, aber ich finde das irgendwie spannend und interessant und möchte mich nochmal bei euch Beiden für die Hilfe bedanken! 
Nein, das sind eindeutig keine Flankenschutzeinrichtungen. Zunächst mal könnten sie dort überhaupt keinen Flankenschutzzweck erfüllen und desweiteren verfügen diese Stumpfgleise über Gleissperrsignale ("Zwerge") und darüberhinaus über Gleissperren. Auch sieht man dort oft Loks rumstehen. Mir scheinen das eher Bereitschaftsgleise zu sein, damit diese schneller an einen Personenzug angekuppelt werden können und bis dahin nicht dumm im Weg rumstehen, bzw. bis dahin nicht 10x "sägen" müssen, um endlich ihren Betrieb aufzunehmen.
Aber ich bin nur Laie und rate nur wild rum. ich würde es aber so tun, wenn ich das zu organisieren hätte.
Ich hätte vielleicht noch erwähnen sollen, dass es sich um einen reinen Personenbahnhof größeren Ausmaßes mit Lokwartung, Waschanlage, etc handelt.
Ich habe jetzt die Einfahrt ab dem ESig mit Hp2 + Zs3 "2" signalisiert und dort, wo genug Gleislänge war, einen daueraktiven 500er 150m vor dem Prellbock verbaut. Ich denke, damit können wir alle leben, oder?
Wer es genauer will, soll Tf bei der echten Bahn werden oder sich sein eigenes privates EVU gründen 
Jedenfalls danke ich dir ganz herzlich für deinen fundierten und umfassenden Text. Daran hast du bestimmt ne halbe Stunde rumgeschrieben,... und dafür danke ich dir ganz dolle! Ich muss aber zugeben, dass mich deine Ausführungen sehr fordern, ja wirklich auch überfordern, weil ich teils (haha, Wortwitz) nur Bahnhof verstehe. Das Prinzip habe ich aber verstanden, hoffe ich.
Danke!
Hallo Jan Chudoba
Bin für fundierte Infos sehr dankbar.
Ja, das war ziemlich fundiert und nun bin ich dümmer als vorher
Nein, nicht wirklich...
Danke für diese fundierte Klarstellung!
Um welches Stumpfgleis auf der Strecke geht es, Prelli?
Es geht nicht um die Schwarzwaldbahn. Ich darf leider nicht sagen, um welche Strecke es geht, auch wenn es mir in den Fingern juckt, etwas darüber zu erzählen. 
Vielleicht sollte ich eine Skizze machen...? Hmmm...
Alle betroffenen Stumpfgleise haben jedenfalls keine ASigs, weswegen dort ja auch keine Zugfahrt beginnen kann.
Bislang hatte ich immer gedacht, dass rote Sh2-Scheiben das Ende einer Zugfahrt signalisieren, z.B. Bahnsteigstumpfgleise.
Dies hat man also 2008 geändert... nun gut.
Ich werde also als ESig ein Hp2 mit Zs3 "2" oder "3" dort verbauen.
Dazu hätte ich 2 weitere Fragen:
Wann würde man ein Zs3 "2" nehmen und wann ein Zs3 "3"? Hat das mit der Nutzlänge des Stumpfgleises zu tun, bzw. mit der Wegstrecke ESig --> Stumpfgleisende? Falls ja, was dient hier als "Faustregel" ein Zs3 "2" statt einem Zs3 "3" nehmen zu müssen?
Und was ist als Zugziel zu verstehen, bzw. wie weiß ich, wo ich da den 500er hinlegen soll?
Und was mache ich, wenn das Stumpfgleis viel zu kurz ist, so dass der 500er theoretisch vor der Weiche auf das Hauptgleis gelegt werden müsste? Gibt es bei der echten Bahn demnach 500er, die je nach Fahrstraße umschalten? Denn sowas haben wir im TS ja garnicht.
Ich sollte nicht so ein Gewese machen, denn 90% der Spieler wissen das ohnehin weder zu würdigen, noch verstehen sie den Sachverhalt, so dass dies schnell als vermeindlicher Fehler interpretiert werden könnte: "Da habe ich eine Zwangsbremsung bekommen, obwohl ich nur 40 km/h fuhr, weil mir das HUD dies als erlaubte Geschwindigkeit anzeigte!"
Ganz schön blöde Sache irgendwie... man macht sich einen Kopf darum, verwendet viel Zeit und Hirnschmalz dafür und letztlich interessierts eh keine (sprichwörtliche) Sau, wenn man von einer Hand voll Puristen und Fachleuten mal absieht.
Achtung Polemik: Aber die Blümchen sind toll!!!1!
*soifz*
Hallo ihr Schwellenstapler
Mal wieder habe ich eine Frage zu einem Signalisierungsproblem.
Stellen wir uns vor, ein Bahnhof hat ein Stumpfgleis mit einem Sh0/Gsp0 am Prellbock (also kein rotes Sh2).
Demnach führen dort ja keine (planmäßigen) Zugfahrten hin.
Frage 1:
Was sage ich dem ESig für diese Fahrstraße?
Nach meinem Verständnis dürfte es für diese physikalisch theoretisch mögliche Fahrstraße keinen Hp2-Signalbegriff mit Kennziffer "3" (Frühhalt) gaben dürfen, sondern nur ein Ersatzsignal Zs1, oder?
Und Frage 2:
Würde man dort im Stumpfgleis einen daueraktiven 500-Hz-Magneten verlegen?
Auch dann, wenn man dort normalerweise nur als Rangierfahrt einfahren kann?
Bin für fundierte Infos sehr dankbar.
lg
Von uns gewünscht wird schon seit Jahren: ICE 1 EL, ordentlicher ICE 3, 101 EL, 181 EL, Bügelfalte EL, usw.
Also ich habe mir die von dir Aufgelisteten nicht gewünscht. Ich freue mich über das, was kommt. Aber danke, dass du für mich sprichst.
Abzockmanier
Und immer schön polemisch bleiben
Ich fühle mich von ganz anderen Leuten/Firmen abgezockt. Aber vR gehört da bislang nicht zu.
Gefällt mir eigentlich ganz gut, aber warum machen viele Lokbauer die Frontscheibe immer so milchig?
Also wenn ich aus dem Auto gucke oder aus dem Fenster hier Zuhause, sehe ich leuchtende klare Farben, so als wäre kein Glas da. Nie aber sehe ich so einen milchigen Nebel.
Alles starke Raucher?
Der Schatten vom Lokkasten wird doch bestimmt noch gefixt, oder?
Wird es eigentlich bei Konstanz - Offenburg GÜs geben?
Ja sischer datt! Aber bislang leider nur fixe, also keine, die am Signal liegen und geschaltet werden müssten.
Wer mit PZB fährt muss halt mit diesen Dingern rechnen *achselzuck*
Das ist doch grad das Spannende daran, dass man halt aufpassen muss. Streckenkunde ist nicht notwendig, denn wenn ich 160 km/h fahre und ein Lf6 "10" sehe, muss ich mit so einem Ding ca. 500-600m vor meiner Nase rechnen.
/Ende Offtopic
Die Streckenlänge ist vollkommen irrelevant.
Ob da nun 620 km Gleise liegen (wie hier) oder 6200 km, das ist dem Ramverbrauch fast egal. Das sind nur ein paar Dutzend MB mehr.
Auch wirkt es sich kaum auf den Ramverbrauch aus, ob dieser Baum dort 1x da rum steht oder 10.000x, solange es derselbe Baum ist. Dessen Mesh und Textur liegt nur einmal im Ram. Das merkt man nur negativ an der Performance (=FPS), aber so gut wie nicht am Ram.
Relevant ist die Anzahl verschiedener Objekte und deren Güte, die gleichzeitig vom TS dargestellt werden sollen.
Daher ist es auch wichtig, KI-Züge möglichst frühzeitig in Portalen verschwinden zu lassen, damit wieder ein bisschen an Ram frei wird.
So jedenfalls meine Beobachtungen.
Edit:
Übrigens sehr schönes stimmungsvolles Bild @fsclips
Dachte zuerst anhand der Vorschau, das wäre ein Originalfoto. Wirklich schön!
Ich hatte hier 15 Züge gleichzeitig auf den Gleisen, teils waren ein paar dicke "Fische" dabei, wie z.B. Fopix' BR218, HRQs Taurus (3x) oder vR_BR232 und vR_E03.
Der Ramverbrauch war bei 3 GB.
Es sollten also (noch) genug Möglichkeiten für den Szenariobau vorhanden sein. Doch empfiehlt es sich, die dicken Brocken (Fopix, HRQ) als KI sehr sensibel einzusetzen, soll es nicht zu einem Dump wegen Ram-Mangels kommen.
Die typischen Kuju-Loks (BR101, BR294) hingegen sind recht sparsam gebaut. Die Strecke verträgt hiervon recht viel.
Bild: Radolfzell
Trotzdem soll nicht verschwiegen werden, dass wir diesbezüglich schon Bedenken hatten und haben, weswegen wir stets bemüht sind und bemüht waren, nicht ganz so "fett" zu (be)bauen, es aber trotzdem gut aussehen zu lassen.
Es ist eine Gratwanderung.... keine Frage...
