ToME: the Tales of Maj'Eyal

An idea that came from several conversations with Gaswafers on the Discord, regarding talents that behave more like item actives. Item with actives (aside from trinkets) have "power" that gets consumed in some integer amount to do their thing. Power recovers at a rate of one per global turn, and works as a sort of reverse-cooldown, ticking up instead of down. This is a framework that roughly duplicates that behavior.

• A talent with charges has charge_use and charge_max fields in its talent definition. These may be functions, in the usual function(self, t) syntax. A talent with charge_use defined will always be interpreted as a charge talent, and will not "go on cooldown".

  Code: Select all

  newTalent{
  	name = "Example Charge",
  	type = {"technique/charge-talents", 3},
  	require = techs_strdex_req1,
  	points = 5,
  	mode = "activated",
  	stamina = 10,
  	charge_use = 5,
  	charge_max = function(self, t) return self:getTalentLevelRaw(t)*5 end,
  	target = function(self, t) return {type="bolt", range=10} end,
  	action = function(self, t)
  		--SNIP
  	end,
  	info = function(self, t) return ([[Rush toward a target spot with incredible speed.]]) end,
  }

• Charge-use behavior should work fine for actives, sustains, and passives, although I can't comment on its effectiveness with sustains. It also hasn't been bugtested with passives or sustains.
• Charge talents don't have any internal cooldowns. Attempting to give them a cooldown won't do anything at the moment. This may be a neat thing to include eventually, I suppose.
• Talents and effects that put charge talents "on cooldown" instead expend a number of charges equal to their charge cost.
• Talents and effects that prevent talents from cooling down will also prevent charges from being gained.
• Talents and effects that reduce a talent's cooldown instead reduce a talent's charge cost, with the same rounding behavior. Since charge costs are probably smaller than cooldowns, this may have unintended balance consequences.

Also included is a test class that learns the thrillingly named "Example Charge" talent, which serves as a rudimentary example of how they work in practice. It also charges in the literal sense, because it's just a modified Rush.

This addon superloads the following functions, from the following files.
engine/HotkeysIconDisplay.lua

• display() (Destructively)

mod/class/Actor.lua

• init(t)
• learnTalent(t_id, force, nb)
• unlearnTalent(t_id, nb)
• startTalentCooldown(t, v)
• useTalent(id, who, force_level, ignore_cd, force_target, silent, no_confirm)
• getTalentCooldown(t, base)
• alterTalentCoolingdown(t, v)
• isTalentCoolingDown(t)
• cooldownTalents()
• getTalentFullDescription(t, addlevel, config, fake_mastery)

mod/class/Player.lua

• restCheck()

(Destructively) implies that the original function is not called. This means that it may break compatibility with other addons that require those functions. If anyone knows any fancy workarounds, please let me know.

This is mostly intended as a framework for other addons. If you're not developing your own addons, don't expect to get a lot of excitement from installing and activating this addon.

Download Link on te4.org

Version v0.1.1

• Fixed a display bug when a talent was both unable to be used (due to resources, gear, etc.) and not at max charges.
• Talents that are unable to be used will continue to display their charge fraction, using the gray frame/background of "disabled" talents, and the growing wedge of cooling down talents. This way you can still track their available charges.
• Fixed a thrown Lua error on talent level increasing when the charge_max field is a function.
• Fixed charge level not properly capping if charge_max decreases as part of talents being unlearned. Normally gets caught on the next tick of cooldowns, so not really a functional change.
• Added a check to getTalentFullDescription() so it should play nice with other addons that may superload that function.
• Added a check to Player:restCheck() so resting will properly respect charge talents. Current behavior is to go until maximum charge. If you use dracos12's Improved Auto-explore and Rest, it totally circumvents the default restCheck, so you won't see this behavior.
• Tested compatibility with Minimalist HUD and other interface styles. No issues found.

Haven't looked at the code and this might not be possible for that particular function, but for your "destructive" superload, see if you can code it so that it only uses your modified code when it is applying to a Charge Talent.
That's what I try to do when I have to do something that might break. It means that if it does break with someone else's stuff, it only breaks on my stuff specifically.

HousePet wrote:Haven't looked at the code and this might not be possible for that particular function, but for your "destructive" superload, see if you can code it so that it only uses your modified code when it is applying to a Charge Talent.
That's what I try to do when I have to do something that might break. It means that if it does break with someone else's stuff, it only breaks on my stuff specifically.

I dunno if there's a proper term for what I was attempting to convey. Settled on destructive as a decent approximation I guess.

For the HotkeysIconDisplay.lua case, as far as I understood it, all the icons are drawn in one pass, iterating over the things on the hotkey bar. And since the actual checking of the talents is inside that iteration, its hard to encapsulate the behavior where I wanted it to be. I suppose in theory you could draw everything "normally" (calling the base function) and then do a second pass only drawing charge talents over their normal spots. But people don't typically muck with the display code, so it should be safe to have this be a little hacky.

For getTalentFullDescription() I realized in hindsight that there's a better way to do it and so that issue is actually fixed.

Version v0.1.1

• Fixed a display bug when a talent was both unable to be used (due to resources, gear, etc.) and not at max charges.
• Talents that are unable to be used will continue to display their charge fraction, using the gray frame/background of "disabled" talents, and the growing wedge of cooling down talents. This way you can still track their available charges.
• Fixed a thrown Lua error on talent level increasing when the charge_max field is a function.
• Fixed charge level not properly capping if charge_max decreases as part of talents being unlearned. Normally gets caught on the next tick of cooldowns, so not really a functional change.
• Added a check to getTalentFullDescription() so it should play nice with other addons that may superload that function.
• Added a check to Player:restCheck() so resting will properly respect charge talents. Current behavior is to go until maximum charge.
• Tested compatibility with Minimalist HUD and other interface styles. No issues found.