The first sound is now permanently playing at the position it was playing at. It’s unremovable, and if Looped is true, it plays forever. Stop() only stops Song2. Moving the part only affects the position of Song2. Song1 will keep playing at the position it was at when the SoundId was changed.
Workaround: Make sure to Stop() before changing SoundId
I’m not so sure this is a ‘real’ bug. All other game engines do exactly the same thing if I’m not mistaken. We give ROBLOX the command to play a sound from file to the client. The fact that we don’t give the command to either pause or stop the song, is our fault isn’t it ?
I don’t think you understand. The two songs will overlap. The first song is no longer an object, cannot be stopped, cannot be removed, it just plays forever.
That is definitely a bug. Download the repro file and tell me that is normal behavior… Set the sound to .Looped as well.
Velibor understood and is saying it’s a quirk in many game engines that it’s the game maker’s responsibility to stop() before changing the ID.
I think this thread would belong equally in either bug reports or feature requests (of course, not both at once.) I see no reason why anyone would rely on this quirky behaviour. Makes it easier to quickly switch to another sound if the sound engine stop()ed it automatically on sound ID change.
Either way, it shouldn’t behave this way. I mean, the fact that the sound can’t be stopped after you do this doesn’t make sense. Since ROBLOX is object based, shouldn’t the sound still be associated to the object even if you change IDs? It doesn’t make sense to just eject the sound and disassociate it from the object just because the ID was changed.