Rclick melee delegate 1138

[FearTheBunnies]

Uses a delegate based approach to expanding the functionality versus actually forcing a revised sorting algorithm. Will allow other mods to hook into the right-click melee determination logic and provide prioritization dynamically for which melee ability should be used. Closes #1138

[Iridar]

Either way this would be a useful functionality to have, so I hope you can address the requested changes so this can be added to CHL.

[FearTheBunnies]

Simplified the process significantly by reducing a lot of the clunkiness and now passes UnitState to the delegate allowing for the end consumer to interact with it and the ruleset cache as much as the desire. Should be much cleaner now.

[Iridar]

Simplified the process significantly by reducing a lot of the clunkiness and now passes UnitState to the delegate allowing for the end consumer to interact with it and the ruleset cache as much as the desire. Should be much cleaner now.

It seems alright superficially, I haven't gone through it letter by letter or ran any tests yet. I still think the system would benefit from being able to override which ability to use depending on the target.

This would just mean copying the code from the X2AbilityTrigger_EndOfMove to:

1) XComTacticalInput - here you would have to retrieve the target State Object from History using PathingPawn.LastTargetObject.GetReference().ObjectID.

2) XComPathingPawn - you get XComGameState_BaseObject TargetObject right in the function arguments.

The X2AbilityTrigger_EndOfMove should still call the override though, just without the target state. You can make the target state object an optional argument for the delegate, or just explicitly pass none there.

This is just so that the override can remain at least somewhat functional in case mod-added code also runs X2AbilityTrigger_EndOfMove::GetAvailableEndOfMoveAbilityForUnit().

[FearTheBunnies]

Updated to include the target object now. Still tried to maintain a minimal footprint in the Highlander itself.

[Iridar]

I'm uncomfortable with how this has been handled. GetAvailableEndOfMoveAbilityForUnitWithTarget() doesn't exist in base game code, but it's not immediately obvious.

I also have BC concerns.

Here's what I request:

1. Get rid of GetAvailableEndOfMoveAbilityForUnitWithTarget(), keep the original code inside GetAvailableEndOfMoveAbilityForUnit().
2. Add the CHHelpersObj.TriggerPrioritizeRightClickMelee() above the original code, just give it a none target object.
3. Also call CHHelpersObj.TriggerPrioritizeRightClickMelee() from the two places where you called GetAvailableEndOfMoveAbilityForUnitWithTarget() from, but this time with the target object.

Let's do it this way, because then we do not have to maintain an additional function and worry about having to protect internal API or maintain BC.

It's not as pretty and results in more lines of code, but I believe it is the better way.

[FearTheBunnies]

I tweaked the implementation a little by finally realizing there are actually two things at play here. First thing is allowing a mod to fix the "bug" of the right-click priority choosing abilities that are non-intuitive. The second thing was enhancing the selection ability to allow for the target to be provided increasing the flexibility of the choice.

[Iridar]

Refactored the PR. Footnotes:

• Moved the code from the original GetAvailableEndOfMoveAbilityForUnit() into a new function GetAvailableEndOfMoveAbilityForUnit_Original(). Replaced for() cycle with foreach() for the sake of optimization.
• GetAvailableEndOfMoveAbilityForUnit_CH() triggers the override, then defers to GetAvailableEndOfMoveAbilityForUnit_Original() if no override is found.
• GetAvailableEndOfMoveAbilityForUnit() does the same, but does not pass the target object to the override.
• Marked TargetObject as an optional to make it clear it's not guaranteed.
• Slapped private and final where appropriate.
• Updated docs and comments.

[Tedster59]

Discord formatting?

[Iridar]

HL-Docs can render UC code in a similar fashion, example: this -> renders like this

[Iridar]

Moved the override trigger after the default logic so that the override could allow for a more informed decision without directly replicating base game logic.

[Iridar]

This is tested and ready to go, just waiting for @FearTheBunnies to squash the commit with my adjustments and it'll be ready to merge.