Menus don't freeze the player - I don't understand how button events work

[alexgleason]

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.



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:

Code ( lua) Select Expand

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,

Code ( lua) Select Expand

  -- 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!

[alexgleason]

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:

Code ( lua) Select Expand

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.

[Christopho]

You have this behavior because game:on_command_pressed() is called before the on_command_pressed() of game menus.

[alexgleason]

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?