[darwins]

Does OR need to consider a new, more comprehensive and more user friendly approach to sound file management?

The present MSTS format for sms files, is neither particularly easy to use or easy to expand to include new variables.

Although not a sound expert I can understand the need to divide files into "Scalability Groups" and "Streams". It is surely possible to make a structure where the user does not need to count the streams and triggers though. Perhaps end of stream or end of group markers are needed or perhaps the closing brackets will be sufficient.

The main suggestions I would like to make are that a sound system could

( a ) allow user defined names for groups, streams or triggers so that one stream or trigger could be called by another rather than having to count them;

( b ) allow game variables to be called by the higher level names that are used by OR - throttle, current;

( c ) allow the use of additional logical functions in sound triggers, retaining Inc_Past and Dec_Past, whilst adding >, <, =, IF, THEN, AND, OR, NOT.

For a locomotive this could result in something like:

Stream ( Blower sounds )
Comment ( Plays traction motor blower sounds when running and for a short time after stopping )
Trigger (start blower)( IF pantograph = 1 AND throttle Inc_Past 0.1 THEN play_1_shot ( startblower.wav ) fade_out )
Trigger (blower running) ( IF Trigger (start blower) = 1 play_loop ( blower.wav ) fade_in fade_out )
Trigger (stop blower) ( IF Trigger (start blower) = 1 AND throttle = 0 AND speed = 0 Random_wait ( 10s 40s )THEN end_loop fade_out AND play_1_shot (stopblower.wav) fade_in )
Trigger ( ) ((start blower) = 0 (blower running) = 0 )
EndStream

As new variables are introduced exhauster, overcharge, notch_up, notch_down and so on they are readily accommodated by the sound system.

There are even more possibilities for external sounds in OR:

Trigger (school) ( IF season NOT summer AND time > 08:30 AND time < 15:30 play_loop ( school.wav ) )

Trigger ( ) ( IF wind > 30kmh play_loop ( wind.wav ) )

Trigger ( Slipery Surface Warning ) ( IF weather = rain OR ambienttemp < 1 THEN Random_wait ( 150s 300s ) THEN play_1_shot ( slippery_platform.wav ))


Not sure how much of this makes sense. The intention here is to start a conversation, perhaps leading to a Trello card for the road map later.

[DirtyRam]

Right on Darwins,
Calm, constructive conversations.
I concur with your intentions, and trying to make better the Open Rails sim, where we can.

Mike

[Weter]

Hello.
1. With ORTS, it seems to me, scalability groups are out of use, aren't them?
2. I use Skip () and type stream name/function in between those brackets.
It's like a Comment () in *.eng/*.wag files.

Trigger (
(* start blower *) 
Actual data
)

might work now...
2. Current Variable2, for instance, combines a number of parameters, and is different from steam to diesel and electric locomotives, so it have a common name, instead of just "throttle", or "load"
3. There is real lack of variables, I agree.

Looks as a program code. But don't forget about things like "disable trigger1", or "set stream3 volume": numbers are still more handy?

So, maybe, not completely "new", but extended/alternative?
Also note, some devs prefer Json format during last years.

[darwins]

Weter, on 15 October 2022 - 07:14 PM, said:

Also note, some devs prefer Json format during last years.

That might be the way to go. I do not know what that looks like though. Are there any examples or tutorials for us non-devs?

[Weter]

Not sure; seems, I've seen some descriptions somewhere...
Many pages were written on discussing new consist format (I've stopped following), so maybe there?

Anyway, as I understand, it's gonna be all new pure-ORTS files are planned in json format.

[dforrest]

Weter, on 15 October 2022 - 07:14 PM, said:

Hello.
1. With ORTS, it seems to me, scalability groups are out of use, aren't them?

Are you saying that "scalability groups", and perhaps other sound commands, are not used by Open Rails?

[Weter]

Hello.
Sure, SL0 (AI -controlled train's sounds) is no more used as so, because AI trains under ORTS use the same SLs as player train.
Also, ambient sounds are mixed now to cab sounds, and user can specify the amount in sound options.
All MSTS triggers are working, but cue points have to have more strict names (1&2), much more new triggers were introduced - see CTN site for table.

[Jonatan]

Are we talking making additions to, or completely replacing the current sound system? I will defy the latter option as much time by talented people have gone into the making of custom sound sets for models over the years. Throwing that effort away is absolutely unacceptible.

If a new system in addition to the current one is added and supported then I say go ahead, it may open up more doors for new content creators.

[darwins]

Jonatan, on 16 October 2022 - 04:51 PM, said:

Are we talking making additions to, or completely replacing the current sound system? I will defy the latter option as much time by talented people have gone into the making of custom sound sets for models over the years. Throwing that effort away is absolutely unacceptible.

If a new system in addition to the current one is added and supported then I say go ahead, it may open up more doors for new content creators.

I think there is a misunderstanding here. Having a new system available for new content, does not mean dumping pre-existing work. OR is constructed on the basis that historic / legacy content will continue to work.

My feeling is that there should be many more possibilities that were never explored with the existing MSTS format.

[ErickC]

I like the idea - if the number of streams will no longer need to be counted, then I also think we should also have the flexibility of using include files within sound definition files. One of the most annoying things for North American stock is managing the sheer amount of options like horns and bells - if the main sound definition file simply had paths to include files with the stream data for the options (e.g. one include file for a 16-645E3 prime mover, one for two-stage dynamic brake fans, one for the EMD Dash-2 control console, one for a Leslie S3L, and one for a steel bell), then the process of managing options could be simplified. Not only that, but a base universal set of horn and control console sounds could then be developed that would go into a common folder for use by anyone.

I still like my idea of horn air pressure being a variable (with the ramp up/down in PSI/second as a ENG file variable) so that we could have horn samples at different pressure levels obviating the need for cued clips... but that's just me. :)