Announcement

Collapse
No announcement yet.

Is this advised? TempActor->GetName() != "None"

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

    Is this advised? TempActor->GetName() != "None"

    With all the crash related debugging Ive been doing lately, I noticed with a number of the crashes that the related Object sometimes had a Name of "None".
    (Specifically, Access None crashes that are already behind a IsValid() check)
    I read somewhere(I think a comment line in the SpawnActor code, IIRC) that this shouldn't happen because Actors are supposed to automatically be given a name based on their class and a unique number(which matches up with what Ive seen of their names at runtime). So I decided to try putting a check filter in my custom validator function:

    TempActor->GetName() != "None"
    (obviously TempActor is validated first so as not to run afoul of calling GetName())

    It seems to work fine enough(meaning Ive not seen a Name = None related crash since then), but Im not sure if this is 1) Not actually doing anything, and the lack of crashes is just that I haven't seen one yet, or 2) might cause some problems in functionality elsewhere Im not aware of (tho again it doesn't appear to so far).

    So my question is if there is any reason I shouldn't be doing that kind of "is valid" check?
    Are there situations in the Engine's code, that my code would be interacting with, where an Actor/Object is suppose to exist without a Name?
    Last edited by Erdrik; 10-12-2017, 01:15 PM.

    #2
    That won't work.
    First you should check against 'NAME_None' , NULL, 0, or 'None' macros instead of "None" string;
    Second that won't work either since, if the TempActor doesn't exist, GetName() will never return anything.
    | Savior | USQLite | FSM | Object Pool | Sound Occlusion | Property Transfer | Magic Nodes | MORE |

    Comment


      #3
      I do use "!= NULL" as well. As I said in the OP the GetName() check is after such checks.
      I was not aware that NAME_None was a thing tho. Thank you.

      EDIT:
      Just for clarity, does TempActor != NAME_None and TempActor->GetName() != "None" check the same thing?

      EDIT:
      Can I get an example of use for NAME_None?
      TempActor != NAME_None will not compile.
      Last edited by Erdrik; 10-12-2017, 02:07 PM.

      Comment


        #4
        TempActor is a pointer, you can't compare a pointer with an FName (which is NAME_None).

        GetName() returns a string (IIRC), so you can do the GetName() != "None".
        GetFName() returns an FName value (which is just an integer under the hood), so you could do GetFName() != NAME_None which is much faster than a string compare.

        In the end, I think you're likely chasing a value that is either about to be destroyed, or is in the process of being destroyed. If you actually are using a Weak Ptr for your Temp Actor value, then isValid should not allow you to access a pointer that is being garbage collected.

        Code:
        TWeakObjPtr<AActor> TempActor = /* Some Actor */
        if (TempActor.IsValid())
        {
            // Our actor is still valid, you can operate on it as normal.
            TempActor->DoStuff();
        }
        else
        {
           // No longer valid, you can reset the weak ptr here if you want, but it's not necessary.
           TempActor.Reset();
        }
        Able Ability System - A high performance, robust ability system for UE4. Now Available!

        Comment


          #5
          Won't complie with TWeakObjPtr.
          Do I need a specific include file for that?

          "'TWeakObjPtr': undeclared identifier"

          Comment


            #6
            Originally posted by Erdrik View Post
            Won't complie with TWeakObjPtr.
            Do I need a specific include file for that?

            "'TWeakObjPtr': undeclared identifier"
            Sorry, it's TWeakObjectPtr
            Able Ability System - A high performance, robust ability system for UE4. Now Available!

            Comment


              #7
              Ah. No problem, thanks.

              Comment

              Working...
              X