[Genma Saotome]

Does anyone know what, if anything, ESD_Alternative_Texture(512) does?

Any others in that range?

[FS.E652 091]

Hi, i think that is a parameter for allow the Rain textures on object, check this:

https://www.elvastow...372#entry266372

[Weter]

Or winter textures on a rolling stock?
IIRC, Carlo did something around it.
Some locomotives I have, appear grey at winter time since some ORTS release.

[Jovet]

Genma Saotome, on 16 April 2024 - 07:51 PM, said:

Does anyone know what, if anything, ESD_Alternative_Texture(512) does?
Any others in that range?

The ESD_Alternative_Texture statement is supposed to represent a bitmask of available texture options.

For the uninitiated, a "bitmask" takes a binary number and uses each bit as a "switch" to control a particular option. The technical definition is a bit more deep than that but we won't worry about it.
Just as we can represent a decimal number with the digits 0-9, such as 1234567890, we can represent it in binary with the digits 0-1: 1001001100101100000001011010010
The leftmost (highest) bit is "1" and the rightmost (lowest) bit is "0". Each 1 or 0 position can represent an on/off option for something.

For the ESD_Alternative_Texture statement, it's just a matter of knowing what each bit is supposed to control. Turning "on" all the bits you want will create a binary number, which you can then convert to decimal for this value.

0 = No special options. Binary 0000000000000000.
1 = Use Snow textures. Binary 0000000000000001.
252 = Use seasonal textures. Binary 0000000011111100.
– Note that the value 252 invokes multiple bits, presumably designed to control individual seasons, but if this was ever documented in MSTS (or OR), I've never seen it.
256 Use Night textures. Binary 0000000100000000.
– Night textures are given an "illuminated" shader that makes them bright at night—unless they are colored very dark, they glow at night. This makes some types of intricate lighting/texturing effects and designs much easier.

These are the only bits defined that I'm aware of. To combine options, just add them together. MSTS had some bugs in this department but I'm sure OR does not.

[Genma Saotome]

Jovet, on 17 April 2024 - 05:42 PM, said:

0 = No special options. Binary 0000000000000000.
1 = Use Snow textures. Binary 0000000000000001.
252 = Use seasonal textures. Binary 0000000011111100.
– Note that the value 252 invokes multiple bits, presumably designed to control individual seasons, but if this was ever documented in MSTS (or OR), I've never seen it.
256 Use Night textures. Binary 0000000100000000.
– Night textures are given an "illuminated" shader that makes them bright at night—unless they are colored very dark, they glow at night. This makes some types of intricate lighting/texturing effects and designs much easier.

These are the only bits defined that I'm aware of. To combine options, just add them together. MSTS had some bugs in this department but I'm sure OR does not.

Joe, I have this list ofwhat I think are all possible alternative texture combinations (NOT in the MSTS order of alternatives and I think I overlooked All seasons):

Conditions	        	        	Omitted		         	       		Problems
						
Default					No Seasons, No light change, no Precipitation				
Night					No Seasons, no precipitation				
Wet from Rain 				No Seasons, No light change				
Accumulated Snow			No Seasons, No light change				
Spring Only				No light change, no Precipitation				
Spring + Night				No precipitation				
Spring + Wet from Rain			No light change				
Spring + Accumulated Snow		No light change				
Spring + Night + Wet from Rain						What about one or the other??
Spring + Night + Accumulated Snow						
Summer Only 				No light change, no Precipitation				
Summer + Night				No precipitation				
Summer + Wet from Rain			No light change				
Summer + Accumulated Snow		No light change				
Summer + Night + Wet from Rain						What about one or the other??
Summer + Night + Accumulated Snow						
Autumn Only				No light change, no Precipitation				
Autumn + Night				No precipitation				
Autumn + Wet from Rain			No light change				
Autumn + Accumulated Snow		No light change				
Autumn + Night + Wet from Rain						What about one or the other??
Autumn + Night + Accumulated Snow						
Winter Only				No light change, no Precipitation				
Winter + Night				No precipitation				
Winter + Wet from Rain			No light change				
Winter + Accumulated Snow		No light change				
Winter + Night + Wet from Rain						What about one or the other??
Winter + Night + Accumulated Snow	
Night + Rain				No Seasonal Change
Night + Snow				No Seasonal Change			

