"One shot wait/rewound" sound flags don't seem effective

[Joey79100]

• "One shot wait" is meant to prevent a sound from being played more than once at the same time.
• "One shot rewound" is meant to stop other occurrences of a sound when a new one starts.

For example, my TRNG level has a room with many wood beams Lara can jump on. On almost every one of them, I put a sound source with a chance of 1 so it plays a creaky sound occasionally. CH01 was still making the sound play way too much (ie. non stop), because of how many sound sources I have for this sound. I fixed this by using the "One shot wait" mode. This way, only 1 at a random location in the room can ever be heard at a time.

In TEN, these flags don't seem to work as intended: each sound source plays like if you put "Normal" mode.

tomb4 (using "One shot wait"): https://youtu.be/BTpQ-JIzDzs

TombEngine (both flags do the same thing): https://youtu.be/HNfuik4joSs

[Lwmte]

Have you used a trick with lengthening sound sample with silence?

[Joey79100]

I've made a test with the "One shot wait" mode and recorded the results. For context, in this test, while Lara is on the blue squares:

• Pressing Action (brown flash/text) will play AOD_TEST_RIGHT near the burning FLAME_EMITTER_2
• Pressing Action+Walk (green flash/text) will play AOD_TEST_RIGHT at Lara's current position

https://youtu.be/IYELVoluGS8

When the sound is "emitted several times" from more or less the same position, it indeed will not play again until the current instance has finished. This is correct.

When the sound is emitted again, but from a different position (distance > 1 square), the sound will start again, even if the 1st instance has not finished playing. This is incorrect.

[Lwmte]

May I ask - in what circumstances you have an object travel whole block at the timespan of 1 frame?

[Lwmte]

I will sum up what I wrote on Discord so information is not lost.

With the help of @Trxyebeep, we now see that originals can't handle two or more same looped/wait sound IDs playing in close proximity. Original engines will only play closest (loudest) one.

However, a trivial case is when you have two or more same sound sources in close proximity - e.g. two waterfalls, several blowing winds, several enemies shooting uzis, etc etc. In that case, original engine will only play closest one, which will inevitably cause sound bugs in tense gameplay scenarios with a lot of sounds emitted. Do we want to reproduce this faulty behaviour in TEN, or we want more consistent and flexible approach?

[Joey79100]

My last video was a pure test, just to show the difference TEN has compared to the classics.

My actual use case was the one in the original video: multiple sound sources for the same "sound" (wood cracks, that are placed at each beam), but I only want 1 to play at a time because otherwise it quickly gets overwhelming, even with a very low chance. I could also use an ever lower chance than CH01 (if TEN supports decimal values, which i have honestly not tested) in my case.

The thing is i don't think it's a faulty behavior, the name "one shot wait" does imply that the sound will not play again if it's already playing. And in case of random environmental sounds (ie. non looping ones, for example wood cracks, wind bursts, birds chirping, or even a random whisper in some horror level, or voices), I think it makes sense. The thing is this 1 square limit, in this case, makes that mode completely redundant: you would just use the normal play mode if you didn't mind the same sound playing more than once at the same time.

For looping sounds, I definitely agree, we should keep the ability to have the same sound playing multiple times. I'm using several looping wind sound sources in more or less close distance, and even when it is is the same sound it plays in "stereo" (the instances are not synced), which is a huge atmosphere booster. Same with river sounds.