Not a bug
BYOND Version:512
Operating System:Windows 10 Pro 64-bit
Web Browser:Chrome 71.0.3578.98
Applies to:Dream Seeker
Status: Not a bug

This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Descriptive Problem Summary: Before 512.1459, sound systems that rely upon the SOUND_UPDATE flag to continually update and repeatedly play long sounds or play looping sounds worked without issue, but now, the client plays no sound at all when the flag is present, regardless if you have file defined for the sound datum or not.

Numbered Steps to Reproduce Problem: Use the code snippet below and place the object defined within it on a simple map. Be sure to feed it your own sounds. On 512.1458 and earlier, the object will play the sound while continually updating its properties. However, more importantly, the object will also play the sound from the beginning for players that connect while the sound is being updated and looped on the client side, all without having to make any special accommodations for that behavior. On 512.1459 and later, the same object will do literally nothing, as the SOUND_UPDATE flag prevents it from playing any sound at all as of 512.1459, even though file is clearly defined.

Code Snippet (if applicable) to Reproduce Problem:
name = "Jukebox"
var/S = 'sounds/juketune.ogg'

. = ..()

spawn while(1)
var/sound/playing = sound(S, 1, channel = 5)
playing.status = SOUND_UPDATE
playing.y = 1
for(var/mob/M in world)
playing.x = x - M.x
playing.z = y - M.y
M << playing

Expected Results: For the sound in the loop to start playing if there's no sound already playing on the channel, even for freshly connected clients, exactly how the SOUND_UPDATE behavior has been for years now.

Actual Results: The code snippet plays literally nothing on clients running 512.1459 or greater.

Does the problem occur: It occurs for every client running 512.1459 or greater.

When does the problem NOT occur? For clients running 512.1458 or older.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? Every single version that has the SOUND_UPDATE flag prior to 512.1459 features this behavior.

Workarounds: The only workaround I can think of is to axe the repeat flag and just play the sound without the SOUND_UPDATE flag for every client that meets the conditions to hear the sound, but this comes at the loss of seamlessness for the audio, has the issue of freshly connected clients being unable to hear the audio until the sound completes a loop, and can result in the audio cutting itself off since the SOUND_UPDATE flag is no longer capable of playing sounds.

Kaiochao resolved issue (Not a bug)
This is indeed a bug. The old behavior of playing audio if the channel has no audio already playing has been present for years now. The bug in that thread has to do with SOUND_UPDATE muting the channel if file is null, which was fixed but in a way that completely breaks the old behavior.
The old behavior was wrong, though. It should never have been done that way. The new behavior is consistent.

Login to reply.