[Bug] calling .Activate does not interrupt existing playback

[GHXX]

Describe the bug Calling .setAlarm() while passing a sound name that doesnt exist, makes the function return true

In which environment did the Bug appear? Singleplayer, fresh world.

To Reproduce Steps to reproduce the behavior:

1. Make a new world
2. use the /oc_sc command to plop down a opencomputers computer
3. place an alarm block next to the computer
4. turn on the pc
5. open the lua prompt in oc by typing "lua" and hitting enter 6.1. set the variable "a" to be an alarm (a = require("component").os_alarm) now run these commands: a.setAlarm("klaxon2") -- returns true a.activate() -- sound klaxon2 starts playing a.setAlarm("klaxon1") -- sound klaxon2 keeps playing, which is to be expected a.activate() -- sound klaxon2 keeps playing, even though sound klaxon1 should be playing

Expected behavior .activate() should stop existing playbacks

Screenshots / Code Snippet

Minecraft:

• Mod Version (e.g. OpenSecurity-MC1.12.2-1.0-48)
• Minecraft Version (e.g. Minecraft 1.12)
• Forge Version (e.g. Forge 14.23.5.2854) (some other mods are installed, but this should not be a compatibility issue i am assuming)

Additional context There are no outputs in the log file while this problem happens.

[CaitlynMainer]

This too is not a bug. The alarm does not track the play state as that is purely client sided, it just tells the client it should play a sound. Trying to synchronize the server TE with what the client TE is doing is not worth the effort.

[GHXX]

Sell, since it is unintended, gameplay degrading behaviour, it is techncially a bug. You wouldnt need to actually check if the sound is playing. To resolve it, you could simply keep track of whether or not a sound is currently being played, which means setting one bool to true when activate() is called, and setting it to false if deactivate() is being called. if the bool is true when activate8) is being called, then simply call deactivate() before executing the activate procedure. This should fix the situation without too much effort. No client side changes needed.

[Ocawesome101]

This is likely a side effect of how Minecraft's client<->server audio subsystem is set up. As such, there is not much this mod could do about it short of changing large portions of said subsystem.

But, there's no point in arguing about it since the issue is closed.

[Shuudoushi]

setting one bool to true when activate() is called, and setting it to false if deactivate() is being called. if the bool is true when activate8) is being called, then simply call deactivate() before executing the activate procedure.

Yes, and this is something that you could, and should, put in your own code when writing programs to take advantage of this block.

[ben-mkiv]

Sell, since it is unintended, gameplay degrading behaviour, it is techncially a bug. You wouldnt need to actually check if the sound is playing. To resolve it, you could simply keep track of whether or not a sound is currently being played, which means setting one bool to true when activate() is called, and setting it to false if deactivate() is being called. if the bool is true when activate8) is being called, then simply call deactivate() before executing the activate procedure. This should fix the situation without too much effort. No client side changes needed.

the server isn't aware of how long the sound is, so it's not as simple as setting a bool

[GHXX]

The sound is looping btw, so the sound length doesnt matter at all, @ben-mkiv

[ben-mkiv]

you can keep track of a bool in your lua script. If i implement something like that on the java side then only if its reliable, and as it could set a boolean to true, it would also do that if the sound doesn't even exist on the client, even tho no sound is playing.

as you noticed it's already confusing enough that setAlarm() returns true even if the sound doesn't exist