I have a user reporting that when he presses a button in the game it stays pressed and nothing happens. We have all reactions listening to an input with action.released set to true so it seems to me that action is never thrown.
Odd, I’ve never heard of anything like this before. So you obviously get action.pressed (since you visually change the state of the button) but no action.released? Hmm, curious indeed. Does it matter which in game button he interacts with? What’s supposed to happen when the button is pressed? Could something be crashing as a result of action.pressed?
Checked the code and we do play the sound before changing the gfx, so in case execution breaks if a “play_sound” message fails, that could be it. Otherwise the button state is updated before any “on click” logic is executed.
Hmm, ok, not sure I understand in which order stuff happens, but is it 1) sound 2) visual state 3) logic ?
I guess there’s a risk that sound fails if some kind of audio channel pool or something is exhausted. Updating visual state shouldn’t really crash once you’ve tested and verified that all states exist. Logic can very easily contain bugs, but since it’s last it’s not the culprit.
Maybe you should consider using pcall around the play sound logic (and possibly also the visual state change). Something like:
function on_input(self, action_id, action)
if button_pressed then
pcall(play_sound, "#button_click")
pcall(update_visual_state, action)
do_button_logic()
end
end
Yes, that is pretty much how it is done, but the logic is in another script that is called with a message so that shouldn’t cause any problems (in this script that is - it sure can cause problems )
That is also what I’m thinking with sound, since the sound is played with a message, would an error with sound really stop execution? Isn’t the sound played when the message queue is processed?