2023 - 02 Ruleset Update PowerManager Request

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.

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

Quote:

---

Originally Posted by 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

---

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.

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

Code:

---

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

---

in getPCPowerAction.

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

Quote:

---

Originally Posted by 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

---

Awesome, thanks!

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

Working like a charm so far, thanks again!

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.

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.

Thanks for your thoughts.

* For the radial menu, I'll need to look at creating some logic to handle >4 action types.

* For the registerDefaultPowerMenu, this is specifically meant to support the current implementation only. If something external resets the menu or decides it wants to handle read only differently, then it would need to make that read only determination before calling the function. I can move the list read only check outside the function, but it would still be in the onInit. Just trying to keep it encapsulated. What's the use case for something different?

* What's the case for a power not being in a windowlist? Technically, any power window can be put in a window list, even if it's hard-coded.

Regards,
JPG

I moved the read-only check into power_item.lua default script for now with the latest Test build (instead of in PowerActionManagerCore); and I have the radial menu situation on my list to resolve before final release.

Regards,
JPG

Quote:

---

Originally Posted by Moon Wizard

I moved the read-only check into power_item.lua default script for now with the latest Test build (instead of in PowerActionManagerCore); and I have the radial menu situation on my list to resolve before final release.

Regards,
JPG

---

Sounds great, thanks again!

Quote:

---

Originally Posted by Moon Wizard

What's the case for a power not being in a windowlist? Technically, any power window can be put in a window list, even if it's hard-coded.

---

With Kit'N'Kaboodle I have added an Actions tab to a bunch of windows (Feats, Spells, Traits, etc) that just has the single power associated with the ability. There are two functional uses for this, the first is that it makes it possible to define default powers for the ability in a module without relying on hardcoding for situations where the parser performs poorly (most MCDM products on the FG Store benefit from this). The second is that it can give the user a way to have a dedicated window for using a commonly used power without always having to find it on the Actions tab, which can be a little slow for high level characters.

Just spitballing, but wouldn't a filtering option with "favorites" be better for high-level characters.

For the actions in other records, I'm not sure we want to travel down that route; and are looking at a different solution to that issue long-term in the background. You'll probably still have to write your own "power_item" stuff, though hopefully you can still leverage the action pieces.

Regards,
JPG

With the release today, I added support for up to seven action types in the built-in radial menu handling (as that is the max that can fit in a radial menu sub-menu). If you need more than that, it will require an extension to do a lot more overwrites.

Regards,
JPG

Quote:

---

Originally Posted by Moon Wizard

With the release today, I added support for up to seven action types in the built-in radial menu handling (as that is the max that can fit in a radial menu sub-menu). If you need more than that, it will require an extension to do a lot more overwrites.

Regards,
JPG

---

Hmmm, well I suppose 5e extension devs will probably just need to assume that this utility won't be safe then, given that I can think of 5 additional action types off hand. Not really that big of a deal since that was the existing nature already, though it would have been nice to just let the ruleset handle it. As always, thanks for keeping us in the loop :)