ID:2412681
 
Resolved
The SOUND_UPDATE flag did not behave in a logical manner; if a sound was not playing it would be ignored unless it applied to all channels, and when a channel was specified but that channel was not playing, the sound would begin.

The new behavior is that SOUND_UPDATE always takes priority over other considerations, and when it is present the file value of the /sound datum is ignored. A new sound will not start playing if the specified channel is currently not in use.
BYOND Version:512.1456
Operating System:Windows 10 Home 64-bit
Web Browser:Firefox 63.0
Applies to:Dream Seeker
Status: Resolved (512.1459)

This issue has been resolved.
Descriptive Problem Summary:

Numbered Steps to Reproduce Problem:

Code Snippet (if applicable) to Reproduce Problem:
/client/verb/test_sound(F as sound)
var/sound/S = new()
S.file = F
S.channel = 100
S.wait = 0
S.repeat = 0
S.status = SOUND_UPDATE
S.volume = 100

usr << S


Expected Results:
Sound shouldn't play

Actual Results:
Sound play


In my case, I want make a volume slider applying to current playing sound on specific channel. It's possible by re-sending S (sound) with new params and SOUND_UPDATE flag, but if sound already ended we just start it again...
And there is no way to know playing something on channel or not.
Or maybe I'm missing something?

Also, documentation unclear about how SOUND_UPDATE should work with wait=1 queue
SOUND_UPDATE should not be used with a file, so this is why you're having a problem. Leave the file part alone, and you don't need to set any vars that already are at their defaults (e.g., wait, repeat, volume). I could make the logic in this area a little more robust, but basically that's the whole issue.

As for interaction with wait, it's basically the same deal: using the update flag and using wait=1 at the same time is nonsensical.
Lummox JR wrote:
SOUND_UPDATE should not be used with a file, so this is why you're having a problem.

I'm still don't understand how it should work. Without file it's just stop playing after update:

/client/verb/test_sound(F as sound)
var/sound/S = new()
S.file = F
S.channel = 100
S.volume = 100

usr << S

/client/verb/reduce_volume()
var/sound/S = new()
S.channel = 100
S.volume = 20
S.status = SOUND_UPDATE

usr << S
The problem here is that you are making a new sound object. You need to a reference to the original object and then update the variables on that.
As I understand there is no difference between the same/new sound obj if the file and the channel are same.
Anyway,
var/sound/testSound = new()
/client/verb/test_sound(F as sound)
testSound.file = F
testSound.channel = 100
testSound.volume = 100

usr << testSound

/client/verb/reduce_volume()
testSound.volume = 20
testSound.status = SOUND_UPDATE

usr << testSound

test_sound -> sound play; reduce_volume -> volume reduced, all ok.
But if the sound is over and I call reduce_volume again, the sound will start playing from the beginning. This is the problem.
Hrm. Looking at the code some more, I'm not sure the file does have to be null when using the update flag. It really ought to be, but it appears the logic is doing something very wrong and a null file + update is only interpreted as an update when it applies to all channels, not to a specific channel.

I'm gonna have to run some tests here to double check. Ideally this should be the behavior:

sound only: sound begins playing
sound + update: update is applied; sound is ignored
no sound only: sound stops playing
no sound + update: update is applied; lack of sound is ignored

If I'm reading the current logic right, this is the behavior:

sound only: sound begins playing
sound + update: update is applied; sound begins if not already playing
no sound only: sound stops playing
no sound + update (all channels): update is applied; lack of sound is ignored
no sound + update (specific channel): sound stops playing

So that's really way wrong.
Lummox JR resolved issue with message:
The SOUND_UPDATE flag did not behave in a logical manner; if a sound was not playing it would be ignored unless it applied to all channels, and when a channel was specified but that channel was not playing, the sound would begin.

The new behavior is that SOUND_UPDATE always takes priority over other considerations, and when it is present the file value of the /sound datum is ignored. A new sound will not start playing if the specified channel is currently not in use.