There is an easy fix for that, which is to create a new function and call the new one from the old one.
int32 UAbilitySystemComponent::HandleGameplayEvent(FGameplayTag EventTag, const FGameplayEventData* Payload) { return HandleGameplayEventEx(EventTag, Payload).Num(); }Regarding the activation triggers. If an ability has configured in its data A.B and A.B.C it is true that it is a redundant configuration, because A.B will be enough to trigger the ability. But it happened to us multiple times that an ability has many (10+) activation events and some of them might become redundant by accident. This should not be reason enough to trigger the ability multiple times with the same event. The code should be robust to any data configuration without leading to undefined behavior.
Regarding the delegate processing I understand that it is a change in the API, but having the map
TMap<FGameplayTag, FGameplayEventMulticastDelegate> GenericGameplayEventCallbacks;
totally accessible as public is really bad. It should have never been public in the first place.
It is prone to errors and caused many bugs in the past to us. For instance you call GenericGameplayEventCallbacks.Remove(tag) //this is TMap::Remove
instead of
GenericGameplayEventCallbacks.FindOrAdd(tag).Remove(handle) // this is MulticastDelegate::Remove
and you are removing all delegates of a certain tag, which you should not be allowed to (because you don’t know if anyone else might be registered to that same tag.
Also it is inefficient as the map keeps growing and growing with tags containing empty delegates. There is no cleanup code that deletes empty entries.
I would at least consider deprecating the public access to GenericGameplayEventCallbacks in an intermediate version and then make it protected in a newer version.