Announcement

Collapse
No announcement yet.

[Making sure I have this right] Casting Between Blueprints.

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

    [Making sure I have this right] Casting Between Blueprints.

    Before I begin, I apologize for being so dense, I just want to make sure I'm processing this information correctly before I move on. (The Graphs will be at the bottom of this post.)

    I'm currently following the Blueprint Communication Project in the UE Documentation and I'm on step 4.

    I'm not entirely sure what "Cast To FirstPersonCharacter" is doing there, but I'm going to try to explain it in my own words and see if someone can't help me or nudge me in the right direction.

    Ok, so the way I see it, is that the "Cast To FirstPersonCharacter" blueprint in the level editor is firing off from the "BeginPlay" Node and sending everything after it, to the FirstPerson Character. Which means the event "GetSpawnLocation" and all other variables connected after the cast can now be seen and interacted with inside the first person character.

    Even as I type it, it doesn't sound right. I hope somebody can help.


    Here's the graphs:





    Level Blueprint:



    FirstPersonCharacter Blueprint:

    #2
    So imagine you're going to a store for a friend, but you've never been to it before. You only know the street address. You have a list, but it's not written in English. When you get to the store, you don't know what to make of it.

    Thinking about the most likely store you'd be sent to with a list, you "Cast" the store to a 'grocery store'.

    IF the store is a grocery store
    The store changes subtly, and you can see various food items inside. You enter and approach the counter. Handing your list over, you receive bacon, eggs, and steak in return. You leave back to your friend.
    If not
    The store doesn't change, but now you know it must be another type of store. You "Cast" to a 'convenience store'. You enter and approach the counter. Handing your list over, you receive an energy drink, chips, and a candy bar in return. You leave back to your friend.
    Either way- casting didn't change the type of store it was, however, you were able to interact with the store in a way that made sense for what kind of store it was. Imagine going to a gas station for bacon. The store didn't represent ALL grocery stores or convenience stores, did it? Of course not. It was only one instance of the store type it was. All grocery stores have eggs, but they'll be in different places and the store will have a different amount. All stores have an inventory, though.

    In a similar way, the object reference that you cast is always the same class- just an instance of that class. Casting doesn't change the type the object is, however, it does let you treat the object as the casted type.
    They broke the signatures so I removed mine thinking it'd be awhile. The signatures work again, but I haven't redone my signature yet.

    Comment


      #3
      Originally posted by RetopoJoe View Post
      Ok, so the way I see it, is that the "Cast To FirstPersonCharacter" blueprint in the level editor is firing off from the "BeginPlay" Node and sending everything after it, to the FirstPerson Character. Which means the event "GetSpawnLocation" and all other variables connected after the cast can now be seen and interacted with inside the first person character.
      "sending everything after it" aren't the best word in this case but beside that this sounds correct. The point is that GetPlayerCharacter returns a reference to any character. At that point it isn't known if this character is a FirstPersonCharacter or not and therefore you don't have access to any variable, function or event that additionally exists in your FirstPersonCharacter. Each FirstPersonCharacter is a Character but not each Character is a FirstPersonCharacter. So you're casting the character to FirstPersonCharacter. If the character is a FirstPersonCharacter it has success and you get access to all variables, functions and events within your FirstPersonCharacter. If it fails you know that the character isn't a FirstPersonCharacter.
      Twitter | Multiplayer TopDown Survival Kit | Fog of War | Game Stats Kit

      Comment


        #4
        Originally posted by Pepeeee View Post
        "sending everything after it" aren't the best word in this case but beside that this sounds correct. The point is that GetPlayerCharacter returns a reference to any character. At that point it isn't known if this character is a FirstPersonCharacter or not and therefore you don't have access to any variable, function or event that additionally exists in your FirstPersonCharacter. Each FirstPersonCharacter is a Character but not each Character is a FirstPersonCharacter. So you're casting the character to FirstPersonCharacter. If the character is a FirstPersonCharacter it has success and you get access to all variables, functions and events within your FirstPersonCharacter. If it fails you know that the character isn't a FirstPersonCharacter.

        That grocery store example is hilarious. Here's a different example in case it helps.
        Anyone else think the whole casting thing takes some of the fun out of Blueprints?

        In UDK / Kismet you could pass any object to any node that had an object-in link.
        If it turned out the object wasn't appropriate you got an error message, big deal.
        Example: Pass a Landscape object to Set Material, it expects a Static Mesh so Error!

        Isn't casting left over from the days of C anyway, where types could be changed by force?
        I know casting has other applications here regarding object hierarchy / inheritance, but still...
        And what happened to just TypeOf? The code above doesn't even handle a casting failure!

        Comment


          #5
          Originally posted by Pepeeee View Post
          You are trying to cast the actor you spawned to the class of the actor you spawned it in? This will only work if both actors are of the same class or if the class of the spawned actor is a child class of the other one. I think you misunderstood what typecasting does.
          Assume the following: You have 1 class 'Human'. And 2 child classes of the class 'Human': 'Woman' and 'Man'. The child class 'Woman' does have the boolean variable 'IsPregnant'. Now you store all women and men together in an array of type 'Human'. When you want to get all humans that are pregnant you cannot call the variable 'IsPregnant' on each element of the array because that variable doesn't exist in the class 'Human'. What you need to do is to cast each element of the array to the class 'Woman'. For all men this cast will fail. On all women you can now access the variable 'IsPregnant'. I hope this helps you to understand what casts are made for.
          Hey, so I'm also having a problem with casting, and this analogy you linked makes a lot of sense to me.

          The only part, I guess the mental road block, is this section: "What you need to do is to cast each element of the array to the class 'Woman'"

          I get what the cast node does, I guess I just always have a hard time figuring out "where" to put the cast node in. Thanks for the link.

          Comment

          Working...
          X