-
Notifications
You must be signed in to change notification settings - Fork 69
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
Comments
This is definitely something we'd accept in the Highlander. |
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
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
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.
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 :) |
@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 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. |
Also see #750 for an attempt to rework this. |
Ok, thanks, I'll take that over. |
…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.
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
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
…Color' (X2CommunityCore#400) and 'OverrideAbilityIconColorImproved' (X2CommunityCore#749) events to prevent a hard hang when using moving melee.
…lityIconColor' (X2CommunityCore#400) and 'OverrideAbilityIconColorImproved' (X2CommunityCore#749) events to prevent a hard hang when using moving melee." This reverts commit bcc72b2.
…lityIconColor' (X2CommunityCore#400) and 'OverrideAbilityIconColorImproved' (X2CommunityCore#749) events to prevent a hard hang when using moving melee." This reverts commit bcc72b2.
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 anXComLWTuple
. 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.
The text was updated successfully, but these errors were encountered: