2023 - 02 Ruleset Update PowerManager Request

[MeAndUnique]

There are a handful of extensions that add new types of actions for PC Powers and it would be greatly appreciated if there were an easier mechanism for including them. For example in 5E this requires overriding getActionButtonIcons, getActionText, and getActionTooltip (assuming PowerManager.performAction was already overridden before these updates). And then the entire set of action handlers must be set again via PowerActionManagerCore.registerActionHandlers. Ideally, it would be preferable to simply add in the information for the new action type, as can be done with the UI changes.

[Moon Wizard]

So, are you talking about the ability to just add a new action type? (i.e. PowerManager.addActionType)

Or are you talking about selectively overriding functions in PowerManager.registerActionHandlers?

Thanks,
JPG

[MeAndUnique]

So, are you talking about the ability to just add a new action type? (i.e. PowerManager.addActionType)

Or are you talking about selectively overriding functions in PowerManager.registerActionHandlers?

Thanks,
JPG

The core goal is the first option, being able to add a new action type and have it plug in to the system for things like tooltips, mini icons, display test, etc.

[MeAndUnique]

Also, a correlated request would be to use PowerManagerCore.getPowerActorNode more reliably throughout so that can be a single override to that function could add functionality rather than being spread out in multiple places such as manager_power.lua in 5E still having things such as

local rActor = ActorManager.resolveActor(DB.getChild(nodeAction, "....."));

in getPCPowerAction.

[Moon Wizard]

After thinking about this a bit, I think I might want to restructure this area to allow easier overrides for specific action types, as well as registering new action types. Let me tinker with it a bit.

Regards,
JPG

[MeAndUnique]

After thinking about this a bit, I think I might want to restructure this area to allow easier overrides for specific action types, as well as registering new action types. Let me tinker with it a bit.

Regards,
JPG

Awesome, thanks!

[Moon Wizard]

Ok, I pushed a new Test channel update to allow actions to be registered separately, as well as a way to override specific functions for any action.
I also added in your suggested changes on the getPowerActorNode, though I only found that one in 5E, and only a few others across the other rulesets.

Regards,
JPG

[MeAndUnique]

Working like a charm so far, thanks again!

[MeAndUnique]

Found an issue that could be a bit trickier: radial menu support for more than 5 types of actions. There are handful of extensions out there that support different actions types, though even narrowing it down to extensions that are associated with FG Store products this could become a concern. The Kingdoms and Warfare extension that comes with the product of the same name adds a new type of action to support the domain mechanics. And one of the recommended (though not required) free extensions for the Beastheart adds a new action type that supports the ferocity mechanic central to the class.

If it helps, my plan should this be beyond the scope of the upcoming release would be to have overflow action types go into a submenu on the 1 slot on the radial menu expanding the total count to 10. Though I hope this is possible to address from the ruleset, as that approach will very likely lead to conflicts among the other action-type extensions.

[MeAndUnique]

Also of note regarding PowerManagerCore.registerDefaultPowerMenu:

• If this function is to be a full handler for action menu items, it should likely reset them when read-only. Otherwise it would be better to leave the read-only handling to the caller entirely.
• There could be cases where the UI structure doesn't have the power window contained within a windowlist for the purposes of read-only detection. Either utilizing a read-only function parameter or having more fault-tolerant detection logic would be preferable.