[scottb613]

Hi Folks,

My question for today is related to Tertex - which kind of came up on the other forum.... Will OR support the Autumn Tertex folder ? If I recall correctly - MSTS supports seasonal Tertex changes but MS in their infinite wisdom decided they didn't like Autumn... It's the only one that didn't work... If we put an Autumn seasonal Tertex folder in a route - will it change on demand in OR ?

Thanks...

Regards,
Scott

[charlie]

scottb613, on 29 May 2013 - 02:39 PM, said:

If I recall correctly - MSTS supports seasonal Tertex changes but MS in their infinite wisdom decided they didn't like Autumn... It's the only one that didn't work...

Unlike vegetation, MSTS has never supported seasonal terrtex. Although not truly "seasonal" in the conventional sense, there's a snow sub-folder containing terrtex that's called at appropriate times. That's all...

regards,
charlie

[scottb613]

Hi Charlie,

Oh - thanks... Yeah - now that you mentioned it - it was only winter.. Well - you would think it wouldn't be a big deal to point to a different sub folder based upon seasons... Maybe we can have them someday...
:)

Regards,
Scott

[Csantucci]

In fact it seems a good idea, and it should be easily implementable.

[disc]

folder? Perhapsa file name extension would be better, like railworks. There the seasoned textures look like this, and work on any kind of objects, including rolling stock:
exampletexture.tgpcdx = summer(and default) texture
exampletexture_sp.tgpcdx =spring
exampletexture_au.tgpcdx = autumn
exampletexture_wi.tgpcdx = winter

The objects reference on the default(summer) texture, then the game loads the texture what is appropriate to the season.

[scottb613]

Yeah - I've dabbled with route building and having true seasonal Tertex would be a big improvement - for what I would think would be minimal investment in development time.... Really appreciate all your efforts - folks...
;)

Regards,
Scott

[Csantucci]

disc, on 01 June 2013 - 02:27 AM, said:

folder? Perhapsa file name extension would be better, like railworks. There the seasoned textures look like this, and work on any kind of objects, including rolling stock:
exampletexture.tgpcdx = summer(and default) texture
exampletexture_sp.tgpcdx =spring
exampletexture_au.tgpcdx = autumn
exampletexture_wi.tgpcdx = winter

The objects reference on the default(summer) texture, then the game loads the texture what is appropriate to the season.

That's against the MSTS standards, that foresee that object and terrain textures for different seasons (for terrain up to now only standard and snow) maintain same name and are located in different folder.

[scottb613]

Hi Folks,

Just curious - was complete seasonal coverage ever implemented in OR ?

Regards,
Scott

[SVRy_Steve]

Add my name to the list of those who'd like seasonal terrtex! It might be pushing it, but it would be nice to have separate winter and snow textures. Most locations have winter :bigboss: but many rarely get snow.

Another thought would be a way to use winter textures at low elevations and have snow in the passes. I've often wished for a way to do this with trees as well (easily). If we could set autumn, winter and spring to have snow above a certain elevation and the other textures show below it would be great. I've read so many stories of trains leaving a low elevation with spring weather, men in short sleeve shirts, no jackets, only to hit a blizzard in the mountains, that this would be a very "cool" addition!

Steve

[Genma Saotome]

IMO what is needed is a full separation of Tertex / Shape textures / MSTS seasons and precipitation structured into a new approach of Living and Non-Living. All would provide for precipitation but only living things would have seasons. What that means is actual practice is a whole lot of directories but I beleive, in the end, it would be worth it.


My operative assumptions are

• Unlike MSTS the organizing directories remain empty.
  
• Everything can vary by precipitation type.
  
• Anything that varies by season does not vary by time of day.
  
• Anything that varies by time of day does not vary by season.

Something like this:

Textures For Seasons
	All Seasons
		All Weather
		Dry
		Rain
		Snow
	Spring
		All Weather
		Dry
		Rain
		Snow
	Summer
		All Weather
		Dry
		Rain
		Snow
	Autumn
		All Weather
		Dry
		Rain
		Snow
	Winter
		All Weather
		Dry
		Rain
		Snow

A parent directory, A default directory, four seasons, each having a default plus 3 precipitation directories... 21 in all. The textures would be used on terrain and plants.

Something similar is needed for man-made objects but calls for an extra level for dealing with night... something like this:

Man Made Textures
	AllTimes
		All Weather
		Dry
		Rain
		Snow
	Daytime
		All Weather
		Dry
		Rain
		Snow
	Nighttime
		All Weather
		Dry
		Rain
		Snow

A parent directory, three times-of-day, three precipitation types, that's 13 more... 34 in all.

In both trees there is a purposefully identified default location -- AllSeasons + All Weather for seasonality and AllTimes + All Weather for man made objects. All of the other directories are entirely optional.

Display choices would be set in something equivalent to the .sd file's ESD_Alternative_Texture() parameter (tho it might take multiple values to properly identify the full set of circumstances as there can be different combinations in play... something akin to ManMade(Y) + UseSpecificTimes(Y) + UsePrecipitation(N) = Daytime + All Weather and Nighttime + All Weather). I believe the directory structure I'm advocating would handle all situations properly, unlike the KUJU design which goofed up /snow and /night.

If the later two are not correct then the necessary number of directories jumps up by quite a bit.