Announcement

Collapse
No announcement yet.

Change text in a widget with variables, help?

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

    Change text in a widget with variables, help?

    I'm have a hard time figuring out the logics of how to change text using variables in UE4.
    I know this is a real newbie question, but I just need to understand the logics on how to update widget text through variables from one object to another.

    I have created a widget which I have mounted to the camera, just as a test. "Text Block" text field is set as a variable in the Widget details.

    But from here the logics are no longer with me.

    Just a basic thing as updating the text using two different variables from the level blueprint when pressing the C key. Why would I need the Object pin in the cast for this simple task? What should I put in that Object slot?

    I'm casting to the widget, and then I want to set a variable with say "1000" on FlipFlop A and "2000" on FlipFlop B, and just sending a set variable commando to the variable residing in the widget that holds the "Text Block" text, and hence updating the text.

    What am I missing here, can anyone give me a direction? Thanks.
    Last edited by chroma123; 06-18-2018, 01:49 PM.

    #2
    I usually do UI and widged-related casting via gamemode (or game instance at times), to ensure that casting will always succeed no matter at what development stage I add new levels to the game or new sub widgets or features to the UI. This also works universally, so you can use same variables stored in the Gamemode for many different things.

    In Level Blueprint I would have: "Cast to GameMode" node, with "Get GameMode" connected to the blue pin. At the blue pin, click "promote to variable" to make a reference of that GameMode so you can use that reference every time you want to save or get information from/to GameMode.

    In GameMode, just make a string/name/text/whatever variable. You dont need to do casting here, as the variable is just stored there and other sources will get the info from there. Lets say "TextBlock" named text variable.

    In the WidgetBP, have a "Cast to GameMode" node, with "Get GameMode" connected to the blue pin as in LevelBP. From the blue pin, click "promote to variable" as well. Now you can use that small blue reference every time you need something from the gamemode or saved there. In your case, pull a line from that small reference block and write "get TextBlock" and it will find the TextBlock variable you made inside GameMode.

    Comment


      #3
      Originally posted by Manatee View Post
      In Level Blueprint I would have: "Cast to GameMode" node, with "Get GameMode" connected to the blue pin.
      Thanks! A couple more questions.
      1) From what node would you use "Cast to GameMode"?
      2) Do you mean Cast to my game mode, or "Cast to GameMode"? Both are available.
      3) What you're saying is that it's possible to make, read and write variables in GameMode on runtime, or do they all have to be predefined in the construct?


      Comment


        #4
        Putting the GameMode method aside for a second, just for my understanding of the variable communication in blueprints.
        Take a look at this image, and specifically the nodes at the top.
        I understand that the object in the left node of the Casts, should be the object that actually sits in the scene.

        Just to have something to trigger the action, I'm using keyboard C. This Casts to an Actor called "PrisVariables", which holds the variable I'm trying to make use of. I get it to output in the print.
        But how do go from here to update the text field in my widget? The widget is connected to my pawn, and spawned with it.
        To relate to the image attached here, I'm Casting to BP_PrisWidget, where the only simple task is to set the Textblock1Pris (which is a variable text field) with the content of the variable "Prisene".
        What I don't understand is, what do I put into the Casting object node, the player pawn? And the variable "Prisene" doesn't seem to get accepted by the last Set node.

        For me there are so many non-logical things going on, but I just need to fetch the general idea of how this can be achieved.
        Thanks again.

        Comment


          #5
          Originally posted by chroma123 View Post

          Thanks! A couple more questions.
          1) From what node would you use "Cast to GameMode"?
          2) Do you mean Cast to my game mode, or "Cast to GameMode"? Both are available.
          3) What you're saying is that it's possible to make, read and write variables in GameMode on runtime, or do they all have to be predefined in the construct?

          1)Begin Play or Construction script, so that the link to the game mode has been made right at the start and can be used anywhere later
          2)I think the My Game Mode is just an alternative GameMode blueprint that comes with the game templates. You can choose from the game settings which is the GameMode blueprint which to be used. Its probably now MyGameMode since that exists.
          3)You cant make completely new variables in gamemode dynamically from other blueprints (I think). But you dont need to predefine the used variables. As long as you have casted to it once, you can use the object variable to read and write everything in GameMode.

          Comment


            #6
            Originally posted by chroma123 View Post
            Putting the GameMode method aside for a second, just for my understanding of the variable communication in blueprints.
            Take a look at this image, and specifically the nodes at the top.
            I understand that the object in the left node of the Casts, should be the object that actually sits in the scene.

            Just to have something to trigger the action, I'm using keyboard C. This Casts to an Actor called "PrisVariables", which holds the variable I'm trying to make use of. I get it to output in the print.
            But how do go from here to update the text field in my widget? The widget is connected to my pawn, and spawned with it.
            To relate to the image attached here, I'm Casting to BP_PrisWidget, where the only simple task is to set the Textblock1Pris (which is a variable text field) with the content of the variable "Prisene".
            What I don't understand is, what do I put into the Casting object node, the player pawn? And the variable "Prisene" doesn't seem to get accepted by the last Set node.

            For me there are so many non-logical things going on, but I just need to fetch the general idea of how this can be achieved.
            Thanks again.
            Have you first made the prisWidget blueprint via "Create Widget" and "Add to Viewport"? From the Create Widget, you can promote the prisWidget to an object variable again.

            In your picture, the prissWidget is red because there is no object connected to it. And the object would that you made with the Create Widget. (Actually Create Widget does casting at the same time, so you dont even need to cast again in case of Widgets but this doesnt break it either).

            On the left, you have the Prisene object variable. Have you tried pulling a line from it while "Context sensitive" is on? You should be able to now type "set textblock1pris" and it should be available and automaticly linked.

            Problem with storing this textblock1pris variable in actor is, that the widget cant be sure that the actor exists, you wont be able to cast to an actor from the widget. This is why game mode is more reliable, everything can communicate with it.

            The name "Cast to" might confuse you, at least it did me. You cant pass information from Blueprint A (lets say level) which is saved in Blueprint B (an actor) to Blueprint C (which is Widget), even though it sounds like Cast TO does that. Cast To simply makes a bridge from the the blueprint you are using, to the blueprint you are casting to. To get information into Blueprint C, you need to do casting there to the source where you want information directly from.
            So to update the text field in the widget you have, you need to open the prissWidget, and in it, cast to the source where the variable is stored at.

            The problem in your case is, that Widgets are kind of complex on what they accept, since Widgets are made after the game/level has been constructed, and cant rely on actors existing the way GameMode and Level blueprints can. You can do it, but it requires more hassling around. Whis is another reason why I keep UI related stuff in the GameMode and not in actors.
            Last edited by Manatee; 06-19-2018, 10:13 AM.

            Comment


              #7
              EDIT: Sorry, i was looking at a couple different ways to do this. You do not need the custom event on the widget...ignore the widget (just make sure your text block is there and set as a variable). (ARGH! Can't remove the Widget image...just ignore it)

              In the level BP, just grab the reference to the text block and set the text.
              Last edited by Tearl; 06-19-2018, 10:19 AM.
              Tracey White - Senior Design Visualization Artist / PC Game Enthusiast / Drummer
              My Maze Game development video series
              My Maze Game Blog

              Comment


                #8
                I really appreciate your response! I'll test this tomorrow.
                ​​​​​​

                So say I've got variables coming from around the scene, forming arrays, strings and other variables. Would it make sense collecting/placing all of them into one place (actor or game mode) with blueprint functions for in and out handling, and with what kind of reference types would be best to use for handling in an effective way? In this specific case, I'm going to collect price information for objects that are changing on user input, like a price configurator.

                For what it's worth, I'm fluent in script languages like actionscript and maxscript, but this all variable handling in blueprints still doesn't make 100% sense. Coming a long way now. Thanks again for your input.
                Last edited by chroma123; 06-19-2018, 03:31 PM.

                Comment


                  #9
                  We put pretty much everything on our player character. Even stuff that isn't part of the character For example, we use a Widget with a slider for Time of Day and there's the TOD Blueprint in the level. Well, the Player Character already has the Widget reference (created in the Character BP) and it's easy to get a reference to the Time of Day BP in the level. So the Widget passes the Time through the Character, to the TOD BP.
                  There's a lot of different ways to handle it...Player Character is our way.
                  Tracey White - Senior Design Visualization Artist / PC Game Enthusiast / Drummer
                  My Maze Game development video series
                  My Maze Game Blog

                  Comment


                    #10
                    Originally posted by Tearl View Post
                    We put pretty much everything on our player character. Even stuff that isn't part of the character For example, we use a Widget with a slider for Time of Day and there's the TOD Blueprint in the level. Well, the Player Character already has the Widget reference (created in the Character BP) and it's easy to get a reference to the Time of Day BP in the level. So the Widget passes the Time through the Character, to the TOD BP.
                    There's a lot of different ways to handle it...Player Character is our way.
                    Yeah, I used that a lot too. And certainly there is many ways.

                    One thing to remember though, is that if you want your variables to stay saved withing level loads, you will need to store those in "Game Instance". Thats the only (besides save data) that stays in memory from the game start to close down no matter what happens. In example, HP or ammount of gold of the character to keep the same between map loads. In other types the blueprints those will reset themselves to the default when opening a new level. It of course depends on how you build your game etc. but just a thing to keep in mind.

                    Comment


                      #11
                      Very interesting input here, guys. Thanks! Things are coming along. While I see the thing about the GameMode, I need to keep it as simple as possible regarding accessibility, so that I don't **** things up too much without the ability to solve it without exploding my head. I don't need to use several levels in this concept.

                      So regarding the widget that should output the Pawn/character stored variables, it should be loaded/constructed during runtime with a blueprint, and not attached up front to the pawn, right - to be able to promote the widget to an accessible variable/reference? But it should still be attached to the pawn when it's runtime-constructed, for easy accessibility "pawn variables" <-> "widget variables". Have I got it right then? And last, how would I access variables in this widget from the pawn, do I still need to cast, and if so, I'll cast with that widget variable created with blueprint in the constructor, right?

                      Ok peace out!

                      Comment


                        #12
                        , not attached up front to the pawn, right - to be able to promote the widget to an accessible variable/reference? But it should still be attached to the pawn when it's runtime-constructed, for easy accessibility "pawn variables" <-> "widget variables". Have I got it right then?"
                        Yeah. To have direct access between those two, the pawn needs to do the Create Widget. If your Level for example creates the widget, the Pawn will not have a direct access to the Widget, thus you must first get the variable from the pawn to the level, and then pass it to the widget.
                        Im cutting some corners with this image but basically this:

                        Everyone can connect to Gamemode, so its a reliable place to store variables that are needed in UI, game progressions etc. The others who are not in the middle can also connect to anyone, but they dont have the knowledge of what others exists, beside the ones in the middle. For example, if you are using an runtime constructed actor, lets say "Enemy" to store variable you want to display on UI widget, the the "Enemy" can create that UI widget and pass the variable changes to it. But if another actor, "Health Pack", also wants to alter the UI widget? It doesnt know that the UI widget exists, and to send health upgrade information, you will need to juggle information casting here and there, making things overly complicated.

                        And last, how would I access variables in this widget from the pawn, do I still need to cast, and if so, I'll cast with that widget variable created with blueprint in the constructor, right?
                        If the variable TEXT is stored in the widget blueprint, the pawn can access it after creating the widget. You dont need to do another casting, once creating the widget and promoting that to a reference, that reference has access to everything within the Widget. Just pull a line from it and SET TEXT should be available.

                        But dont be afraid of storing variables that are used for cross-communication into GameMode/GameInstance/MyCharacter. If you have one focused storage for those instead of of everything being scattered around, you will get much less headaches. My actors only have variables that they never need to share with anyone anyway, and are used only for their own logic. Everything that needs to interact with others is better be stored somewhere where everyone has an access to.

                        Comment


                          #13
                          Thanks. I ended up using variables in the pawn. Easy access is key. Also learning the possibilities with promote to variable was important

                          Comment

                          Working...
                          X