Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support dynamic colours for tactical HUD ability icons? #400

Closed
pledbrook opened this issue Jan 25, 2019 · 5 comments · Fixed by #957
Closed

Support dynamic colours for tactical HUD ability icons? #400

pledbrook opened this issue Jan 25, 2019 · 5 comments · Fixed by #957
Labels
needs-docs Needs documentation

Comments

@pledbrook
Copy link
Contributor

The LW2 highlander modifies UITacticalHUD_Ability.UpdateData() (if I remember correctly — I don't have access to the source right now) so that it handles ability colours of "Variable". When it encounters a colour with that value, it triggers an event with an XComLWTuple. This allows the mod to use different colours for the same ability depending on various factors.

I'm wondering whether it makes sense to add the same or a similar feature to X2WOTCCommunityHighlander, or whether this should be handled in a completely different way.

@robojumper
Copy link
Member

This is definitely something we'd accept in the Highlander.

pledbrook added a commit to long-war-2/X2WOTCCommunityHighlander that referenced this issue Jan 25, 2019
This change adds a copy of WOTC's `UITacticalHUD_Ability` class with slightly
modified code for rendering the colour. Specifically, the new code (based on
the old LW2 changes) fires one of two events that allow listeners to override
the ability colour using the provided XComLWTuple.

From a mod's perspective, it can now register listeners for the following
events:

 * 'OverrideObjectiveAbilityIconColor'

   Allows the listener to override the colour of an ability that is tied to a
   mission objective. The normal colour is orange.

   The event includes a 2-element `XComLWTuple` with an ID matching the event
   name.

   The first element of the tuple is a boolean for which `true` means the
   listener wants to override the ability colour.

   The second element of the tuple is a string representing the desired colour.
   See `UIUtlities_Colors` for examples of this string's format.

 * 'OverrideAbilityIconColor'

   Allows the listener to override the colour of any ability whose initial
   colour is the string "Variable".

   The event includes a single-element `XComLWTuple` containing the desired
   colour as a string
pledbrook added a commit to long-war-2/X2WOTCCommunityHighlander that referenced this issue Feb 3, 2019
This change adds a copy of WOTC's `UITacticalHUD_Ability` class with slightly
modified code for rendering the colour. Specifically, the new code (based on
the old LW2 changes) fires one of two events that allow listeners to override
the ability colour using the provided XComLWTuple.

From a mod's perspective, it can now register listeners for the following
events:

 * 'OverrideObjectiveAbilityIconColor'

   Allows the listener to override the colour of an ability that is tied to a
   mission objective. The normal colour is orange.

   The event includes a 2-element `XComLWTuple` with an ID matching the event
   name.

   The first element of the tuple is a boolean for which `true` means the
   listener wants to override the ability colour.

   The second element of the tuple is a string representing the desired colour.
   See `UIUtlities_Colors` for examples of this string's format.

 * 'OverrideAbilityIconColor'

   Allows the listener to override the colour of any ability whose initial
   colour is the string "Variable".

   The event includes a single-element `XComLWTuple` containing the desired
   colour as a string
pledbrook added a commit to long-war-2/X2WOTCCommunityHighlander that referenced this issue May 1, 2019
This change adds a copy of WOTC's `UITacticalHUD_Ability` class with slightly
modified code for rendering the colour. Specifically, the new code (based on
the old LW2 changes) fires an event that allow listeners to override the
ability colour using the provided XComLWTuple.

From a mod's perspective, it can now register listeners for the following
event:

 * 'OverrideAbilityIconColor'

   The event includes a single-element `XComLWTuple` of the form
   [ in bool IsObjective, out string Color]. The Color element has the
   default value for the corresponding ability's HUD icon. If you don't
   want to change it, leave the value as it is.

   The boolean lets you know whether the ability is associated with the
   current mission's objective. For example, Evac is an objective
   ability on Extract VIP missions.

   Lastly, the event source is the `XComGameState_Ability` instance for
   the icon that's being drawn.
Onidotmoe added a commit to Onidotmoe/X2WOTCCommunityHighlander that referenced this issue Jan 30, 2020
Onidotmoe added a commit to Onidotmoe/X2WOTCCommunityHighlander that referenced this issue Jan 31, 2020
@Iridar Iridar added the needs-docs Needs documentation label Jan 9, 2021
@Iridar
Copy link
Contributor

Iridar commented Jan 9, 2021

The PR that was supposed to close this issue has been merged to the live version of the Highlander. It remains open because it needs docs. Please add some :)

@Iridar
Copy link
Contributor

