ID:2400562

 Applies to: DM Language
 Status: Open Issue hasn't been assigned a status value.
a /client proc that get run when a sound is stopped/finished would be useful for finer control over sounds. Something like the following:

/client/SoundEnd(sound/ending_sound)


If an actual reference to the sound isn't viable a \ref to the original sound would be good too. The issue at the moment is we have no way of determining sound length, which would also be nice but there's already a feature request for this iirc which was denied. Instead of that a hook for the sound ending for the client seems a good alternative to many use cases.
 <-> Sep 21 2018, 12:25 pm Please yes, this would really make dealing with sounds in general not easier but actually doable without having to offload the job to javascript or something else. +1
 <-> Sep 21 2018, 12:53 pm or maybe a sound status that could tell when it ends, for example SOUND_ENDED
 <-> Sep 21 2018, 1:12 pm Sounds can be sent to multiple clients
 <-> Sep 25 2018, 2:50 am I think this feature is fundamental to handle sounds decently anyhow. Right now I want to make a sounds subsystem for SS13 to handle queueing,sending and updating sounds. This, in particular, is needed for updating sounds if the source location moves, so that the client always hears the sounds from the right direction, but I cannot do it anyhow without being able to detect when the sound stops playing for the client, to stop it being updated. I hope the special FMOD license byond has would allow for this to become a thing, because right now I believe sounds are pretty limited to how we can handle them.
 <-> Sep 25 2018, 12:26 pm I'll put this on the list for 513. It seems pretty doable and 513 is a good target for it.
 <-> Sep 25 2018, 12:57 pm Thank you!