Why Whistle on gaining Camera Focus for a train?

Can someone tell me why, when changing camera focus to another train, the whistle audio goes just because the train passed a whistle sign when it was not in focus and is now well beyond where the whistle should have been blown? If you passed TWO signs while the train was out of camera focus, you will get TWO whistles. It is annoying because logging railroads have (had) a lot of unprotected grade crossings and whistles were the standard warning for them in the deep woods. When I change focus to a train I have been away from for some time, it sounds off, even if stopped, parked or otherwise inactive.

It seems to be due to the lack of a sound radius in particular assets. I have one of my routes where you can hear every train hitting every crossing on the route because the bells lack a sound radius in the config.
cheers
Graeme

grazlash said:

It seems to be due to the lack of a sound radius in particular assets. I have one of my routes where you can hear every train hitting every crossing on the route because the bells lack a sound radius in the config.
cheers
Graeme

Click to expand...

My old TS2010 route did the some thing as yours. But in TRS19 it is more than just that. The software actually queues the audio for each whistle sign that the train passed when it was NOT on the camera, and plays all of the queued audio when the camera is finally put on that train. The audio does not play when the out of camera train passes it, instead it plays when the camera is finally put on that particular train.

On the surface, it would seem a simple matter, since the train in question must be known if the audio is being queued for it, to just check to see if the camera is on that train or near enough to be heard by the camera, and if not, to just cancel the audio occurrence instead of queueing it. But it is in the NV3 code somewhere, so I cannot get at it to fix it.

Robert704 said:

My old TS2010 route did the some thing as yours. But in TRS19 it is more than just that. The software actually queues the audio for each whistle sign that the train passed when it was NOT on the camera, and plays all of the queued audio when the camera is finally put on that train. The audio does not play when the out of camera train passes it, instead it plays when the camera is finally put on that particular train.

On the surface, it would seem a simple matter, since the train in question must be known if the audio is being queued for it, to just check to see if the camera is on that train or near enough to be heard by the camera, and if not, to just cancel the audio occurrence instead of queueing it. But it is in the NV3 code somewhere, so I cannot get at it to fix it.

Click to expand...

Ideally yes having this related to the camera position is a good idea, but unfortunately the sound radius is controlled within the asset its self.

http://online.ts2009.com/mediaWiki/index.php/"Soundscript"_container

The sound distance is the setting that needs adjusting along with the overall volume as well in some cases. There are a couple of sound assets that really got me looking into these parameters in detail. Among them is the dog barking, geese honking, and the child coughing. The coughing one is so loud that it's almost comical with the child coughing so loudly that it can be heard a mile or more away. If any child, or person for that matter coughed that loud, we'd find a lung on the side of the road somewhere!

The issue too is people create sound assets by cloning others. In some cases, the sounds are marked as ambient when they should be directional. Ambient sounds can be 3d and spread over an area as background noise such as bird chirping. The problem is people use an ambient sound asset as a base and use that config for a directional sound asset. This is why the dogs barking, or example sounds weird to put it mildly. Unfortunately, if I remember correctly, this asset can't be edited due to being built-in or payware.

JCitron said:

Ideally yes having this related to the camera position is a good idea, but unfortunately the sound radius is controlled within the asset its self. ...

Click to expand...

I fully understand what you are saying, but consider this: The trigger that starts the sound for a train's whistle (horn) is the whistle sign asset. BUT, the sound audio is associated with the traincar (loco = 1), and in that implementation does not need to be range specific if the train has camera focus. I agree that adding range for an engine without camera focus would be a significant effort. But in most cases, simply not playing the audio if the train did not have camera focus would be a more realistic option, and simple to implement, (a call to check camera focus and an if statement). The only downside would be when two trains were in close proximity and one sounded its whistle (horn), then the other one (provided it had camera focus) would not hear it. That minor loss would be much better than playing the delayed audio ten minutes later when the camera was finally placed on the train in question and the sound was still queued, like it is now.

Robert704 said:

But in most cases, simply not playing the audio if the train did not have camera focus would be a more realistic option, and simple to implement.

Click to expand...

Why compromise? If the sound is played at the correct time then there is no need to queue the whistle and it will not play later. If the sound distance is set correctly it will, or won't, be heard, at the right time, when the focus is on another loco, according to the sound distance. The problem is that it gets queued when it should occur at the time. Level crossing gates don't get queued - there seems to be no good reason for queueing sounds. It's a bug.

SailorDan said:

Why compromise? If the sound is played at the correct time then there is no need to queue the whistle and it will not play later. If the sound distance is set correctly it will, or won't, be heard, at the right time, when the focus is on another loco, according to the sound distance. The problem is that it gets queued when it should occur at the time. Level crossing gates don't get queued - there seems to be no good reason for queueing sounds. It's a bug.

Click to expand...

Exactly. The only reason I can see for any compromise is the effort required to add audible range to the whistle/horn audio. If that effort is not justified due to complexity, then I believe what I propose is an alternative -- not perfect, but better.