Iridar commented Jan 11, 2021

@pledbrook I wanted to make docs for this issue, but while I was testing it I noticed the event only ever triggers for abilities that
if (IsObjectiveAbility || AbilityTemplate.AbilityIconColor != "")

Can you please explain what is the reason for this restriction?

EDIT: I made some local changes to the Highlander to test if there would be any issue with triggering this event at all times, and it seemed to work perfectly fine. Triggering an event with that name only in very particular circumstances seems completely counter-intuitive.

@robojumper
Copy link
Member

Also see #750 for an attempt to rework this.

@Iridar
Copy link
Contributor

Iridar commented Jan 12, 2021

Also see #750 for an attempt to rework this.

Ok, thanks, I'll take that over.

Iridar pushed a commit to Iridar/X2WOTCCommunityHighlander that referenced this issue Jan 14, 2021
Iridar pushed a commit to Iridar/X2WOTCCommunityHighlander that referenced this issue Jan 14, 2021
Iridar pushed a commit to Iridar/X2WOTCCommunityHighlander that referenced this issue Jan 14, 2021
…ilities

Switched back to EnableMouseAutomaticColor as setting Colors directly would get overriden by default upon mouseover

Changed the structure of X2CommunityCore#400 & X2CommunityCore#749 Completely

Added Highlander Docs

Changed Documentation from inout to in on IsObjective

Make ability icon color override backwards compatible

Since the new event for overriding ability icon colors is fired for
every ability icon, not just objective abilities or abilities with a set
icon color, it may break existing listeners that assume that they are
only receiving abilities that match those criteria.

This change keeps the old event and introduces a new
'OverrideBothAbilityIconColors' event, which ensures maximum
compatibility.

I have also fixed the issue references in the HL-Docs lines: it doesn't
support multiple issue numbers per feature at the moment.
Iridar pushed a commit to Iridar/X2WOTCCommunityHighlander that referenced this issue Jan 14, 2021
Switched back to EnableMouseAutomaticColor as setting Colors directly would get overriden by default upon mouseover

Changed the structure of X2CommunityCore#400 & X2CommunityCore#749 Completely

Added Highlander Docs

Changed Documentation from inout to in on IsObjective

Make ability icon color override backwards compatible

Since the new event for overriding ability icon colors is fired for
every ability icon, not just objective abilities or abilities with a set
icon color, it may break existing listeners that assume that they are
only receiving abilities that match those criteria.

This change keeps the old event and introduces a new
'OverrideBothAbilityIconColors' event, which ensures maximum
compatibility.

I have also fixed the issue references in the HL-Docs lines: it doesn't
support multiple issue numbers per feature at the moment.

Implemented Issue X2CommunityCore#749
Iridar pushed a commit to Iridar/X2WOTCCommunityHighlander that referenced this issue May 24, 2021
Switched back to EnableMouseAutomaticColor as setting Colors directly would get overriden by default upon mouseover

Changed the structure of X2CommunityCore#400 & X2CommunityCore#749 Completely

Added Highlander Docs

Changed Documentation from inout to in on IsObjective

Make ability icon color override backwards compatible

Since the new event for overriding ability icon colors is fired for
every ability icon, not just objective abilities or abilities with a set
icon color, it may break existing listeners that assume that they are
only receiving abilities that match those criteria.

This change keeps the old event and introduces a new
'OverrideBothAbilityIconColors' event, which ensures maximum
compatibility.

I have also fixed the issue references in the HL-Docs lines: it doesn't
support multiple issue numbers per feature at the moment.

Implemented Issue X2CommunityCore#749
Iridar added a commit to Iridar/X2WOTCCommunityHighlander that referenced this issue Jul 4, 2021
…Color' (X2CommunityCore#400) and 'OverrideAbilityIconColorImproved' (X2CommunityCore#749) events to prevent a hard hang when using moving melee.
Iridar added a commit to Iridar/X2WOTCCommunityHighlander that referenced this issue Jul 7, 2021
…lityIconColor' (X2CommunityCore#400) and 'OverrideAbilityIconColorImproved' (X2CommunityCore#749) events to prevent a hard hang when using moving melee."

This reverts commit bcc72b2.
Iridar added a commit to Iridar/X2WOTCCommunityHighlander that referenced this issue Jul 9, 2021
…lityIconColor' (X2CommunityCore#400) and 'OverrideAbilityIconColorImproved' (X2CommunityCore#749) events to prevent a hard hang when using moving melee."

This reverts commit bcc72b2.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-docs Needs documentation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants