I noticed something weird today: my sword can be activated during a dialog box. It goes to the first frame of animation and then is frozen until the dialog box finishes.
(https://i.imgur.com/BNSksAe.png)
When I first opened the dialog box I checked "hero:get_state()" and it says "free". When I press the item button assigned to my sword, it says "sword activated". Keep in mind my sword is an item assigned to item_1 (using hero:start_attack() internally), so it's not surprising that I have strange behavior. But I did think it was strange the dialog box doesn't freeze my hero. I can fix this issue by calling hero:freeze() when the dialog box starts, and hero:unfreeze() when it finishes.
Okay, I understand that some menus (like a HUD) shouldn't freeze the player. But it raises a question: how exactly are button events handled? My dialog box has this:
function dialog_box:on_command_pressed(command)
-- "action", "attack", "up", and "down" are handled here. I'm using "item_1" and not pressing any other buttons.
...
-- Don't propagate the event to anything below the dialog box.
return true
end
It returns true, so it shouldn't propagate. The context of dialog box is "game", and "game:on_command_pressed" is where the hero swings her sword.
In main.lua,
-- I've simplified my code, but it shouldn't matter. This function shouldn't be called in the first place.
function game:on_command_pressed(command)
print("you've reached me") -- This prints in the console when I perform the action in the screenshot, confirming that this function is called
-- Makes the sword swing
local item = get_item_for_command(command)
item:on_command_pressed(command) -- this code calls hero:start_attack() internally
return true
end
Any ideas why the event is propagated to game:on_command_press?? Thank you!
Okay, freezing and unfreezing the player was a bad solution because the hero must be unfrozen in order to brandish a treasure. So what I did instead to work around this is simply add this to game:on_command_pressed:
function game:on_command_pressed(command)
-- Don't handle any of this stuff when a dialog box is open
if game:is_dialog_enabled() then
return false
end
...
end
I'm getting the feeling that a "dialog box" is not simply just a normal game menu. It must have some additional behavior.
You have this behavior because game:on_command_pressed() is called before the on_command_pressed() of game menus.
Quote from: Christopho on October 15, 2018, 10:32:35 PM
You have this behavior because game:on_command_pressed() is called before the on_command_pressed() of game menus.
Okay, so it is intended behavior! Thank you for replying.
I thought the game is "below" the menu, and therefore it wouldn't be called. So is game:on_command_pressed()
always called first no matter what when there's an active game?