[railguy]

It definitely would involve some programming challenges (I freely admit that I am NOT a programmer). I was thinking along these lines of having something like this in the stream definition:

TimeOfDay (1) - example, 0=ignore, 1=day, 2= night 3=day and night.

Season (1) - example, 0=ignore, 1=summer, 2=autumn, 3=winter, 4=spring. One could do additional definitions for combinations of seasons, for example, 5=summer and autumn, 6=autumn and winter, etc.

Precipitation (1) - example 0=ignore, 1=clear, 2=rain, 3=snow

As OR has done in some other parameters, having the program invoke the parameters when they are present, but fall back to MSTS default if they are not would allow both legacy MSTS streams and modified OR streams to run.

So, in my frog example, if one only wanted the frog sound in the summer at night in clear weather, the SMS stream could be coded thus:

TimeOfDay (2)
Season (1)
Precipitation (1)

Then, if one wished to use the same sound source for a meadowlark chirping in on a clear summer day, the stream could be coded thus:

TimeOfDay (1)
Season (1)
Precipitation (1)

And, for the same sound source to have a blustery winter wind blowing from the same sound source, one could code a stream like this:

TimeOfDay (0)
Season (3)
Precipitation (0)

Like the MSTS headlight function, one could only code the parameters that one needed to "filter the stream." In the above example, for the winter wind, one could just code the Season (3) parameter without worrying about the others.

Just some more food for thought. Thanks.

[disc]

The question is, what does MSTS say to these parameters?

[copperpen]

As the sms is a text file I would think that MSTS would do the same as always, ignore what it is not coded to read. So prefix the new parameters with ORTS.

[Csantucci]

I have tested inserting above lines before the Triggers ( line within a Stream of an .sms file. MSTS doesn't complain and continues to run correctly.

[James Ross]

railguy, on 13 November 2015 - 07:21 AM, said:

TimeOfDay (1) - example, 0=ignore, 1=day, 2= night 3=day and night.

...

Like the MSTS headlight function, one could only code the parameters that one needed to "filter the stream." In the above example, for the winter wind, one could just code the Season (3) parameter without worrying about the others.

Just a little note: if we do add something like this, the values should match those uses in the lights (ideally using the same enums in code) to avoid unnecessary confusion. Additional values useful here might also be useful in the lights, too.

[Csantucci]

Best would be using strings like Season ( "Winter" ).

I remind that there is already the possibility to add to the activity location specific sounds (see paragraph 10.16.4 of the manual), which already can satisfy some of the above needs.

[James Ross]

Csantucci, on 13 November 2015 - 10:57 PM, said:

Best would be using strings like Season ( "Winter" ).

Why? Unless MSTS ignores ORTSWeather("Rain") but doesn't ignore ORTSWeather(2) I'd rather we matched the lights when in MSTS data files. (Obviously we'd have to pick some numbers of the season but the others have existing values.)

[roeter]

Quote

Precipitation (1) - example 0=ignore, 1=clear, 2=rain, 3=snow

This misses out fog. Think about foghorns on boats, lighthouses etc., so Precipitation should be Weathertype, and add 4 = fog.
Another possible option would be to link the sound to the calculated visibility.

By the way, adding visibility to possible options for engine sounds would be interesting as well - let's hear all those AI trains blow their horns and whistles in fog as they used to due.

Quote

TimeOfDay (0)
Season (3)
Precipitation (0)

Wind is calculated in the program, so why not create some setting which can relate the sound to the calculated wind?
It would be pretty odd if the wind is seen blowing fierce (visible in exhausts of engines) while the sound remains silent, and similar the other way round.

Regards,
Rob Roeterdink

[Csantucci]

James Ross, on 14 November 2015 - 04:01 AM, said:

Why? Unless MSTS ignores ORTSWeather("Rain") but doesn't ignore ORTSWeather(2) I'd rather we matched the lights when in MSTS data files. (Obviously we'd have to pick some numbers of the season but the others have existing values.)

I'm sure you know the difference between binary code and assembler. Assembler is a bit easier to understand by reading and to remember by writing to humans. So, it's the same with "1" and "winter".

[disc]

I've just added a new .sms variable called CurveForce(for flange sounds), which works if the "Curve dependent resistance" is enabled at simulation tab. The problem with the CurveForceN variable is the sudden changes, for example at straight its 0 then at the start of the curve, it instantly rises, then drops to 0 at the end of the curve, and that isn't sounds good. This is because the tracks in MSTS routes don't have Transition curves, but that can't be changed.
So i tried some filtering, to make the the sound changes smoother. I've tried the already implemented MovingAverage filter, but that is FPS dependent, so it's not an option. The butterworth IIR filter works great, but looks too "heavy" for me, however it didn't change the update process CPU usage noticeably, but still a simpler FPS independent filter would be better. Any suggestions?