Announcement

Collapse
No announcement yet.

Able Ability System Info and Support Thread

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

    Also, I'm running into a more serious crash for some reason.

    UObject* UClass::CreateDefaultObject()
    {
    if ( ClassDefaultObject == NULL )
    {
    ensureMsgf(!HasAnyClassFlags(CLASS_LayoutChanging), TEXT("Class named %s creating its CDO while changing its layout"), *GetName());

    I have a Punch_Right_Into ability that seems to be compiling in the blueprint but one of the exports references itself, so when it attempts to create the default class for it, this ensure fails and crashes the game. Not sure what is causing this self reference.


    callstack.txt

    Comment


      Originally posted by JSwigart View Post
      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?
      Possibly. The REINST means the blueprint was reinstanced under it. I wouldn't think that would cause your issue, but I honestly don't know. Marketplace support just got back to me and said they are experiencing longer than normal delays but the update was received and is working its way through the system.
      Able Ability System - A high performance, robust ability system for UE4. Now Available!

      Comment


        For the CDO crash, here's where it looks like it's self referencing. In FLinkerLoad::FindExistingExport

        The lines
        TheClass->GetDefaultObject(); // build the CDO if it isn't already built
        Export.Object = StaticFindObject(TheClass, OuterObject, *Export.ObjectName.ToString(), 1);

        It's blowing up on that GetDefaultObject()
        this 0x000002cfe9de5600 {LoadFlags=0 bHaveImportsBeenVerified=false bDynamicClassLinker=false ...} FLinkerLoad *
        TheClass 0x000002cdf2696b00 (Name=0x000002cdaafd9114 "Punch_Right_Into_C") UClass * {UE4Editor-AbleCore-Win64-DebugGame.dll!UAblAbilityBlueprintGeneratedClass}
        OuterObject 0x000002cdf26dc480 (Name=0x000002cdc9cf91dc "/Game/Timeless/Spells/PlayerAbilities/Punch_Right_Into") UObject * {UPackage}
        Export.ObjectName 0x000002cdcb8b8c04 "Default__Punch_Right_Into_C" FName

        Any idea what might cause this?
        Last edited by JSwigart; 09-17-2019, 11:41 AM.

        Comment


          This may be unrelated, but is there a possibility that if you duplicate an ability, that it could be broken? I want to say the abilities I am having these issues with are ones that I had duplicated from another similar ability to avoid recreating them from scratch.

          Comment


            Originally posted by JSwigart View Post
            For the CDO crash, here's where it looks like it's self referencing. In FLinkerLoad::FindExistingExport

            The lines
            TheClass->GetDefaultObject(); // build the CDO if it isn't already built
            Export.Object = StaticFindObject(TheClass, OuterObject, *Export.ObjectName.ToString(), 1);
            Originally posted by JSwigart View Post
            This may be unrelated, but is there a possibility that if you duplicate an ability, that it could be broken? I want to say the abilities I am having these issues with are ones that I had duplicated from another similar ability to avoid recreating them from scratch.

            Any idea what might cause this?
            The Default Object is created when you load that object (normally you can call GetDefaultObject and it will force a load). If it's a reinstance of a class, then it may not have a default object yet (or it's still compiling it). There's a lot of reasons why it may not have a CDO yet (SKEL's don't get CDOs at all for example).

            Blueprints work well, but they have lots of gotchas. I find duplicating them to be a dubious task at best. If you find yourself doing a lot of duplication, you may want to try and take one layer of complexity out by putting that into a custom C++ task with whatever values you are just tweaking exposed.
            Able Ability System - A high performance, robust ability system for UE4. Now Available!

            Comment


              I re-created the problematic abilities from scratch and so far I'm not getting the issue described. I'm thinking there is definitely an issue with duplicating abilities.

              Comment


                Can you explain the logic of UAblCancelAbilityTask::ShouldCancelAbility ?

                Specifically, why does the function have that first early return true?

                if (*m_Ability && m_Ability->GetDefaultObject<UAblAbility>()->GetAbilityNameHash() == Ability.GetAbilityNameHash())

                I was trying to make a stackable DOT fire effect with a task that cancelled itself if the conditions of the ShouldCancelAbilityBP were met, so it can manage its own decay and take advantage of the RemoveOneStack functionality already implemented here, but this early out was preventing my function from being called. Curious why this early out exists?

                Comment


                  Originally posted by JSwigart View Post
                  Can you explain the logic of UAblCancelAbilityTask::ShouldCancelAbility ?

                  Specifically, why does the function have that first early return true?

                  if (*m_Ability && m_Ability->GetDefaultObject<UAblAbility>()->GetAbilityNameHash() == Ability.GetAbilityNameHash())

                  I was trying to make a stackable DOT fire effect with a task that cancelled itself if the conditions of the ShouldCancelAbilityBP were met, so it can manage its own decay and take advantage of the RemoveOneStack functionality already implemented here, but this early out was preventing my function from being called. Curious why this early out exists?
                  I believe the case was to prevent an Ability from cancelling itself mid update... that may no longer be a problem with the delayed cancelling of abilities that went in a few updates ago. I'll have to poke at it.
                  Able Ability System - A high performance, robust ability system for UE4. Now Available!

                  Comment


                    Fyi, there's a crash in HandlePendingCancels that I fixed as follows.

                    Click image for larger version  Name:	Capture.PNG Views:	2 Size:	31.1 KB ID:	1666364

                    Didn't make sense to me at first until I read a few posts about it, such as https://answers.unrealengine.com/que...ml?sort=oldest

                    Basically the CheckAddress call in the Remove function verifies that you aren't passing a reference that is within the array, because it can get corrupted during removal. The fix is just to grab a local reference to the object being removed and pass that in.

                    Comment


                      Originally posted by JSwigart View Post
                      Fyi, there's a crash in HandlePendingCancels that I fixed as follows.

                      Click image for larger version Name:	Capture.PNG Views:	2 Size:	31.1 KB ID:	1666364

                      Didn't make sense to me at first until I read a few posts about it, such as https://answers.unrealengine.com/que...ml?sort=oldest

                      Basically the CheckAddress call in the Remove function verifies that you aren't passing a reference that is within the array, because it can get corrupted during removal. The fix is just to grab a local reference to the object being removed and pass that in.
                      Yea, that theoretically is the same. Thanks for the fix, I'll toss it in the next update - if only to be a bit more explicit.
                      Able Ability System - A high performance, robust ability system for UE4. Now Available!

                      Comment


                        It can do broken stuff if the reference passed in falls into the memory range of the list as the removal moves stuff around and effectively changes the value from under the remove parameter., so their CheckAddress is a interesting protection against that edge case.

                        Comment


                          Originally posted by JSwigart View Post
                          It can do broken stuff if the reference passed in falls into the memory range of the list as the removal moves stuff around and effectively changes the value from under the remove parameter., so their CheckAddress is a interesting protection against that edge case.
                          Ahhhh, I see it. Yea, FindByPredicate returns the address of an actual element from the allocated block - which normally doesn't matter because you'd copy it off to a temporary variable. But since it's a double pointer, you end up passing a variable that is within that block and check address fails because the address of the variable being passed in is from that block and will be corrupted when the move happens. That explains why the simple temporary variable fixes it.

                          Gotcha, yea, I'll get that in this weekend.

                          Able Ability System - A high performance, robust ability system for UE4. Now Available!

                          Comment


                            I have a question about able and networking. What is the typical philosophy behind the logic one might want to have implemented inside the CanAbilityExecute function of the ability?.

                            I have a dash ability that has a CanAbilityExecute function which checks if the owner pawn has any available "dash charges" that recharge over time. When the ability activates, only the server subtracts 1 dash charge. During The dash charge variable is replicated to the client apparently before the ability starts(at least in PIE), so the client fails the custom check and does not activate the ability, while the server does.

                            How do you normally handle these sorts of data dependencies?

                            Comment


                              Originally posted by JSwigart View Post
                              I have a question about able and networking. What is the typical philosophy behind the logic one might want to have implemented inside the CanAbilityExecute function of the ability?.

                              I have a dash ability that has a CanAbilityExecute function which checks if the owner pawn has any available "dash charges" that recharge over time. When the ability activates, only the server subtracts 1 dash charge. During The dash charge variable is replicated to the client apparently before the ability starts(at least in PIE), so the client fails the custom check and does not activate the ability, while the server does.

                              How do you normally handle these sorts of data dependencies?
                              That sounds like the server is initiating the dash. Normally I would have the client initiate it (so it does the dash charge check) and the server just verifies and plays it as well.
                              Able Ability System - A high performance, robust ability system for UE4. Now Available!

                              Comment


                                Ok, so the issue seems to be that there is a behavioral difference between the client(listen server?) running in the editor window, and the client running in the popup window during PIE.

                                In the Editor window, the call to UAblAbilityComponent::ActivateAbility call ends up activating the ability server side first, because it takes the code path for authoritative

                                // We're authoritative. Start the Ability.
                                Result = InternalStartAbility(Context);

                                While the client in the popup window functions as you describe, where it's not authoritative, so it sends the ServerActivateAbility RPC and then starts the ability locally, which activates the abilities in the 'proper' order of client then server.

                                How do you handle this inconsistency in PIE ?

                                Comment

                                Working...
                                X