... when using SilverLining 3D weather aka Dynamic Clouds. (3D Clear, 3D Cloudy, 3D Raining etc..) I always thought the date field in the scenario properties is of no use really, as stated in the dev docs too. But if you use 3D weather it does take the month into account, not just the season (which determines the textures). Sunset and Sunrise are then calculated based on the route's latitude and date in the scenario properties, overriding the TimeOfDay blueprints used when Dynamic Clouds are disabled. Try for yourself!
Here's an example. Season is set to spring in both scenarios. First one has date Feb 21, second one Jun 21. Weather is 3D 2. Cloudy. February June When using standard weather (2D bitmap sky), the date is ignored and the sunset/sunrise is read from the TimeOfDay blueprint, and both scenarios will look the same because only the season you chose will matter.
I've noticed that the sun is in the right compass position for the time of day in 3D weather, but can be ridiculously out of position in standard weather; i.e. rising in the north and setting in the south.
Yes. And with 2D weather you only have 4 predefined sunset/rise times. And the moon is ridiculously big sometimes. This strikes me because I did not know about this for years. Nice to see that TS is capable of more than I thought.
Torf How does that work in the Southern Hemisphere? Do we still get Winter weather in January which is our summer? I'll have a try later on! pH
The vegetation, which is objects and texture, depends only on the SEASON you choose in the editor. The day/night cycle in 2D weather depends also solely on the SEASON. The day/night cycle in 3D weather does NOT depend on the SEASON but on the DATE and LATITUDE of the route's origin. Peter, I'll check with the NZ Midland Line. As I know figured out that the 3D weather is calculated and not predefined in TimeOfDay, the sun should be in the North at noon. Quick way to test: Create a new route with polar latitude (+- 67-90 degrees). Set date to June (December for southern hemisphere). There should be no sunset at all and you should see a polar day.
I can confirm the 3D weather calculations are realistic. Southern Hemisphere midsummer, Dec 21, 11:59 pm. Midnight sun. (created a new route at 70 deg south, season set to winter just for fun. Note: FlatEarthers should not read this
Regarding the date, I wish DTG could change the date entry either by adding labels or setting to ISO (y-m-d). My favorite date is 05/06/07 and I genuinely have no idea when it happened. (I mean, since we say quarter past 5, the time format should be minutes:hours, too. It's 26:14 right now.) ((Except in my language we say quarter 6, or right now half 3.)) I think it's dmy in TS because it's British and it starts with 01/07/2010, supposedly Summer.
Correct and I believe that apart from North America most of the ROW uses the same protocol but I stand to be corrected (and am willing to learn). This Forum being British uses British protocol, RWA being US based uses American protocol, you learn to live with it. The one everyone uses is 01/01/xx
My country actually uses yyyy.mm.dd, which is sortable. I wouldn't mind dmy but with the US doing mdy I'm regularly confused and default to ISO, which is yyyy-mm-dd. Very often I don't know the actual format. I only see nn-nn-nnnn, so I have to guess. Some dates like 12-31-99 make it clear, regardless of sequence. Computers usually use mm-dd-yy(yy) by default, because they somehow end up with US settings, or that's the default fallback. So being a programmer for 25 years I automatically assume that computers use either yyyy-mm-dd or mm-dd-yyyy. Hence the point, using the standard or just clarifying with a caption would be neat. Sure, there is no icon for it...
Understand your frustration but when DTG (a British company) started out I doubt international date notation entered their heads, to be honest it only mine entered years ago when I first dealt with German and US companies and then I used the notation for example: 01 January xxxx for clarity. That was back before IBM invented PCs and Apple was fruit or the Beatles' record label.
That is also an English method, day before month. Here in normal, we put month first. It seems more natural and less robotic to say February 1, for instance, than 1 February.
Anyway if the format is known it should be no problem. I just find it interesting that it is actually used, I often left it as is and just chose the season believing it was the only important thing for day/night cycle. And the dev docs are totally dated and not maintained anymore it seems.
