[disc]

Looking at the AI trains, i'm annoyed by the brake hissing sounds which are sometimes played for minutes after the AI touched the brake lever. I've looked what happens, and i saw that the AI is very rough, so isn't capable of constant braking, but pulling the brake lever like like a lunatic... apply, full release, apply, full release, sometimes in a second. That's one part of the problem, but the other part is with the .sms files.
Because of the limits of MSTS, the rolling stock developers are using oneshot brake sounds activated by discrete triggers, and are queued. That's why the brake hissing stays for minutes with AI after the last brake pressure change: if there is a brake release hissing sound set in .sms, and the AI releases the brakes 40 times in few seconds, then the sound is played 40 times until the queue is empty. For a problem like this, TS20xx have an option, called "reject new", which rejects the playing of the new sound in a group, if another one is playing.
Is there anything like this in MSTS/OR?

The other branch of this problem, is: Why are the brake hissing sounds are played as oneshot, why not as loop, like in other train simulators? For example: the loop is started when the brake pressure starts to change, and released when the pressure change stops. As i see in MSTS/OR this is currently not possible, as there are triggers that shows that the pressure is started changing ( TrainBrakePressureDecrease aka trigger 54, and TrainBrakePressureIncrease aka trigger 14), so a loop can be started, but when to stop? For that i think new trigger is needed, something like TrainBrakePressureNotChanging, which can be used for releasing brake hissing loop. Maybe othe new triggers could be adder, or even new sound controller variables, more than the current three.

I have another thing in my mind: these numbered discrete triggers, and variables that have names "Variable1, Variable2, Variable3" are not too informative. What about an optional(of course MSTS style .sms compatibility should stay) feature in OR that can read triggers with textual names? I think that would make easier to edit and read .sms files for the developers.

PS: What MSTS does if there are such "alien" parameters in .sms files, that are written above?

[Csantucci]

disc, on 27 September 2015 - 08:51 AM, said:

The other branch of this problem, is: Why are the brake hissing sounds are played as oneshot, why not as loop, like in other train simulators? For example: the loop is started when the brake pressure starts to change, and released when the pressure change stops. As i see in MSTS/OR this is currently not possible, as there are triggers that shows that the pressure is started changing ( TrainBrakePressureDecrease aka trigger 54, and TrainBrakePressureIncrease aka trigger 14), so a loop can be started, but when to stop? For that i think new trigger is needed, something like TrainBrakePressureNotChanging, which can be used for releasing brake hissing loop. Maybe othe new triggers could be adder, or even new sound controller variables, more than the current three.

That seems a good idea.

disc, on 27 September 2015 - 08:51 AM, said:

I have another thing in my mind: these numbered discrete triggers, and variables that have names "Variable1, Variable2, Variable3" are not too informative. What about an optional(of course MSTS style .sms compatibility should stay) feature in OR that can read triggers with textual names? I think that would make easier to edit and read .sms files for the developers.

Everything can be done, but personally I wouldn't spend time in implementing that.

disc, on 27 September 2015 - 08:51 AM, said:

PS: What MSTS does if there are such "alien" parameters in .sms files, that are written above?

MSTS doesn't care if you add new discrete triggers (identified by a number). I don't know what happens if you use names to identify triggers. You can try that :)

[disc]

Csantucci, on 28 September 2015 - 07:59 AM, said:

That was something I thought had been implemented in OR (I asked for that the person that revised the sound code, and got an affirmative answer), but I see that it seems not to be so now.

I've searched for the causes in code, and i see there is a hardcoded 16 element queue for the sounds inside one stream. I'll try to lower this to 1 and see/hear what happens. However as i heard, and as i remember MSTS didn't have this queuing behavior. But i don't know what would be the best: -disable queueing completely - or make the queue lenght user defined by an sms parameter?

Csantucci, on 28 September 2015 - 07:59 AM, said:

That seems a good idea.

As i see it's not hard to add new variable triggers and discrete triggers (however the sound debug form UI isn't ready for that :D ), think it would be helpful if all parameters of a locomotive that can be used for sounds, would be exposed to .sms. The question is, which trigger numbers should i use for these new triggers? As i see OR specific triggers are >100, maybe i just continue from the last used number, which is currently 136?
Perhaps i should create a blueprint on launchpad.

Csantucci, on 28 September 2015 - 07:59 AM, said:

I don't know what happens if you use names to identify triggers. You can try that :)

I can't, i'm using win 8.1 with an AMD gpu, on which MSTS doesn't starts.

[James Ross]

