In TSC are these fixed to the season or the dates the scenario is set? Reason I ask is that I have the AP sky and weather 2 pack and set a scenario to start at 19:50 on today's date 18th April. Sky was black though with stars when the sun should have still been bright. For some reason I thought the AP pack changed the Default settings but maybe I'm wrong. If anyone can shed any light on this (no pun!) Much appreciated.
Two possibilities - as a second sky and weather engine was added by DTG to RailWorks 2. We can choose between two fundamentally different systems. Using 3D Weather + Dynamic Clouds enabled: Sunrise and path are calculated on the scenario date and the route's latitude. Pretty realistic. Used in QuickDrive by default. Has volumetric clouds casting real shadows. Works for high latitudes also - so you can have a polar day. All light calculations and shadowing are dynamically calculated - in 2D weather they are predefined for eight different times of day. Although there is a complex configuration file (RailWorks\data\SilverLining\SilverLining.cfg) I am not aware of anyone ever messing with it. This needs Dynamic Clouds to be ticked in the settings plus a 3D weather blueprint. Good for enhancing the look of old routes. Cajon Pass, 3D. Clear, Jul 1st Using 2D Weather (DynClouds Off) - for example AP SWEP Sunrise and sunset as well as the sun's azimuth are read from a fixed season TimeOfDay file, only four different possibilities depending on the Season that is set in the scenario. Date is irrelevant. Everything is "hardcoded". Uses three spheres of cloud bitmaps that can be blended using the weather blueprint. Many of TSC's TimeOfDay files are incorrectly setup so the sun travels the northern sky (though easy to fix). While you can achieve very nice sunset and sky gradients with a ToD file, it is not flexible and only applies to a certain latitude, so each route usually has its own set of ToD files (Spring, Summer, Autumn and Winter.bin) Sun will always rise exactly in the east and set exactly in the west. (which in reality only happens end of march / september). Polar day is not possible. Some very old routes like Cajon Pass or Bristol Exeter have bad looking ToD files (causing black mountains) - they look much better using 3D weather. Cajon Pass, 1. Clear, Summer. Good example of a badly composed TimeOfDay file. Though the sun is already up, it has way too low lighting values defined. Lighting is not calculated based on the sun's position, but taken from the season file for the specific time of day. So for the future I am hoping for an updated global 3D weather environment that does not need ToD and is therefore easy to apply and only needs two values as input, date and lat. More information from the developer documents: https://sites.google.com/a/railsimd...anual/blueprint-editor/time-of-day-blueprints
To quickly answer your question: It depends on which season you choose, not the scenario's date. For each season spanning three months, only a single sunrise and sunset time can be defined. That's a limitation of the bitmapped 2D sky environment AP uses.
So it's either use dynamic clouds as per default skies for More realistic time of day sunrise/sunsets or go with the AP SWEP but have it locked to a fixed time of day dependences on season. Cheers for the information.
Seasons should be looked at as which vegetation you want rather than the literal season to be honest. As a result, 18th April will suit Summer more than Spring as the leaves start showing on the trees and the longer days.
I wish it would take GMT/BST into account. Sunset in high summer at my latitude is almost 10pm, but it's 9 in the game.
It does, if the ToD files are correctly setup. You can specify if DST is used for each season, and its offset.
Oooh! I'm off to take a look. Thanks. [edit] Not sure how to edit the .bin files... if that's what I need to do that is.
At the beginning of each season file, the azimuths for sun and moon are given. For routes in the northern hemisphere, these must be negative. Simply put a minus in front of the value in case it's missing. Azimuth can range between -1.5 and +1.5. Zero means the sun will rise vertically directly to zenith at noon (tropical). 1.5 means its highest point will be just above the horizon at noon. The horizon itself is pi/2, but that's technically not possible with TSC, as there has to be a sunrise and sunset, that's why 1.5 is the limit. Example: Assets\Kuju\RailSimulatorCore\TimeOfDay\Summer.bin I've elaborated on that a bit more here: https://forums.dovetailgames.com/threads/ap-weather-extension-adjusting-the-azimuths-guide.56087/
One thing I found after saving a long free roam session on the West Highland merged route was the random weather stopped after a couple of saves. Unsure if that's to do with route merge or number of saves done. Weather just defaults to clear sky.
What weather was used? This is probably due to the fact that there is no randomness. Default 2D weather patterns are scripted. A weather blueprint (without extension) can contain four different weather types. You can create an event chain by defining the amount of time each pattern is used. The weather event chain must end somewhen, staying at the last pattern indefinitely. The playlist does not repeat. Example: RW_Stormy_HeavyRain.bin (DisplayName: 17. Stormy Rain) Rain (10 minutes) Overcast (15) Clear (15) Overcast (25) Clear (30) Overcast (15) Clear (45) So after two hours of play, the weather will stay clear (to be exact: with the parameters set in the <WeatherTypeClear> section) in this example. Of course you can add more patterns changes to the chain (checking the docs, there's no limit given) When you save a game, your scenario timer gets saved too - so the weather will not be reset. If you save a scenario using the above weather at 45 mins of play, reloading will go through the weather chain and pick the condition at 45 mins, which is 10+15+15+25 Overcast! Detailed info: https://sites.google.com/a/railsimd...l/blueprint-editor/weather-pattern-blueprints
The AP weather is set as fair cloud and the appropriate track marker put in and the settings done in scenario marker.
You should put that in the thread for AP weather, I know Kim Olesen's an expert on the random weather marker thingy.
In my earlier experience, when I saved a scenario with dynamic weather, it loaded with some other and didn't react until I played for the same duration, and then get completely stuck. Some NEC free roam has alternating rain and clouds, but once continued, it's mostly rain, unless you run longer. May have been fixed, what torf described should be the case. Or a restart. But not "stick with the one at T for the duration of T then continue".
There is a serz.exe in the root folder of the game. Copy the bin to something easy, open a command line and run serz.exe my.bin - it creates my.xml. Feeding it the xml creates the bin.
That's the most complicated way. Just create a shortcut to serz.exe on your desktop and drag the bin over it. Or, as I do a lot of modding, right-click on a .bin file and select serz.exe as a standard application. Doing this for .xml also, you'll only need to double-click for converting back and forth. I copy the .bins I wanna edit from the .ap to a temp folder and do my stuff there.