IF I understand you correctly these could be a sequence of numbers, zero to around 30, and if the OR code could deal with it the numbers alone address all the possibilities.

OTOH, it the additive method was used then the sequencing numbers must jump by 256 with each MAJOR dimension (e.g., once for night, another 256 for seasons, etc).

In the list above, there are 3 major breaks to produce combinations: Season, sunlight/Darkness, and Precipitation... so that's 256. 512, 768.

So far, is this correct?

What seems to be the insurmountable problem: In one situation, a building might need textures than made it look wet. In another, with accumulated snow. I am at a loss to figure out how you provide for both conditions, one at a time.

Any thoughts?

[Jovet]

Genma Saotome, on 17 April 2024 - 09:11 PM, said:

IF I understand you correctly these could be a sequence of numbers, zero to around 30, and if the OR code could deal with it the numbers alone address all the possibilities.

Dave, I'm not sure where you're going with the "sequence of numbers" part. In MSTS, the ESD_Alternative_Texture value bits just told the game which type of alternate textures were available by the route author when the time came to invoke them. MSTS's functionality was limited. The connotations of subfolders in the Textures folder were limited. As I recall there was a bug, but even if there wasn't, I don't believe MSTS would respond to both "Snow" and "Night" at the same time. So, even if there was a SnowNight or NightSnow folder, it wouldn't make use of any textures in it (for example).

All of MSTS's texture options at once would be:
0000000509 or hexadecimal 0x01FD or binary 0000000111111101.
These are all the same value, just in different formats. To my knowledge, ESD_Alternate_Texture only understands decimal numbers. As I recall in other spots, where "flags" are invoked such as in the TDB, which is the same bitmask concept, those are represented in hexadecimal. https://www.elvastower.com/forums/public/style_emoticons/default/nea.gif

Genma Saotome, on 17 April 2024 - 09:11 PM, said:

OTOH, it the additive method was used then the sequencing numbers must jump by 256 with each MAJOR dimension (e.g., once for night, another 256 for seasons, etc).In the list above, there are 3 major breaks to produce combinations: Season, sunlight/Darkness, and Precipitation... so that's 256. 512, 768.

It's just powers of 2, as that's what each bit represents (just in a regular decimal number each digit represents a power of 10).

The "breaks" are there, but they're simply groups of similarly-functioning, mutually-exclusive bits. The actual values/choices of the bits are not really important beyond all of us knowing what they are so they can be employed. Since OR (or ORMG) seems to have defined bit 10 for Wet/Rain textures, the complementary bits 1 and 10 are no longer adjacent, which is fine. The second bit (0000000000000010) was never defined, to my knowledge. Perhaps Kuju had intended it be reserved for "Rain" textures. We'll never know.

Genma Saotome, on 17 April 2024 - 09:11 PM, said:

What seems to be the insurmountable problem: In one situation, a building might need textures than made it look wet. In another, with accumulated snow. I am at a loss to figure out how you provide for both conditions, one at a time.
Any thoughts?

A lot of work, that's what. Rain and snow are complementary, they'd never need invoked by the game at the same time. It's either dry, raining, or snowing—never any combination of those. The same is true for the seasons... it's never Autumn and Spring at the same time. These are the "breaks" you were speaking of above. This makes things a bit easier.

Where one goes into the weeds is stacking many of the non-mutually-exclusive options on top of each other. For example, if you wanted snow-seasonal-night texture for a shape, then you'll first have to hope the game knows how to handle that (e.g. what folder name it's going to look in), and on top of the regular texture you'll have to make all of the individual combinations. In this example, on top of the dry day textures, dry day textures for each season, day snow textures for each season, and then dry-night textures and snow-night textures and then all of those for each season... a lot of work. I can't claim to know how deep in the rabbit hole OR will go. I just know that no one ever had much success setting this up with MSTS because it had bugs with regard to handling Night textures (especially in combination with anything else, as I recall).

Any of the higher bits could be defined by OR as it sees fit. We can assume the ESD_Alternate_Texture value was intended as a 32-bit number. Perhaps some visual tricks/adjustments/effects could be applied to textures by the game itself without having to provide hand-crafted textures for each and every situation. Higher bits could enable those effects as desired, or something. There's a lot of potential for experimentation and growth in this area.