Announcement

Collapse
No announcement yet.

Able Ability System Info and Support Thread

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    I had an issue with channeled conditions that required me to modify the Able code. Pretty sure I mentioned it before in the past. I'm not sure why the fix has yet to make an appearance in the main code. The problem is some conditions are only checkable on the client side, and not the server side, such as the input conditionals, and the logic for branch and channeled conditions doesn't account for that entirely.

    But since functions like UAblChannelingBase::GetConditionResult and the FAblAbilityInstance::CheckChannelConditions that calls it only operate on bools which can be inverted to true when it wasn't able to properly check input.

    In reality, there are 3 states that need to be accounted for by all the condition checking code, branch conditionals and channel conditionals. It needs to make a distinction between explicit success and failure and a condition that cannot be checked, so it really needs to be treated as a tri-state check against the activation logic. Where the logic breaks as-is is given the fact that the results can be inverted, such as "input not pressed". GetConditionResult returns false in that situation when it can't properly check, but because the caller lacks the context that the false is due to the inability to check, if the result is inverted, it gets turned into a success and you have the server making branch of channeling decisions based on information it doesn't have. A tri-state would only invert the explicit states, and not the ignored state.

    Here are select bits of how I fixed these issues, by changing these bools into a tri-state enumerator, and handling them accordingly.

    Click image for larger version

Name:	conditionresult.JPG
Views:	38
Size:	43.8 KB
ID:	1863943
    Click image for larger version

Name:	channelcond.JPG
Views:	38
Size:	331.3 KB
ID:	1863941
    Click image for larger version

Name:	condition_result.JPG
Views:	37
Size:	161.0 KB
ID:	1863942
    Note how the input conditional returns an ignored state, distinct from the true/false success/failure it returned before. This represents a distinct state that won't be mistaken for an explicit success/failure state
    Click image for larger version

Name:	inputcond.JPG
Views:	37
Size:	160.1 KB
ID:	1863944

    By handling these distinct states properly, you ensure that anything involving input conditionals, or any user added realm specific conditionals, can ONLY drive state changes from the appropriate realm(client/server)
    Attached Files

    Comment


      Ah, that does ring a bell. Not sure why it got missed either. Thanks JSwigart

      Just a heads up, I'm in Austin and just got back to my place after 5 days without power / water. Power is back but still waiting on water. I'm safe and have supplies, but be patient as I get settled back in and try to get back into a normal flow. Hope everyone else is staying safe out there.
      Able Ability System - A high performance, robust ability system for UE4. Now Available!

      Comment


        Hi Matt.

        First off great plugin and glad to hear you're getting back to normal and safe.

        Quick question, If I need my character to instantly rotate to where the camera is facing on ability cast, fully networked, what would be the best way to go about that?

        I suggest adding a m_TargetRotation or something that can be set on the context before being sent to the server, then use that to set context owner's rotation on all the clients. The TurnTo Task doesn't work here because there isn't a target, and the TurnTo Camera wouldn't work in a networked environment if I'm not mistaken.

        Thanks again for the great plugin

        Comment

        Working...
        X