ToME: the Tales of Maj'Eyal

"Resting talents" are talents that include waiting (i the example discovered, Dig, but there are also some more like Refit Golem.)
They can cause problems because they do not properly clean up stuff like getTarget repacements, which can doo odd stuff for other talents being either auto-used or otherwise used during a supposed rest.
Log of discovery on IRC:

06:02 ElectronicRU ok so I'm not exactly sure what happened
06:02 ElectronicRU but the picture is as follows
06:02 Xan Has this error with getTarget ever turned up before?
06:02 ElectronicRU Dig gets used with force_target
06:02 ElectronicRU the getTarget is replaced, Dig talent is called
06:02 ElectronicRU due to how Dig works, it forces the coroutine out
06:02 ElectronicRU getTarget never gets replaced back
06:03 Xan Why is force_target ever set to self anyway?
06:03 ElectronicRU well, because your addon does so
06:03 Xan That's in the default Player.lua as well.
06:03 ElectronicRU because vanilla does so for talents to use when no enemies are in sight
06:04 ElectronicRU it makes sense for Healing Touch, I guess
06:04 ElectronicRU that's not the issue, the issue is lack of proper recovery
06:04 Xan Oh, I see.
06:04 Xan When whoever made the addon added more conditions, they didn't change how useTalent was called for those extra cases.
06:04 ElectronicRU so the solution is to move stub assignment and cancellation out of the coroutine
06:05 Xan But even so, calling useTalent like that really shouldn't break the game.
06:05 ElectronicRU because to have them hinge on an assumption that no one ever uses forceTarget with something that puts a rest is, well, fragiles
06:05 ElectronicRU yep, exactly

The solution is to move stub assignment out of coroutine to not have it relying on it not calling any talents during the rest, and to do away with stubs immediately.

I'm pretty sure I stumbled across this bug today, but instead triggered it by binding the 'Dig' talent to a mouse click. (I was trying to find an easier way than alternating a hotkey and bumping a direction to clear out a map that was almost nothing but trees.) Now whenever I use a targeted ability one of two things happens:

1. If 'Dig' is still bound to the same mouse click then the hotkeyed ability always targets the last square in which the last creature to be targeted by the bound 'Dig' mouse click. This means that melee attacks will attack that square even from across the map, and beams and ranged attacks will always point in the direction of that square. If I stand on the square myself all attacks will target me instead. Non-targeted abilities work just fine such as self-only abilities or ones that are always centered on you.

2. If 'Dig' is unbound from a mouse-click either by using 'unbind' or binding something else to it then a LUA error pops up every time a hotkey is used to trigger a targeted ability. Something similar to this, but with slightly different files depending on which ability was used and how it was triggered (e.g. keyboard or mouse-click) I can sort of work around it by using the mouse and keeping 'Dig' bound to a left mouse click which allows changing the target by clicking on a melee range hostile target before using another hot-keyed ability on it. And for ranged targets using a right-click to bring up a menu of abilities works in most cases. But it's not perfect because it can't be set at range and not all ranged abilities can be used from the right-click menu.