Hallo
Schau mal nach im Hauptmenü ---> Fahren --> Standard
Dort sollten ein paar Aufgaben für die RSL zu finden sein.
Hallo
Schau mal nach im Hauptmenü ---> Fahren --> Standard
Dort sollten ein paar Aufgaben für die RSL zu finden sein.
Ich sehe das anders.
Gute 2D-Bäume sehen auch neben dem Gleis natürlicher aus, als die künstlich wirkenden 3D-Bäume, wie sie derzeit für den TS erhältlich sind. Einziges Manko ist der fehlende Schatten, der -wenn vorhanden- auf dem Gleis liegend viel Realismus erzeugen kann.
Ein Verschieben in einen anderen Ordner desselben Laufwerks ist technisch betrachtet ein Umbenennen.
Daher geht das auch so schnell, weil nicht physikalisch irgendwas verschoben wird, sondern nur der Eintrag im Inhaltsverzeichnis des Datenträgers wird abgeändert.
Vermutlich rührt daher das Missverständnis.
Dass Kuju generell immer benötigt wird, ist nur bedingt richtig.
Es ist richtig, wenn das Tool nur die erste Ordnerebene behandlen kann, also den Provider, hier "Kuju".
Wenn das Tool aber noch das Product in der zweiten Ordnerebene behandelt, würde "Kuju/RailSimulatorCore" bei manchen Strecken ausreichen, weil nur hier die elementaren Objekte vorhanden sind, die der TS immer benötigt, z.B. Bahnsteig- und Szenariomarker oder den Gizmo des Editors, der seinerseits ja auch ein Objekt ist.
Letztlich aber erscheint mir der Einsatz dieses Tools aber noch irgendwie fragwürdig. Ich erkenne da irgendwie keinen Sinn. Das sähe anders aus, wenn die Product-Ordner, also die zweite Ordnerebene gezielt für ein bestimmtes Addon abgespeckt werden würde, was die BluePrints verkleinern würde und RAM sparen könnte, was aber ja nicht der Fall ist, wenn ich das richtig verstehe.
Bei 3,5-irgendwas GB ist Schluss, das stimmt leider.
Dennoch soll nicht verschwiegen werden, dass durch den Start des TS trotzdem auch mal 4 oder gar 4,4 GB verbraucht werden durch die ganzen anderen Zusatzmodule wie DirectX, OpenAL und PhysX, die ihrerseits ihre eigenen, vom TS unabhängigen Speichergrenzen haben.
Insofern... bevor wieder jemand angesprungen kommt und versucht, zu belegen, dass XP-32Bit keinen Nachteil gegenüber 64Bit hat... ist es schon von Vorteil, wenn man ein 64-Bit-OS mit mindestens 6 GB in seinem Rechner verbaut hat.
Eine Leistung erschleichen ("Leistungserschleicher") ist eine strafbare Handlung, wie z.B. das sogenannte "Schwarzfahren", also die Inanspruchnahme eines öffentlichen Verkehrsmittels ohne gültigen Fahrschein.
Hier von Leistungserschleichung zu sprechen ist fehl am Platz und schlichtweg falsch.
Ich bediente das Angebot mit einer .com-Adresse, bekam aber bislang keinen Code. Es kann also in meinem Fall nicht daran liegen, dass ich mehrere Adressen angegeben hätte und außerdem: Wie will DTG das nachprüfen, ob ich da mit einer oder fünf EMail-Adressen mein Glück versuche? IP-Adresse? Die ist schnell geändert. Zur Not gibts auch noch Proxies.
Das Argument des "entgangenen Gewinns" ist in meinem Falle auch nicht haltbar, weil ich mir diese Strecke wie auch alle anderen US- und GB-Strecken ganz sicher nicht zugelegt hätte, weil sie mich nicht interessieren. Einzig für eventuelle Freewarestrecken, die künftig auf die Assets dieser Strecke zurückgreifen könnten, wäre der Erhalt des Codes dieser Strecke für mich sinnvoll gewesen.
Viele Objekte kann man auch im Szenario-Editor verbauen.
Also auch Autos, Einsatzfahrzeuge, etc.
Einfach den btreffenden Provider anhaken.
Sollte sich der TS aufhängen, hat man auf dem Desktop normalerweise ein Fenster mit einer Fehlermeldung.
Dass der Ladebalken je nach Größe der Gleisanlage stockt, ist normal.
HH-H hat eine relativ große Gleisanlage, da kann es schonmal passieren, dass sich für 10-20 Seks nichts tut, bei langsameren Prozessoren entsprechend länger.
Ich vermute, dass die Tracks.bin und die Tracks-Kacheln in diesem Zeitram analysiert werden und die Ribbons für die Gleisanlage im Ram aufgebaut und verbunden werden, denn je kleiner die Gleisanlage, desto schneller läuft der Ladebalken wieder weiter.
Was habt ihr denn alles für verschleimte Ranz-Kisten?
Jaja, ich geh ja schon ![]()
*duck und weg*
Hihi
Ich frage mich, warum es nötig ist, das Archiv zu splitten?
Leute, die sich damit nicht auskennen, sind mit Teilarchiven nämlich schnell überfordert.
Steht denn nichts im Readme, dass es sich um Teilarchive handelt, und wie man diese entpackt?
Danke
Und wie sehen die Bäume im Herbst/Winter/Frühling aus?
Das wäre dann wartbar, oder?
Klingt fast so, als würde jeder Käufer der M-GaP sein eigenes Süppchen kochen und was verändern.
Die Strecke hat es wohl echt bitter nötig, wenn sich jeder genötigt fühlt, daran rumzuschrauben.
Traurig Traurig
Toller Vergleich, Norbert!
Wie der von Äpfeln und Betonpfeilern oder so...
Wenn 2 Leute je eine Aufgabe bauen, dann werden diese 2 Aufgaben wohl kaum identisch sein.
Beim verbessern einer Strecke, unabhängig durch 2 Gruppen, ist das aber leider der Fall. Die Strecken mögen anschließend unterschiedlich sein, können aber nicht ergänzend genutzt werden. Die 2. Strecke hat also keinen Mehrwert. Ein zweites Szenario aber schon.
Baubar?
Ist das sowas wie eine Salatbar? ![]()
Warum sollte DTG das tun?
Quelle?
Schön!
Freut mich, dass du was für dich rausholen konntest.
Vielleicht rüstet irgendjemand die Strecke ja doch mal mit Signalteam-Komponenten nach? Wer weiß...?
Lass den Kopf nicht hängen.
Diese undankbare Sysiphus-Arbeit wäre vermutlich eh nicht das geworden, was du dir vorgestellt hast.
Das lag aber nicht an dir. Bitte nicht falsch verstehen.
Aber du hast recht.... schade, dass man nicht eher Bescheid wusste. Verstehe ich irgendwie nicht wirklich, warum man da nicht mal Absprache hielt.
AbsolutesChaoz:
Prinzipiell hast du natürlich Recht.
DTG/RSC weiß das aber selbst auch nicht so genau, denn die schreiben in ihren DevDocs:
ZitatAzimuth has an effect on shadow fall and general darkening of the ground. The range of values where there is a visible difference is between 0 and 1.5. The higher the value the longer the shadows and darker the ground becomes. A value between 0 and 1 is recommended.
Das hat also mit dem astronomischen Azimut garnichts zu tun. Also hilft nur experimentieren und da kann man auch nicht erklären, was diese Werte genau bedeuten, weil da die wissenschaftliche Grundlage fehlt oder aber sich mangels Dokumentation nicht erschließt. Mir jedenfalls nicht. Ich kann da nur mutmaßen.
Aber ich probiere es mal...
Astronomie:
Der Azimut kann normalerweise positive Werte annehmen bis zu 360°.
0° bedeutet, der zu behandelnde Himmelskörper befindet sich exakt in Richtung Norden.
180° bedeutet, dass der zu behandelnde Himmelskörper sich exakt in Richtung Süden befindet.
Jetzt zum TS:
Der TS kennt ja keine Gradangaben von 0 bis 360°.
Vielmehr kommt hier meist der Radiant zum Einsatz, der sich aus 2 x Pi zu einem Vollkreis zusammensetzt.
Das würde sich halbwegs decken mit der Angabe in den Devdocs, denn da steht:
ZitatThe range of values where there is a visible difference is between 0 and 1.5.
Ich vermute, dass 1,5 aber falsch ist, weil es eigentlich 1/2 x Pi sein müsste, also ca. 1,57077.
Was diese Angaben aber nun tatsächlich tun, das weiß ich leider auch nicht. Ich weiß aber, dass man damit die Sonne dazu brigen kann, im Norden zu setehen OBWOHL man mittels Breiten-/Längengrad die Nordhalbkugel definierte. Jedenfalls ist das meine Erinnerung an meine Experimente auf dem Dreuselsee vor bald 2 jahren.
Verwirrend ist hier nur, dass die DevDocs sagen, dass höhere Werte längere Schatten machen. In der Astronomie hat der Azimut aber garnichts mit der Höhe der Sonne zu tun, sondern nur mit der Richtung. Die Höhe kenne ich eher als Deklination oder Höhe über Horizont, aber keinesfalls als Azimut.
Was es mit Easting und Northing auf sich hat, habe ich auch noch nicht ganz kapiert.
Es gibt aber einen Rechner, den ich gerade fand, der das umrechnen kann: http://www.utmconverter.com/ (Bild)
Dieser spuckt einem dann Easting/Northing und die Zone aus und ich muss feststellen, dass die Werte meiner SWB wohl falsch sind.
Alles in allem ist das ein großer Salat an Kram, den man angeben muss, aber den man nicht angeben müsste, wenn das vernünftig umgesetzt worden wäre, denn Sonnen- und Mondbewegungen, sowie Sterne müssen nicht individuell für jede Strecke definiert werden, weil man auf dem Erdball das alles prima ausrechnen kann und die Definition dieser Werte unnötig machte. Der UBoot-Sim "Silent Hunter" ist ein gutes Beispiel dafür, bei dem man sogar präzise nach den Sternen navigieren kann.
Dadurch aber, dass man an viel mehr Rädchen drehen kann, als nötig, bietet sich viel Raum, um Murks zu definieren. RSC/DTG-Strecken sind da ein tolles Negativbeispiel. Allein die Farbgebung der Himmel bei Dämmerung ist (Achtung Wortwitz) himmelschreiend.
Falls jemand weitere Aspekte zur Klärung des Azimut im TS und des Northing und Easting beitragen kann, würde ich mich freuen. Vielleicht bekommt man ja doch noch Licht ins Dunkel und versteht die Zusammenhänge umso besser. Vielleicht gibt es ja sogar eine Logik dahinter, die sich mir aber noch nicht erschlossen hat. Ich bin kein Mathematiker und auch kein Voodoo-Schamane, der mittels Werfen von Hühnerknochen dem auf den Grund gehen könnte, was sich Kuju dabei dachte.
Und DTG? Die haben selber keine Ahnung davon. Daher liefern die auch immer und immer wieder denselben Murks in ihren Strecken aus, bestehend aus braunen Himmeln bei Dämmerung, einem 5-fach zu großen Mond und viel zu schnellen Wolkenbewegungen.
ich habe den Vorschlag von Prelli mal ausprobiert
Welchen Vorschlag? ![]()
Keine Ahnung ob die HaSi stimmt oder nicht.
Dann mach das mal mit der eigenen RouteProperties.
Kannst ja die Werte der B-W nehmen.
Oder die vom Dreuselsee, die müssten auch stimmen und beziehen sich auf die Gegend irgendwo beim Taunus.
Nochmal zur Klarstellung:
Das Wetter hat nichts zu tun mit der Himmelmechanik oder mit Koordinaten.
Das Wetter sagt der Strecke nur, welche Niederschläge und Winde es gibt, ob man Wolken sehen kann, oder ob es neblig ist.
Noch nicht einmal die Wolken (als Textur) werden im Wetter definiert, sondern die 3 Wolkensphären werden mit der Strecke in den TimeOfDay-Dateien geliefert. Das Wetter schaltet diese nur ein oder aus. Sonst nichts.
Gleiches gilt für Mond, Sonne, Sterne. Da hat das Wetter ebenfalls nichts mit zu tun.
Das Wetter definiert also nur einen "Fahrplan" für das Wetter, basierend auf dem Himmelsgerüst der Strecke (RoutesProperties und TimeOfDay), was sie wann für ein Wetter wie lange darstellen soll.
Das einzige, was individuell im Wetter verändert werden kann, sind Aussehen und Form des Niederschlags, also z.B. Regen, Niesel, Graupel, Hagel und ferner die Winde, die die Wolken um die Ecke schieben und dem Niederschlag eine Seitenbewegeung verpassen.
Also bitte nicht verwechseln: Himmel und Wetter ---> Verschiedene baustellen