Able Ability System Info and Support Thread

[ExtraLifeMatt]

@JSwigart

So the issue I’m running into is that I have a branch conditional that branches to an ability if an input is NOT held, and so the server is not able to check that properly, so it doesn’t hold in the first ability state as I am expecting. Seems to me that if a branch has ANY conditionals that rely on input(or are auth client reliant), the server should basically ignore that branch task altogether. Sorta like the conditionals themselves need to have a EAblAbilityTaskRealm, and if UAblBranchTask::CheckBranchCondition comes across a condition that it can’t evaluate due to the EAblAbilityTaskRealm mismatch, it should abort the function and return false, with the expectation that the auth client is going to take full responsibility for that branch.

What do you think about adding a simpler thing, such as

EAblAbilityTaskRealm m_ConditionsRealm;

to UAblBranchTask so that there is a mechanism to assign sole responsibility for evaluating a branch. It could default to ClientAndServer so as not to change existing behavior, but it would allow a user to assign sole branching responsibility to one side of the network. In this case knowing there are input components to the conditional logic, I could set it to client. The list of alternatives seem far less desirable, such as networking button state, or building in netmode logic into all the blueprint branch conditionals.

Conditions should be shared between Client and Server for security reasons, Input is the one outlier. It’s such a specific case that I would just inherit from the base Conditional class and create your own variation. That’s the simplest solution (and it’s safe for future integrations - just make sure you setup a vendor folder or what not and integrate your changes over when a new version of Able comes out).

@JSwigart

Actually, rather than a conditions realm, it should probably be a bool for only evaluating the conditions if the owner IsLocallyControlled?

That’s effectively what the Input Conditional checks. Again, Input is a very specific case and it doesn’t really apply to all the other conditionals (for example, checking some stat or looking for another running Ability). I would just code a very specific behavior for Input and leave the API the same.