Announcement

Collapse
No announcement yet.

Able Ability System Info and Support Thread

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

    Originally posted by brian.boettger View Post
    ExtraLifeMatt It's set to Try To Adjust Location But Always Spawn. I tried setting it to always spawn ignore collision and it did the same thing.

    Just to make sure I removed the spawn actor task and created a new starting with "Always Spawn Ignore Collision" and it did it again..
    Hmmm, you have a class specified I assume? The issue is definitely the SpawnActor is failing for some reason... I can make it a bit more tolerant and just report an error when it fails to spawn (rather than crashing), but that likely won't fix your underlying issue.
    Able Ability System - A high performance, robust ability system for UE4. Now Available!

    Comment


      let me actually answer the question since you asked while i was typing my last novel.
      the class is specified and when i break point on the destroy actor methods in the projectile blueprint (On Begin Overlap), it hits that function. if i F11 past, it crashes after it destroys the actor?

      now, my character is replicated using a controller and character server side then a pawn and pawn controller client side.
      This could obviously lead to "lag" and it's fairly safe to say that it works normally when the destroy request is not so immediate to its being spawned.
      so i guess that's a wordy way of saying, i wonder of because of auth check on the character->controller etc architecture, it's not done "spawning" before it runs the assert because it was destroyed?
      Last edited by brian.boettger; 09-10-2019, 03:00 PM.

      Comment


        Originally posted by brian.boettger View Post
        let me actually answer the question since you asked while i was typing my last novel.
        the class is specified and when i break point on the destroy actor methods in the projectile blueprint (On Begin Overlap), it hits that function. if i F11 past, it crashes after it destroys the actor?

        now, my character is replicated using a controller and character server side then a pawn and pawn controller client side.
        This could obviously lead to "lag" and it's fairly safe to say that it works normally when the destroy request is not so immediate to its being spawned.
        so i guess that's a wordy way of saying, i wonder of because of auth check on the character->controller etc architecture, it's not done "spawning" before it runs the assert because it was destroyed?
        Maybe? I would expect it to still exist when the assert happens, just marked for GC. However there may be some "optimization" where if you spawn an actor and immediately call for it's destruction, that the GC happens immediately - in which case it would return nullptr and the assert would fail.

        I'll turn that assert into a warning. It's likely what is happening is fine, it's just not expected from Able's end.
        Able Ability System - A high performance, robust ability system for UE4. Now Available!

        Comment


          Seems to be a bug with channel conditions. UAblAbilityComponent::InternalCancelAbility gets called, but since the ability IsProcessingUpdate() it gets deferred into the m_PendingCancels. Problem is, the // Check for Channeling... block in ablAbilityComponent.cpp goes ahead and sets m_ActiveAbilityInstance to null, so in HandlePendingCancels it's null and isn't able to appropriately finish the ability.

          I'm guessing that // Check for Channeling... block should not be nulling the active ability instance?

          Edit: Ok this was only a problem because we had a local modification that set m_IsProcessingUpdate at the top of the tick.
          Last edited by JSwigart; 09-11-2019, 02:51 PM.

          Comment


            Originally posted by JSwigart View Post
            Seems to be a bug with channel conditions. UAblAbilityComponent::InternalCancelAbility gets called, but since the ability IsProcessingUpdate() it gets deferred into the m_PendingCancels. Problem is, the // Check for Channeling... block in ablAbilityComponent.cpp goes ahead and sets m_ActiveAbilityInstance to null, so in HandlePendingCancels it's null and isn't able to appropriately finish the ability.

            I'm guessing that // Check for Channeling... block should not be nulling the active ability instance?

            Edit: Ok this was only a problem because we had a local modification that set m_IsProcessingUpdate at the top of the tick.
            Yea, careful with that. That flag is set at a very specific time.
            Able Ability System - A high performance, robust ability system for UE4. Now Available!

            Comment


              Can you talk me through the multiplayer control flow of abilities that have branching?

              For branch conditionals like UAblBranchConditionOnInput that rely on an input component that only exists on the auth client, how are abilities with input driven branching meant to be kept in sync on the client and server in multiplayer?

              If you start ability A, and it branches to ability B, the server isn't going to be able to properly evaluate that branch if it uses input conditionals, so the ability is going to get out of wack. Is the intention that in these circumstances the auth client will act as authority and 'correct' the server when it decides to branch?

              Comment


                Originally posted by JSwigart View Post
                Can you talk me through the multiplayer control flow of abilities that have branching?

                For branch conditionals like UAblBranchConditionOnInput that rely on an input component that only exists on the auth client, how are abilities with input driven branching meant to be kept in sync on the client and server in multiplayer?

                If you start ability A, and it branches to ability B, the server isn't going to be able to properly evaluate that branch if it uses input conditionals, so the ability is going to get out of wack. Is the intention that in these circumstances the auth client will act as authority and 'correct' the server when it decides to branch?
                For input conditionals, yes. You have to, for the reason you suspect.

                Effectively:

                Client tests for Input Condition and passes -> Calls ServerBranchAbility -> Server sees the Client wants to branch to that Ability and says "sure" -> Server tells the Client to branch (Client already is branching locally at this point so this is more for remote clients).
                Able Ability System - A high performance, robust ability system for UE4. Now Available!

                Comment


                  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.
                  Last edited by JSwigart; 09-12-2019, 05:02 PM.

                  Comment


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

                    Comment


                      Originally posted by JSwigart View Post
                      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).

                      Originally posted by JSwigart View Post
                      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.
                      Able Ability System - A high performance, robust ability system for UE4. Now Available!

                      Comment


                        ExtraLifeMatt Just checking in, it's weird that the UE4.23 Able isn't available in the marketplace yet. You mentioned that you submitted the update a week ago. Could something have gone wrong where it didn't actually get submitted?

                        Comment


                          Originally posted by Decriment View Post
                          ExtraLifeMatt Just checking in, it's weird that the UE4.23 Able isn't available in the marketplace yet. You mentioned that you submitted the update a week ago. Could something have gone wrong where it didn't actually get submitted?
                          It came back late last week with an error, I resubmitted that evening and haven't heard anything since (says it's still processing). Generally they tend to be pretty backed up since EVERYONE has to update their plugins. I know as much as you do at this point. I'll poke some people if I don't hear anything in a few days.
                          Able Ability System - A high performance, robust ability system for UE4. Now Available!

                          Comment


                            I'm running into an issue with an ability that references a custom task. I can select the custom task to add it to the timeline, and it compiles and saves without any apparent issue, but next time I open the editor, if I try to save that ability again, I get "check" assets in engine code for that referenced task

                            void UBlueprintGeneratedClass::InitPropertiesFromCustomList(uint8* DataPtr, const uint8* DefaultDataPtr)
                            {
                            FScopeLock SerializeAndPostLoadLock(&SerializeAndPostLoadCritical);
                            check(bCustomPropertyListForPostConstructionInitialized); // Something went wrong, probably a race condition
                            ...


                            Also, perhaps related, but the Task name in the timeline changes to have a REINST_ prefix.

                            Anyone else see this sort of issue?

                            Comment


                              Originally posted by JSwigart View Post
                              I'm running into an issue with an ability that references a custom task. I can select the custom task to add it to the timeline, and it compiles and saves without any apparent issue, but next time I open the editor, if I try to save that ability again, I get "check" assets in engine code for that referenced task

                              void UBlueprintGeneratedClass::InitPropertiesFromCustomList(uint8* DataPtr, const uint8* DefaultDataPtr)
                              {
                              FScopeLock SerializeAndPostLoadLock(&SerializeAndPostLoadCritical);
                              check(bCustomPropertyListForPostConstructionInitialized); // Something went wrong, probably a race condition
                              ...


                              Also, perhaps related, but the Task name in the timeline changes to have a REINST_ prefix.

                              Anyone else see this sort of issue?
                              Yea, you don't want REINST_. This is fixed in the latest version (which still hasn't gone out - I'm writing up an email to marketplace support right now).
                              Able Ability System - A high performance, robust ability system for UE4. Now Available!

                              Comment


                                It didn't have the REINST_ when I first selected it. Only after saving and reloading did it start asserting. Does the fix address that? Any idea how long it will take to go live?

                                Comment

                                Working...
                                X