Tell UI Tweaks that your ability triggers overwatch. Either:

• If your ability unconditionally triggers overwatch (consumes an attack, or otherwise calls processReactions with the agent as an argument), then add the following to your abilitydef.
  triggersOverwatch = true,
• If your ability only triggers overwatch under certain conditions (example: in vanilla, using a console triggers overwatch unless the agent has wireless hacking), set it to a function with the following signature and return a truthy value if the ability would trigger overwatch with these arguments.
  triggersOverwatch = function(self, sim, abilityOwner, abilityUser)

Use a compatible tooltip implementation (most tooltips that resemble vanilla tooltips should work). At the moment, abilities using Combat-Panel-based tooltips (including the vanilla melee/shootSingle) are not supported and will be passed through as-is. Compatible implementations are any of:

• Define 'createToolTip' as per vanilla, and return a string.
  
• Define 'onTooltip' as per vanilla, and return a string.
  
• Define 'onTooltip' as per vanilla, and return a 'client_util.tooltip'
  • (constructed directly, or from calling 'abilityutil.onAbilityTooltip').
• Define 'onTooltip' as per vanilla, and return a 'abilityutil.hotkey_tooltip' or a subclass thereof.
  • Your subclass may freely modify other parts of the HUD (preview AP, highlight cells, etc), but must not modify the underlying 'self._tooltipWidget', because this will be drastically different between vanilla and UITR.
  • with UITR, such tooltips support ':addSection()', but if you make use of this, your mod won't work without UITR installed.
• Define 'acquireTargets' as per vanilla, and return a 'targets.throwTarget'.
  • In this case the warning is applied to the tooltip when the player is targeting a throw, after selecting the item.

UITR attempts to wrap the tooltips for all abilities except those with one of the following flags set in their ability def:

• Programs
  program = (anything not nil),
• Daemons
  standardDaemon = (anything not nil),
• Algorithms
  reverseDaemon = (anything not nil),
• UITR-specific override
  noUITR = true,

For pseudo-daemons (daemons that provide UI to a persistent effect, such as Royale Flush, Programs Extended Counter AI, etc), explicitly setting is sufficient for this, because 'false' is not 'nil'.

---

This section covers implementation details that may be relevant if you want to call UI functions outside of the normal code paths.


UITR doesn't modify ability defintions (other than assigning 'triggersOverwatch' flags to the vanilla abilities). The custom handling is injected onto the ability instances as part of 'simability.create'.

Any defined 'createToolTip' or 'onTooltip' functions are replaced with a custom 'onTooltip' that calls the defined tooltip function(s) and modifies the results. If both are defined, vanilla prefers 'createToolTip' in some parts of the UI and 'onTooltip'; UITR replicates that behavior. ('agent_panel.updateButtonFromAbilityTarget' passes additional target arguments compared to 'agent_panel.updateButtonFromAbility')

String tooltips are wrapped in a 'client_util.tooltip' subclass with an initial section that replicates the appearance of how the vanilla code would've processed your string into a 'mui_tooltip'.

Any defined 'acquireTargets' is wrapped. If it returns a 'targets.throwTarget' or subclass, UITR further wraps the targeter's 'generateTooltip'.

The targeter's 'generateTooltip' is expected to return a string. UITR's 'generateTooltip' wraps the vanilla string in our 'client_util.tooltip' subclass. Because the agent panel expects to further append to targeter tooltips, the subclass supports concatenation with strings. The following appends the additional text into the widget's body text (the original string).

In vanilla, 'abilityutil.hotkey_tooltip' is a subclass of 'mui_tooltip'. UITR replaces it with a subclass of our 'client_util.tooltip' subclass.

Notably 'mui_tooltip' renders a single element, whereas 'client_util.tooltip' instead contains a series of independent sections that are rendered in a column.

Normally modifications to base classes do not propagate to subclasses that were loaded before the base class was modified, unless the subclass calls the base class' functions from its own. The first time an instance of each subclass is initialized, UITR's 'abilityutil.hotkey_tooltip:init' inspects the current object's class and replaces any remaining functions inherited from the vanilla hotkey_tooltip class.


The vanilla 'client_util.tooltip' expects to receive a screen instance when initialized, but UITR needs to be able to initialize tooltips where the screen isn't available until ':activate'.

UITR defines subclasses 'abilityutil.delayed_tooltip' and 'abilityutil.delayed_tooltip_section' that defer most of the base class functionality until ':activate' is called. For example, 'delayed_tooltip_section:addLine' stores its arguments in a queue and won't add the new child until the tooltip is activated. If adding additional methods that create children with different skins to 'tooltip_section', it is likely that the same methods will need to be added to 'abilityutil.delayed_tooltip_section'.