disc, on 27 September 2015 - 08:51 AM, said:

Because of the limits of MSTS, the rolling stock developers are using oneshot brake sounds activated by discrete triggers, and are queued. That's why the brake hissing stays for minutes with AI after the last brake pressure change: if there is a brake release hissing sound set in .sms, and the AI releases the brakes 40 times in few seconds, then the sound is played 40 times until the queue is empty. For a problem like this, TS20xx have an option, called "reject new", which rejects the playing of the new sound in a group, if another one is playing.
Is there anything like this in MSTS/OR?

I get annoyed by this sometimes in OR as the player when I'm making a bunch of control adjustments and the sounds just queue up for far too long. If this doesn't happen in MSTS we should definitely look at avoiding it by default for MSTS content, but either way adding an ORTS SMS flag to enable or disable queuing for specific streams seems sensible (like the "reject new" option).

TrainBrakePressureNotChanging also seems like a good idea, and should be reasonably easy to implement (assuming triggering repeatedly is fine).

[disc]

James Ross, on 28 September 2015 - 11:18 AM, said:

ORTS SMS flag to enable or disable queuing for specific streams seems sensible (like the "reject new" option).

But how can i add a flag, that is not interfering with MSTS?

James Ross, on 28 September 2015 - 11:18 AM, said:

TrainBrakePressureNotChanging also seems like a good idea, and should be reasonably easy to implement (assuming triggering repeatedly is fine).

Hmm repeated triggering... i didn't think about it. I don't think that would cause sound glitches, but probably more CPU intensive, so a "TrainBrakePressureStoppedChanging" would be better.


Maybe i've found a bug: i've looked the value of Variable3 on an eletric loco (which should show the percentage of current dynamic brake force), and i saw that even if the dynamic brake force is at max, variable3 never goes over 90% just if i apply the friction brakes too, which shouldn't. So i looked in the code, and i saw that Variable3 is computed using MotiveForceN which is a combined force value, and lowered by traction losses already (that's why variable3 never go above 90% alone), and also lowered by friction brake force (Because of this, the value could exceed 100%).

I think this is wrong(is it?), and Variable3 value should be a percentage of current rated dynamic brake force, without other forces, so i fixed this both in MSTSElectricLocomotive and MSTSDieselLocomotive. I've also looked at variable 2 on electrics which should be a percentage of current rated tractive force, but 100% never can be reached which means it shows the force at rails. I'll try to fix that too.

[slipperman]

Hi Disc,

Quote

I can't, i'm using win 8.1 with an AMD gpu, on which MSTS doesn't starts.

