Inconsistency in Hotkey handlers

[Ikael]

Initially I noticed this while developing Savage Worlds, but I was able to reproduce this in CoreRPG as well with simple sampler code: Interface.onHotkeyActivated handler does not seem to be consistent. It's performed but if I have modified draginfo anyhow it might or might be applied. This is like a race condition in FG launch, on some FG launchs/reloads draginfo modifications always apply/work, on other launches they does not work at all.

See the attached sample code to duplicate the issue. Use following steps:

Create new campaign using CoreRPG ruleset and enable this extension
Prepare any of your hotkeys by dropping single die into it
Activate the hotkey by clicking it (don't drag). You might see two things happening:

single dice is rolled (the one you defined in that hotkey slot)
multiple dices rolling (d100,d20,d10,d8,d6,d4)


Continue activating the hotkey several times, you should see the very same thing happening from those two all the time
Reload the ruleset and do activation steps again, at some point reload/activation cycle you should be seeing the other thing happening


Is this an issue within FG engine? -- Secondly why some parts of the draginfo cannot be affected, such as description? -- Thirdly why there is not API support for hotkey drag-activation?

In Savage Worlds ruleset you can prepare your hotkeys from traits, but at some point you might boost those traits and this makes the usage of the hotkey useless. See the original feedback comment about it: https://savagefgii.idea.informer.com/proj/?ia=26095 . In the Savage Worlds 4.2 ruleset all trait roll/draginfo are build when they are activated even in hotkeys, but this inconsistency (and lack of drag-activation-api) makes the new feature luck-based useless in hotkeys. Another usefulness of this dice/draginfo building on the run if that you don't need to update your hotkeys all the time when you upgrade your traits.

[Nickademus]

I have also seen an issue with the hotkey code (both for myself and some players), where when you drag and drop a die roll it grabs the hotkey slot entry to the right (~80%) or left (~20%). It is only for dragging, never for clicking the button or hitting the Fkey. Might be an extension problem, but I don't think I'm using the same extensions as my GMs. And nothing I use affects the hotkeys. It seems the variable accessing the hotkey array is getting a random +/-1.

Sounds like the hotkey code could use a rework (though it probably already is for the Unity build).

[Moon Wizard]

This is caused by the fact that Lua dictionaries are not guaranteed to return entries in the same order when iterating over all entries. FG stores all of the registered onHotkeyActivation handlers in a Lua dictionary assigned to the Interface package object. When a hot key is pressed, all of the activation handlers are called, regardless of return values from a particular handler. In this case, your example is modifying the draginfo object, and the ActionsManager script is making the roll. The order of these 2 handlers is not guaranteed; thus sometimes you see the original roll and sometimes the roll modified by the extension.

Also, the expected return value for onHotkeyActivation is either true or false/nil. See the examples in CoreRPG. Your extension is returning the draginfo object. It doesn't really make a difference in this case.

My suggestion (naively, given that I do not know exactly how your code works) is to adjust the handler for the action type handler registered with ActionsManager global CoreRPG script to deal with the scenario.

In a longer term scenario, I'm thinking that it might be good to capture the drop in an onHotkeyDrop handler, change the drop object type to a new reference specific to the action originating from that PC/NPC, and then create an onHotkeyActivation that decodes that action into a roll with all the relevant effects. It's a fairly large undertaking to handle all roll types across all CoreRPG rulesets, which is why I haven't tackled this yet.

Regards,
JPG

[Ikael]

Indeed this is the issue and I can reproduce is with more details now. Basically SavageWorlds and CoreRPG's Interface.onHotkeyActivated functions werecompeating with each other and whoever gets to play first will determine if SavageWorlds features work or not (in case SW handler is done first it works fine). I updated code slightly and altered dragtype slightly to avoid CoreRPG from applying any action to it. It seems to work now, thanks alot!



This is caused by the fact that Lua dictionaries are not guaranteed to return entries in the same order when iterating over all entries. FG stores all of the registered onHotkeyActivation handlers in a Lua dictionary assigned to the Interface package object. When a hot key is pressed, all of the activation handlers are called, regardless of return values from a particular handler. In this case, your example is modifying the draginfo object, and the ActionsManager script is making the roll. The order of these 2 handlers is not guaranteed; thus sometimes you see the original roll and sometimes the roll modified by the extension.

Also, the expected return value for onHotkeyActivation is either true or false/nil. See the examples in CoreRPG. Your extension is returning the draginfo object. It doesn't really make a difference in this case.

My suggestion (naively, given that I do not know exactly how your code works) is to adjust the handler for the action type handler registered with ActionsManager global CoreRPG script to deal with the scenario.

In a longer term scenario, I'm thinking that it might be good to capture the drop in an onHotkeyDrop handler, change the drop object type to a new reference specific to the action originating from that PC/NPC, and then create an onHotkeyActivation that decodes that action into a roll with all the relevant effects. It's a fairly large undertaking to handle all roll types across all CoreRPG rulesets, which is why I haven't tackled this yet.

Regards,
JPG