inheritsBindFrom="SPECIAL_MOVE_BLOCK" - cannot pass the event along to game

Maintenance for the week of February 24:
• PC/Mac: No maintenance – February 24
thaellin
thaellin
✭✭
Hi,

For reasons, I am trying to make a plugin that shows that I am NOT BLOCKING even if I am holding the block button (simplified problem statement).

I have a bindings xml where I register
<Action name="BLOCKBUGGED_SPECIAL_MOVE_BLOCK" inheritsBindFrom="SPECIAL_MOVE_BLOCK" allowFallthrough="true">

In my lua code, I activate this input layer, and the custom bound up/down functions are correctly invoked. However, it prevents the block from being registered by the game.

I have tried with and without the allowFallthrough attribute. I have tried having my bound functions return nothing, true, and false - there is no change in behaviour.

Is there a way to make this work or is what I am trying to do simply not allowed by the plugin API?

Thanks,
-- Thaellin
  • thaellin
    thaellin
    ✭✭
    Thanks - that post has more detail than the wiki page... it also made me decide to pull the esoui source to review some things.

    I find I have 'improved' behaviour with a bindings file such as
    <Bindings>
        <Layer name="SI_MYADDON_LAYER">
    	  <Category name="MYADDON_KEYBINDINGS_CATEGORY">
    		 <Action name="MYADDON_SPECIAL_MOVE_BLOCK" inheritsBindFrom="SPECIAL_MOVE_BLOCK" allowFallthrough="true" rebindable="false">
    			<Up>return MyAddon_BlockInputUp()</Up>
    			<Down>return MyAddon_BlockInputDown()</Down>            
    		 </Action>		 
    	  </Category>
        </Layer>  
    </Bindings>
    

    The important part being the 'return' within the XML definition. If I use this bindings file, then I get my 'down' function invoked and block still works.

    .... HOWEVER.... this version does NOT invoke the MyAddon_BlockInputUp() function.

    If I return TRUE from BlockInputDown (or eliminate the 'return' from the XML), the game does not block, but I DO get my BlockInputUp call...

    I'm a bit baffled. I have also tried adding a second action layer which only listens for the 'up' but it does not seem to get called. There does not /appear/ to be any special code intended to be required for 'up' if we pass the input along instead of capturing it... but something is amiss here.

    Thoughts?
    -- Thaellin
  • Dack_Janiels
    Dack_Janiels
    ✭✭✭
    Did you check the source on how ZOS does it? Are you using the event manager, callback manger correctly to listen and fire events?
  • monkidb16_ESO
    monkidb16_ESO
    ✭✭✭
    If you are using the default (RMB) binding you can use
    EVENT_MANAGER:RegisterForEvent(addonName, EVENT_GLOBAL_MOUSE_DOWN, OnGlobalMouseDown)
    EVENT_MANAGER:RegisterForEvent(addonName, EVENT_GLOBAL_MOUSE_UP, OnGlobalMouseUp)
    
    and
    local function OnGlobalMouseDown(eventCode, button)
    	if button == 2 then
    		;RMB is Down
    	end
    end
    local function OnGlobalMouseUp(eventCode, button)
    	if button == 2 then
    		;RMB is Up
    	end
    end
    
    to see if you're holding that key.
  • thaellin
    thaellin
    ✭✭
    I did look in the ESOUI code, and it appears 'identical' (except that nothing ever inherits from SPECIAL_BLOCK_MOVE - I will see if I can intercept other keybinds later)

    Event manager and callback manager don't really play into it. I use an event for initialization and I have a calback fired every 1 second... but the code is not needed. You can reproduce this with just a bindings.xml (probably need to pushactionlayer)
    <Bindings>
        <Layer name="SI_MYADDON_LAYER">
    	  <Category name="MYADDON_KEYBINDINGS_CATEGORY">
    		 <Action name="MYADDON_SPECIAL_MOVE_BLOCK" inheritsBindFrom="SPECIAL_MOVE_BLOCK" allowFallthrough="true" rebindable="false">
    			<Up>
    			     d("Block key released.")
    			     return true
    			</Up>
    			<Down>
    			     d("Block key pressed")
    			     <!-- return true: block works, but 'Blockkey released' never displays -->
    			     <!-- return false: block is consumed, but 'Blockkey released' WILL display -->
    			     return true
    			</Down>            
    		 </Action>		 
    	  </Category>
        </Layer>  
    </Bindings>
    
  • Dack_Janiels
    Dack_Janiels
    ✭✭✭
    I wonder if it is a secure action that can’t be modified.
    Edited by Dack_Janiels on April 8, 2024 3:11AM
  • Baertram
    Baertram
    ✭✭✭✭✭
    The Wiki never says to be most up2date. We mention everywhere where possible that you have to look at the actual API documentation txt files and the ZOs code, as they show what curently is there, and how you can use it.

    If the Wiki is not describing it properly go ahead please and update it so whatever you found out and needs better description: Add it there. We all are maintaining a Wiki! Thank you very much.


    An addon example to capture the keybind (Bar Swap) can be found here:
    https://github.com/slippycheeze/SlippyCheezeESO/tree/main/BarSwapFailWarning

    If the same behavor does not work for the block key it maybe somehow secured or working differently.

    if button == 2 then
    Pease do not hardcode the values but use the proper ZOs defined constants for the buttons (and everywhere else in the game too):
    MOUSE_BUTTON_INDEX_RIGHT
  • thaellin
    thaellin
    ✭✭
    If you are using the default (RMB) binding you can use
    ...

    HOLEE CARP!

    That should do nicely for my purposes.Maybe not if I tried to make it general-purpose/redistributable, but I will definitely try that!
    Baertram wrote: »
    If the Wiki is not describing it properly go ahead please and update it so whatever you found out and needs better description: Add it there. We all are maintaining a Wiki! Thank you very much.


    An addon example to capture the keybind (Bar Swap) can be found here:
    https://github.com/slippycheeze/SlippyCheezeESO/tree/main/BarSwapFailWarning

    If I can figure out correct information to put in the wiki I will try to edit it. The pattern I am using looks the same as the one you've found from the barswapfail addong (thank you for digging that up!)



  • thaellin
    thaellin
    ✭✭
    (Minor update notes - tried listening on MOVE_FORWARD, had same behaviour where I got the down notification but not the up notification. Also tried using the insertactionlayer function as in the swapfail addon, but this did not change the behaviour... it seems there is something 'special' about listening for the 'up' with an inherited bind on certain actions... I wish I could figure out what that is...)

    I also set up the global mouse event listener, which does see both events and does not interfere.

    I should be able to put together what I need based on this...

    Thanks everyone for helping me out
  • Baertram
    Baertram
    ✭✭✭✭✭
    I guess those movement and combat related bindings are protected then so that you could not "insert any code to do botting or whatever".
    Maybe it's because the OnDown and OnUp actions are secure functions?

    For those EVENT_GLOBAL_MOUSE_UP:
    Make sure they unregister for your addon if not used, e.g. as you open any menu and show the UI.
    You can e.g. use HUD_UI_SCENE and HUD_SCENE to distinguish if your UI is currently closed and register the listener then, or unregister if the UI shows again.
    That way no unnecessary global mouse clicks are monitored and you all of sudden run any code allthough you are out of combat.
    Speaking of that I'd also combine it with the event for player combat state and only register it while in combat and unregister as you leave combat for example.

    Scene state change callbacks:
    https://wiki.esoui.com/Scene_Manager:_On_scene_change
    Edited by Baertram on April 8, 2024 3:49PM
  • Dack_Janiels
    Dack_Janiels
    ✭✭✭
    Have you looked at the code of Am I Blocking? https://www.esoui.com/downloads/info2920-AmIBlocking.html
    Maybe it could give you some ideas.
    Edited by Dack_Janiels on April 8, 2024 4:57PM
  • thaellin
    thaellin
    ✭✭
    Have you looked at the code of Am I Blocking? https://www.esoui.com/downloads/info2920-AmIBlocking.html
    Maybe it could give you some ideas.

    Thank you. I have - it is/was my starting point and will likely form the logical basis for the 'reasons' I am not blocking... and if I am holding block, not blocking, and do not have a reason, then I will notify myself loudly.... If I am /very/ lucky I will be able to figure out 'the reason' why my block sometimes fails (I have a bug post, though nothing from ZOS for ages... it is not a valid reason for block to have failed... https://forums.elderscrollsonline.com/en/discussion/650989/current-block-bug)
    Baertram wrote: »
    I guess those movement and combat related bindings are protected then so that you could not "insert any code to do botting or whatever".
    Maybe it's because the OnDown and OnUp actions are secure functions?

    I'd expect consistency, though... being able to listen to 'down' but not 'up' (unless I suppress down) is strange. Also, the fact that an independent action layer is not able to see the 'up' if I hooked the 'down' is bothersome... I still wonder if I am missing something. I may have to look more carefully at the ESOUI code, which is the only place I have found both up and down being registered.
    Baertram wrote: »
    For those EVENT_GLOBAL_MOUSE_UP:
    Make sure they unregister for your addon ...

    These are all great tips and I will definitely use them. thank you VERY much
    -- Thaellin

  • monkidb16_ESO
    monkidb16_ESO
    ✭✭✭
    Baertram wrote: »
    Pease do not hardcode the values but use the proper ZOs defined constants for the buttons (and everywhere else in the game too):
    MOUSE_BUTTON_INDEX_RIGHT


    Is there really any difference?

    If I hook up a debug like:
    local function OnGlobalMouseDown(eventCode, button)
    	d(button)
    end
    

    the game will even print 1 for LMB, 2 for RMB, and 3 for MMB in the chat.
  • Beilin_Balreis_Colcan
    Beilin_Balreis_Colcan
    ✭✭✭✭✭
    ✭✭✭


    Is there really any difference?

    If I hook up a debug like:
    local function OnGlobalMouseDown(eventCode, button)
    	d(button)
    end
    

    the game will even print 1 for LMB, 2 for RMB, and 3 for MMB in the chat.
    Using named constants instead of numeric literals is just good software development practice, you should avoid using literals where possible.
    PC(Steam) / EU / play from Melbourne, Australia / avg ping 390
  • Baertram
    Baertram
    ✭✭✭✭✭
    You can always use 2 over MOUSE_BUTTON_INDEX_RIGHT. Those particular constants for the mouse buttons most likely do not change but if you practice that way with all others like hardcoding 11 instead of ITEMTYPE_ADDITIVE you'll get pretty soon into trouble if ZOs changes the constant ITEMTYPE_ADDITIVE to e.g. 111.

    The constans were defined to be used, and ZOs uses them in their code, so do use them in addons too and you are safe.
    Else: No garanty that your addon will still work in a few weeks.

    Most constants wont change, but it always could happen. And we already had that happen in ZOs code, believe me.
    Edited by Baertram on April 8, 2024 10:02PM
Sign In or Register to comment.