[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: 311

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