Tag/Nachtumschaltung im Welt-Editor !?

Gibt es nicht. Zeit muss im geladenen Freie Fahrt Szenario geändert werden.

Der Editor bemüht generell das erste(?) Freie-fahrt-Szenario zur Darstellung.
Dort kann/muss man auch die jahreszeit, das Wetter und die Uhrzeit vorgeben.
Das Datum hat keinerlei Einfluss, so gibt es auch durchaus Winter mit Schnee, wenn man den 20.Juli einstellt oder so

Hat es vielleicht schon im Zusammenhang mit Breiten- und Längengrad? Auf der Südhalbkugel kann es das durchaus schon mal geben...
Das ist auch der Grund, was zum Schmarrn für Sandra-Marion führt. Einen Knipser gibt es nicht. Es hängt halt alles mit allem zusammen.
Dafür geht auch die Sonne zur richtigen Zeit und an der richtigen Stelle des Horizonts auf.

Gruß
Norbert

In der Vorschau des Blueprint-Editors gibts das schon, incl. Jahreszeiten.
StS

Zitat von siebziger

Hat es vielleicht schon im Zusammenhang mit Breiten- und Längengrad?

hat es. Steht im Sky Info Blueprint, auf den bezieht sich der Route Blueprint, und auf den wird bei der Erstellung der Strecke Bezug genommen.
Die Einstellungen sind in vielen Strecken ziemlich sinnfrei, weswegen auch Schatten manchmal aus den falschen Himmelrichtungen kommen bzw falsche Längen haben.

Um das korrekt einzustellen, bleibt aber wieder die Frage offen, wie geht es richtig.

Leider nur empirisch:
Auf http://www.astronomie.info/calsky/Sun/index.html läßt Du Dir die Schattenlänge (eigener Menüpunkt) für einen Tag in der gewünschten Jahreszeit ausrechnen, stellst einen Kamin von bekannter Höhe in eine Ebene und mißt mit Lineal was rauskommt. TOD ändern und alles wiederholen, bis es paßt. Die Schattenrichtung auch beachten!
Bei mir stimmt das Ergebnis exakt für Thun jedenfalls. Und das sieht erheblich heller aus als diese englischen Standardeinstellungen, auf die man meist so trifft.
Grüße

Das ist wieder nur halbgare Rumprobiererei, auch wenns am Ende vielleicht passt. Zumal noch immer keiner weiß wie der TS mit der Einstellung die den Schattenwurf beeinflusst überhaupt umgeht bzw welchen Wertebereich es da gibt.

OT:

Die Einstellung des Sonnenstandes und damit des Schattenwurfes wird über den Wert "AzimuthAngle" durchgeführt. Dieser Wert beschreibt den Höchststand der Mittagssonne. Positive Werte sind für die südliche Halbkugel ( Sonnenlauf = Ost-Nord-West ) und negative für die nördliche ( Sonnenlauf = Ost-Süd-West ). Fällt man eine Senkrechte am obersten Punkt der Himmelshalbkugel, so wird von hier der Anzimutwinkel gemessen. Bei 45° ist der Wert = 1.0, kleinere Werte bedeuten einen höheren Sonnenstand ( kürzere Schatten, Sommer ) und Werte größer eins eine Verschiebung in Richtung Horizont ( längere Schatten, Winter ). Dies paßt für die Kuju-Himmelsgeometrie und kann auf den Demostrecken des Signalteams betrachtet werden.

Gruß 4711

Du kannst den Azimuthangle gerne eingeben, nur stimmt der nicht mit dem überein, was RW anzeigt. Deshalb kommt man um die Rumprobiererei nicht rum.

ja, ist ne ziemlich nebulöse Sache. Ich hatte vor langer Zeit mal ein paar TS-spezifische Hinweise dazu gefunden (weiß nicht mehr wo, möglicherweise railworks america) und mir für ein paar Orte die Werte berechnet - erstmal nur aus Neugier, ob sich da überhaupt was tut, was nicht erst an der 6. Stelle hinter dem Komma liegt. Aber da gibt es auch innerhalb Deutschland schon deutliche Unterschiede. Ich weiß nach meinem doppelten Systemwechsel vor einigen Monaten leider nicht mehr so genau, welche RouteTemplates ich genau berechnet hab, und welche kopiert sind. Da @120 Thun erwähnt, fällt mir allerdings ein, dass Berner Oberland eins der ersten Streckenprojekte war, bei dem ich die Werte berechnet habe - und damals auch den Eindruck besserer Lichtverhältnisse (im Vergleich zu den Kuju Standardwerten) hatte.

@4711 was Azimuth astronomisch ist, ist schon klar, aber der "Azimutwinkel" im Blueprint ist nicht dasselbe, sondern (ungefähr aus der Erinnerung) eine skalierte Differenz zu irgendeinem Basiswert.

p.s.:
ist halt so, dass die Wertebereiche in den Blueprints sich (vermutlich) meist daran orientieren, wie es für die internen Berechnungen der alten Engine am besten passt, und nicht daran, was für die Content-Autoren am nachvollziehbarsten ist (siehe z.B. auch die Kurvenüberhöhungskennwerte).