Announcement

Collapse
No announcement yet.

Stale TWeakObjectPtr

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

    Stale TWeakObjectPtr

    Initially I instantiated a class from my GameMode and accessed in other parts of the game. This appeared to work well. Since making use of FStreamableManager for loading assets, I decided to move several items into GameInstance. The problem I'm having now though is that the TWeakObjectPtr becomes Stale for no apparent reason:

    Click image for larger version

Name:	Stale.TWeakObjectPtr.jpg
Views:	1
Size:	10.4 KB
ID:	1159378

    What is the proper way to instantiate a TWeakObjectPtr? Is the below valid:

    Code:
    Manager = TWeakObjectPtr<UMyManager>(NewObject<UMyManager>(UMyManager::StaticClass()));
    What about returning the pointer to other classes:

    Code:
    TWeakObjectPtr<UMyManager> UMyGameInstance::GetMyManager()
    {
        return Manager;
    }
    What about AddRef()?

    How can I make it so that the members of my class are not going out of "scope", being STALE?
    Attached Files
    Last edited by Jerry.Richards; 08-13-2015, 05:15 PM.

    #2
    Why are you using a weak pointer? The whole point of it is that it will not prevent the object from being garbage collected (and when that happens, the weak pointer will be marked as stale). Clearly for a manager class, you want it to persist, so you shouldn't store it in a weak pointer.

    Just have
    Code:
    UPROPERTY()
    UMyManager* Manager;
    in your game instance, and assign it as follows
    Code:
    Manager = NewObject<UMyManager>();
    You can then return it in GetMyManager as a raw UMyManager*, since you can assume that the game instance will be around as long as any caller, so it won't be garbage collected.
    Last edited by kamrann; 08-14-2015, 03:32 AM.

    Comment


      #3
      Thank you Kamrann for confirming that for me. After reading another thread someone else mentioned using UPROPERTY() for persistence reasons. And I have already switched to the syntax you described above. Then I found class members, those objects managed by the manager, going out of scope (FText for example). So I made almost everything a UPROPERTY() in the managed objects too. Is this correct then?

      Comment


        #4
        What do you mean by going out of scope?
        Only UObjects will be garbage collected. If your manager is stored as a UPROPERTY it will be fine, so anything embedded in it that isn't a UObject (such as an FText) will also persist just fine. The only reason to make those UPROPERTY also would be if you want to access the members in the editor/via blueprint.

        Comment


          #5
          Without UPROPERTY on the manager, the manager goes out of scope. I just reverted my code back to the following:

          Code:
          .h
              UMyManager* Manager;
          
          .cpp
              :
              Manager = NewObject<UMyManager>();
              :
          
              UMyManager* UMyGameInstance::GetManager()
              {
                  return Manager;
              }
          And while accessing it from code derived UUserWidget:

          Code:
          void UMyWidget::Update()
          {
              gameInstance = (UMyGameInstance*)(GetWorld()->GetGameInstance());
              int32 item = gameInstance->GetManager()->GetSomeItem();
          The debugger shows that the Manager object has gone out of scope:

          Click image for larger version

Name:	Stale.TWeakObjectPtr.02.jpg
Views:	1
Size:	13.7 KB
ID:	1083752

          Comment


            #6
            Additionally, after adding UPROPERTY() to the Manager the UObjects managed by it appear to go out of scope:

            Click image for larger version

Name:	FText.OutofScope.jpg
Views:	1
Size:	112.2 KB
ID:	1083755



            This error is due to subobjects going out of scope:

            Click image for larger version

Name:	Subobjects.OutofScope.jpg
Views:	1
Size:	32.8 KB
ID:	1083756
            Last edited by Jerry.Richards; 08-14-2015, 11:07 AM.

            Comment


              #7
              Sorry, yeah you definitely need UPROPERTY on the manager itself.

              I can't tell from that image what is causing the other issue. You'd need to check the call stack window in VS when the exception occurs, and find where in your own code it is being triggered (hit the Break button, open the call stack debug window, and try double clicking on the entries below the very top one until you find one inside your own code). That should give a better idea of why it's happening.

              Comment


                #8
                Thanks. I'll let you know if I find the root of the problem.

                Comment


                  #9
                  Hang on I didn't see your last image before. What is this array with two elements? If your manager embeds other UObjects inside it, either directly or through an array/struct, those will need to be UPROPERTY as well.

                  Basically, any UObject-derived member (or array thereof) needs to be UPROPERTY to keep it from being garbage collected. Other type such as FText etc don't need to be, but should be anyway if you want editor/blueprint access to them.

                  Comment


                    #10
                    Thank you I thought I was going crazy. Yes, they are UObjects that were garbled up. I'll make sure to make a note of this requirement for UObject members.

                    If I posted another question, would you be able to help me with FArchive problem?

                    Comment


                      #11
                      Most probably not because I've never used it. Post away anyway (in a new thread), I'll take a look, and someone may be able to help.

                      Also check this out for another good learning resource.

                      Comment


                        #12
                        Thanks, that is pretty cool.

                        Comment

                        Working...
                        X