Hi, as promised here's my parameters that will expand your AP TimeOfDay files for almost all available TSC routes. As the TimeOfDay system only provides one day representing a whole season, we don't need to be that exact. (Each day is different in reality, but that's covered already by SilverLining (DynamicClouds/3D Weather) for those that prefer it, or for polar regions like Scandinavia where TimeOfDay technically fails due to fixed E/W sunrise/set nodes.) The big advantage is you now have high standing "desert" sun in regions around LA, while using your AP clouds. I have asked AP, they won't do another pack themselves (APWeatherEP is based on London latitude and daytime length) What you need to do: 1. Set up a folder somewhere on your PC, name it "MyAPWeatherEP" or such 2. Create two folder named "US" and "AUS" 3. Copy the original "TimeOfDay" folder from "Assets\AP\WeatherEP" to the "US" folder 4. Unserialize the files from .bin to .xml format using "RailWorks\Serz.exe" 5. Make the changes to the defined times according to the supplied table in the "US" folder 6. After you have done so, copy modified "TimeOfDay" folder to the "AUS" folder 7. As the sun/moon is crossing the northern sky here, remove the minus from the two azimuths 8. Serialize the files from .xml to .bin again You now have a master TimeOfDay folder for the US and the southern hemisphere NZ area. Copy this to the routes' asset folder where it applies. Sometimes, you need to rename the files so they match the ones referred to (G-TraX often use SP-RW3-Summer.bin for example). This world map shows where your set of ToD files would apply: (the subtropical /tropical zones inbetween don't have seasons in reality - this is where you could apply ONE blueprint for all times as the sun is almost the same (6AM to 6PM) on each day of the year - they only have "weather" seasons, as opposed to the polar regions which have months-long days and nights as they are both facing the sun for half a year, not half a day, due to tilted earth's axis (thanks to the moon). Miami, being on the same location as Dubai (or technically: passing the same location during earth's rotation), or MachineRail's brazilian "Dom Pedro II" route for example could use a Spring blueprint all the time. Here's the data: Code: US SPR+AUT SUMMER WINTER ------------------------------------------ SunRise 07:00 06:00 07:30 SunSet 19:00 20:30 17:00 SunAzimuth -0.7 -0.3 -1.1 MoonRise 19:00 20:30 17:00 MoonSet 07:00 06:00 07:30 MoonAzimuth -0.7 -0.7 -0.5 BreakOfDawn 06:30 05:00 06:45 Dawn 07:00 06:00 07:30 Morning 08:20 07:20 08:50 Noon 12:00 13:00 12:00 EarlyEvening 17:00 19:10 15:50 Dusk 18:50 20:20 16:50 Night 19:00 20:30 17:00 Midnight 20:00 21:30 18:20 For the southern hemisphere TimeOfDay files (South Africa, New Zealand), use the same values EXCEPT make the Azimuths positive (remove minus) -Spikee1975 Note: When it says "Midnight" for example in the blueprint, this doesn't mean exactly midnight, it's just when the respective colour palette blends in. It's just one of eight times of day the artist can freely define as he wants to. Note that the "Dusk" and "Dawn" ToDs will have an effect on lightsources which have the "DaylightCycle" flag set to true - such as station or street lights. In short: The further away from the equator, the longer the days in summer and shorter in winter, but also the sun's curve will be flatter. The closer to the equator, the more equal daylight time is across the year, and the sun's curve will be steeper, almost vertical, therefore having to travel a shorter distance through the atmosphere and being of significantly higher energy. Enjoy! If you have questions or something's unclear, just ask.
So I'm guessing just the standard AP SAWEP could just be used for all UK, German, Austrian, Swiss and French routes? For parts of the US, which routes could still use the standard pack without modifying? What would happen if the times were changed to reflect super long days like in Australia/NZ has in summer due to Daylight Savings, and places like Alaska where the sun barely rises above the horizon?
You can see on the map I've supplied which version applies. The default APSWEP applies to most of Europe (except southern countries like Spain, Italy, and Greece where you'd use the US ToD) as well as Canada. TimeOfDay files are only an approximation, as said you can pick one day only to represent three months. To have full accuracy, you must use DynamicClouds in conjunction with any "3D. ...." weather blueprint. This will use exact daylight simulation based on the route coordinates and the scenario date field. (Of course small deviations due to time zones being set for political/economical reasons and not exactly being astronomically correct IRL, but that's not something to be bothered about in a train simulation.)
What I'd be more interested in is that say a route was built in the US or Australia that covered a section over a state border with a timezone difference of 1hr etc, could that be represented in the simulator (like in a scenario, could the time shift 1hr forward or backward etc) when crossing a state border
Also, if I wanted to I could modify the times (as shown above) to simulate the average times in my home country (in this case Australia)?
Of course. Note that the different times set for each timeofday pattern should match the path of the sun - otherwise you'll get bad effects like in some routes, which are pretty dark but the sun is still up. Just create your own set and play around. You can test your settings by using the "TimeScale" value in the blueprint, set this to 600 for example for testing your season file with accelerated time. And no, traveling through timezones is not simulated. The clock is always local time where you start your journey.
This is really useful, thank you. As for places with unusual sun rotations such as the polar regions (not that there are any North Pole routes in TS, other than the Great Western Main Line), I am aware that 3D weather is the best bet for these. However, I don't like the lighting nearly as much as the lighting provided by AP weather, so is it theoretically possible to modify AP weather for these areas or is it off limits? On another note, is it theoretically possible to combine the AP and 3D weather systems in some way to have the best of both worlds?
Well, there's routes like Narvik-Luleå for example. Using 3D weather you can do midsummer runs under the midnight sun which never sets. The TimeOfDay system is a completely different environment, your sky is a dome (Environment\Sky\SkyDome.GeoPcDx) that can rotate various bitmaps in different transparencies defined by the weather blueprint. In SilverLining (3D) there is no bitmaps and the colouring is based rather on definition of atmospheric density and parameters, and clouds are objects that can cast shadows onto the ground. 3D uses its own skydome and weather blueprints, there's a config file you can alter. AP/TS weather gives you an illusion (albeit a nice looking one), while 3D is more of an environmental realtime simulation. While in reality the sun only rises exactly in the east and sets exactly in the west on two days of the year (end of march / september), it will always be like that in 2D/AP weather no matter if summer or winter. Both systems use completely different sky models, blueprints and are incompatible. A 3D weather blueprint defines cloud layers, defining the cloud type, layer height, if it's local to the player or location, if clouds expand and so on. The biggest disadvantage of 2D or AP weather is that the distance fog (mountains) is depending on the upper sky colour defined. In 3D it's not, you have distant mountains not being tinted blue there. Also, correct moon phases and path of the moon - in 2D/AP it's always the same no matter which phase - as you can only set one azimuth per season. I find the night lighting using 3D far superior to any 2D blueprint - at the moment the stars are missing but that's known to the team and should be fixed in an update. Of course, we're still away from a perfect 3D environment, even Flightsims still are. As a bitmap cloud image is a photo, it may look better at times than procedurally generated clouds. And some 2D trees look better than 3D counterparts. The ETS2 weather system is such a combination of the best of both worlds - it dynamically adjusts daylight and sun azimuth based on your location - endless polar day on Svalbard, quick nightfall in the desert - and it works even if you're driving the tour in one run, while displaying beautiful cloud images and blending them over dynamically. All you need to set is rain probability, and the result is good. Of course it doesn't feature seasons yet, but it's in the works. TS 2D sky: Yellow is the sun path - it's always anchored to East/West, the azimuth defining the tilt. (0 means vertical path, pi/2 means at the horizon, which is not possible in TSC (there has to be a sunset/sunrise!), so the azimuth is limited to 1.5, which will have the sun travel very low above the horizon. This shows the issue - you could say I'll define an AP season for the North, by setting sunset at midnight and sunrise at 1AM - the problem is the sun would just jump from West to East, as it is not in the North at midnight. Of course this is real geek stuff but that's something I'm into since I first visited Norway and experienced the midnight sun, thinking about the Earth. Without its 23 degrees tilted axis in relation to the ecliptic which was caused by the moon, we'd have no seasons, same daylight no matter where you were, and a completely different vegetation. Or even hellish conditions like on Venus, which rotates so slowly (one Venus day lasts 243 Earth days) that the side facing the sun is heating up and due to greenhouse effect to 460°C.... With these three sets of AP TimeOfDay, you basically got all you need. And where it fails, 3D comes in. You can also adjust things, I might reduce that huge corona glare at noon for the US sky (by actually increasing the SunGlare value). AP uses it to have the nice sunsets and introduce a third sky colour using that trick. Compared to other train simulators, TS still has the most sophisticated and flexible environment system - even offering two different systems to choose from, one paint-your-own-sky and a ready to use auto-adapting 3D one. TSW is much more limited in terms of cloudscapes, only cumulus (and sun sets waaay too early there. Station lighting is not fixed to dusk/dawn there, which leads to completely dark stations sometimes)
That all looks right. Only thing that is outdated is this, "The biggest disadvantage of 2D or AP weather is that the distance fog (mountains) is depending on the upper sky colour defined. In 3D it's not, you have distant mountains not being tinted blue there.". AP fixed that in 2.0 of their Sky/Weather EP. Any remaining blue tinge is an average reflection of reality but of course this varies depending on many more variables that TS doesn't support.
Didn't know this, thanks. I'm on v1 of the AP (only bought it for the 320 colour defs, as I'm keen on vanilla compatibility I'm using the core sky which doesn't need AP weather blueprints, so I get the looks (but not the clouds, yes I'm happy with the Kuju (NOT RSC/DTG) clouds) plus all scenario weather blueprints (and there's many great dynamic custom weather scenarios) work without changing them to AP ones, so all DLC scenarios are compatible. As the AP skydome is three times bigger than the DTG one, that's were weather blueprint incompatibilities arise (especially due to wind speed which rotates the layers). So I made my own sky. AP colours applied to core skydome (by replacing the AP sky.GeoPcDx ref with RailSimulatorCore sky and dividing all gradient values by three in the season files)
Wow how did I not see this thread before? Brilliant stuff, extremely helpful! I will definitely be using these edited weather files for those regions you mentioned.
I copied these and feel that they should be made available to the community. Is it ok if I upload them to Train Sim Community with credit to you?
You must not distribute the TimeOfDay files, as these are Intellectual Property of AP. (Yes, all those colours and stuff too). That's why everyone must apply these changes for themselves. The edits are way too small to not qualify as a violation of copyright if distributed as files. from the APSWEP manual:
If you are making a route, it's enough to use Kuju\RailSimulatorCore\TimeOfDay\Core_Spring.xml and so on, as AP replaces these core files upon installation (a verification will remove them again though). This way, it'll automatically work, no matter if you got the AP pack or not. Also, using the 3D weather blueprints for scenarios will automatically use AP weather if present and DynClouds are off.
I don't have the knowledge of making a route, but good to know in case I want to use AP weather on high iron simulations routes that only have one weather file.
In that case (Saluda I think), extract the route template from the Saluda assets .ap. You will find that for each season, the same TOD blueprint is given. Change them accordingly (Spring.xml, Summer.xml, Autumn.xml, Winter.xml), serz the template, make a folder Assets\HIS\Saluda\TemplateRoutes, put your changed template.bin in there and copy an AP TimeOfDay folder (preferably with my US modifications applied) to Assets\HIS\Saluda. That's all.
