Author Topic: Menus don't freeze the player - I don't understand how button events work  (Read 196 times)

alexgleason

  • Jr. Member
  • **
  • Posts: 85
  • Vegan on a Desert Island
    • View Profile
    • Vegan on a Desert Island
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
  1. function dialog_box:on_command_pressed(command)
  2.   -- "action", "attack", "up", and "down" are handled here. I'm using "item_1" and not pressing any other buttons.
  3.   ...
  4.  
  5.   -- Don't propagate the event to anything below the dialog box.
  6.   return true
  7. 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
  1.   -- I've simplified my code, but it shouldn't matter. This function shouldn't be called in the first place.
  2.  
  3. function game:on_command_pressed(command)
  4.  
  5.   print("you've reached me") -- This prints in the console when I perform the action in the screenshot, confirming that this function is called
  6.  
  7.   -- Makes the sword swing
  8.   local item = get_item_for_command(command)
  9.   item:on_command_pressed(command) -- this code calls hero:start_attack() internally
  10.  
  11.   return true
  12. end

Any ideas why the event is propagated to game:on_command_press?? Thank you!
« Last Edit: October 15, 2018, 08:20:02 pm by alexgleason »
RIP Aaron Swartz

alexgleason

  • Jr. Member
  • **
  • Posts: 85
  • Vegan on a Desert Island
    • View Profile
    • Vegan on a Desert Island
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
  1. function game:on_command_pressed(command)
  2.   -- Don't handle any of this stuff when a dialog box is open
  3.   if game:is_dialog_enabled() then
  4.     return false
  5.   end
  6.   ...
  7. end

I'm getting the feeling that a "dialog box" is not simply just a normal game menu. It must have some additional behavior.
RIP Aaron Swartz

Christopho

  • Administrator
  • Hero Member
  • *****
  • Posts: 1146
    • View Profile
You have this behavior because game:on_command_pressed() is called before the on_command_pressed() of game menus.

alexgleason

  • Jr. Member
  • **
  • Posts: 85
  • Vegan on a Desert Island
    • View Profile
    • Vegan on a Desert Island
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?
RIP Aaron Swartz