Oh yes you can and it does!! - at least for now :)
See here (post #16) : http://www.trainsim....d-in-MSTS/page3

Cheers,
Ged

[disc]

So here is the patch for diesel/electric Variable3, and for electric Variable2.  variable23fix.zip (1.12K)
Number of downloads: 447

BTW what should i do to get access to upload changes to SVN?

[Csantucci]

I think you will get a reply about your last question.

Referring to the multiple play one shot triggers for AI trains, I have committed a first tentative fix in x.3269. It checks more deeply if there already identical sounds queued for playing; at least in a specific case I found out that it drastically cuts out sound repetitions when the trigger cause wasn't there any more. However this couldn't yet be a solution covering all cases.
Maybe also on the side of the AI trains code something could be done to avoid too close trigger generation.
I am waiting for reactions.

[disc]

Csantucci, on 30 September 2015 - 04:37 AM, said:

I think you will get a reply about your last question.

Referring to the multiple play one shot triggers for AI trains, I have committed a first tentative fix in x.3269. It checks more deeply if there already identical sounds queued for playing; at least in a specific case I found out that it drastically cuts out sound repetitions when the trigger cause wasn't there any more. However this couldn't yet be a solution covering all cases.
Maybe also on the side of the AI trains code something could be done to avoid too close trigger generation.
I am waiting for reactions.

I've tried to make the AI driver less rough, as i've made a gentle automatic train control for TS from 200 lines of lua script, but the current AITrain.cs is so overcomplicated(i think a lot of things should be moved out to seperate methods, as the those 1000+ line methods does not look right) and there are the shunting, and other "exceptions"... i can't see through that.

Hmm as i see you limited the repeating of oneshots in 3269. That's maybe a better idea than mine (i wanted to limit the queue itself, at least for a try).

[markus_GE]

Csantucci, on 30 September 2015 - 04:37 AM, said:

I think you will get a reply about your last question.

Referring to the multiple play one shot triggers for AI trains, I have committed a first tentative fix in x.3269. It checks more deeply if there already identical sounds queued for playing; at least in a specific case I found out that it drastically cuts out sound repetitions when the trigger cause wasn't there any more. However this couldn't yet be a solution covering all cases.
Maybe also on the side of the AI trains code something could be done to avoid too close trigger generation.
I am waiting for reactions.

I´ve had the problem of sound queuing, and delaying other sounds, often in manually controlled trains (IE, player-trains). When starting a heavy load, I usually put it into run 1 (or more, if necessary on grades) and use the loco brake to keep speed below 2 MPH until all slack is out (the coupler are under tension). Doing so, I move he loco brake a lot, but only for a few percent each time. Every move, though, add´s another engine brake sound to the queue, which then keeps playing for minutes, and prevents e.g. the throttle sound from being played. Doing multiple throttle changes while the queued brake sound are still playing leads to queuing of the throttle sound behind the brake sounds as well, and they are then played all in sequence (almost like a machine gun, 'tak-tak-tak-tak').

Will you above fix also (positively) influence this problem?

Cheers, Markus

[Csantucci]

markus_GE, on 30 September 2015 - 07:30 AM, said:

Will you above fix also (positively) influence this problem?

Cheers, Markus

That's the intention, but you should better try.
However if your .sms file has in the same stream a long sound (engine brake) together with other sounds (throttle), the .sms file is not well built.
Those sound should reside in different streams, so that they can be played at te same time.

[James Ross]

disc, on 28 September 2015 - 01:13 PM, said:

But how can i add a flag, that is not interfering with MSTS?

Generally speaking, MSTS ignores any blocks it doesn't understand, so we add a new block starting "ORTS" and that's fine (e.g. ORTSRejectNew ( 1 ) ).

disc, on 29 September 2015 - 05:56 AM, said:

So here is the patch for diesel/electric Variable3, and for electric Variable2. variable23fix.zip

BTW what should i do to get access to upload changes to SVN?

I'll get this process going, if you could PM me an email address to have your login details sent to.

[markus_GE]

Csantucci, on 30 September 2015 - 08:28 AM, said:

That's the intention, but you should better try.
However if your .sms file has in the same stream a long sound (engine brake) together with other sounds (throttle), the .sms file is not well built.
Those sound should reside in different streams, so that they can be played at te same time.

I understand that these are not very well-made SMS files. However, even some high-sound-quality and true-to-reality SMS files are built this way, and changing them all takes some time. Also, changing them does not cure the problem of engine brake sounds playing for minutes after you last touched them ;)

Cheers, Markus

[disc]

The biggest problem is with those sound files that are unnecessarily long. Developers should crop their sounds to short as possible. I also see a lot of MSTS/OR sounds with silence before and after the sound left. Silence is not needed, except from few exceptions, that should be cut off. Also for positioned 3D audio (everything which is not for 2D Cab), shouldn't be stereo (actually the most the sounds recorded with home camera/phone are not stereo at all, just two mono tracks).

[Eldorado.Railroad]

disc, on 30 September 2015 - 12:26 PM, said:

The biggest problem is with those sound files that are unnecessarily long. Developers should crop their sounds to short as possible. I also see a lot of MSTS/OR sounds with silence before and after the sound left. Silence is not needed, except from few exceptions, that should be cut off. Also for positioned 3D audio (everything which is not for 2D), shouldn't be stereo (actually the most the sounds recorded with home camera/phone are not stereo at all, just two mono tracks).

Ok? So just how long in seconds should those sound files be? Yes, there have been some sounds files that have a lead-in of silence, but this depends if they are being used as a one-shot or being looped. In my experience, there are often compromises in sound looping. Short loops might sounds ok....if there are no sonic events that make short sound loops sound awful. With longer samples you can often mask those events so they are not as annoying to listen to. The masking occurs because the "annoying" period is about 10 seconds long. That type of masking is not possible with short 1-2 second loops. Often mechanical things produce sounds that have a much longer period that do not fit in 1-2 seconds loops. As I recall Peter Gulyas spent a lot of time revising the sound code a few years back. I appreciate very much that you are willing to spend some time with this code. I also ask that you test....a lot...before making changes. As I remember the first code changes that Peter made resulted in a real mess (well at least for me) for many weeks. I was not too happy about those changes while they did not work! So please be careful. New features are great as long as they are a segment of code that can be opted out of (experimental), so the underlying sound code that "works" now..still works.

Thank you for interest and hard work with this item.