So, this may be very generic to most, but I’m a bit confused. So I’m setting up a puzzle game with a very simple concept; you are to reach the other platform. Right now, I have levels made and most of what I want ready to go. Except for finishing the level. There is nothing that happens should you complete the level and this is mostly to do with one problem I’m having. I can set up a trigger value that when the player overlaps with it, it will provide an end-game screen, but also set some values so that in the level select screen, an integer is updated to show how many were completed out of the total levels as well as change the text of the level on the button to green to reflect that. The problem is that actor or level blueprints don’t share or directly communicate with a widget blueprint so I don’t know how to trigger things like that and even running custom events that an execute console command doesn’t seem to work the way I intend.
I know there’s event dispatchers, but I have no idea how to hook those up since I haven’t used event dispatchers and I thought about setting up functions or macros, but those are locked into one blueprint and still don’t get variables set by another blueprint, or if they can, I don’t know how to set that up.
Basically, when the player completes a level, the end-game ui pops up, 1 is added to an integer which will be called later, and a boolean value is set to true. Then in the level select screen, the next time it is created, the integer will be called showing how many levels have been completed and the boolean value is connected to a branch that if true, will execute a colour and opacity node that changes the text colour to green.
I haven’t added screenshots because I’m not sure where you guys would like to start if you were setting this up, but even your own screenshots on how you hooked up similar events would help.
Event dispatchers are useful in situations where one actor needs to send out a message to any other actors who are listening that says “Hey, guys! Over here! This thing just happened that you were waiting for to happen!”. I could see this being somewhat useful in your situation, but I think there are likely other cleaner ways around it.
Typically in a widget, you have items bound to variables. These variables can be within or outside of the widget itself, so long as those variables are public. Here is an example of a HUD widget from an old project I dug up of what the drop-down looks like for creating bindings.
You can see here that clicking “Bind” will give you the drop-down menu which allows you to either Create Binding, which creates a function that can be used to drive this particular piece of the widget OR you can auto-bind it to a variable from a sub-object property (class). Here, I don’t have any public variables in my character class that have anything to do with color or opacity that could be bound, so it appears that it will not really do me much good to play with the sub-object properties. But you can also see I’ve got some functions already set up for driving the color and opacity of various bits of my HUD.
Digging a level deeper, here is a very simple example of driving a binding through a variable in another class. You can see my character class having its “CurrentSpellPower” variable (0>>1 float) accessed and returned to the progress bar for a Spell reset timer.
Alternatively, there are other times where more functionality is required - specifically, things that need to be programmed within the widget. In this case, I lean towards recommending setting up custom events within your widget and calling those when you need to do so. This is another example from that same widget, where once the player selects their weapon for the game it updates a couple images in the HUD and some colors for progress bars. All of it is based off of the WeaponSelected custom event, which is called way back over in one of our earliest blueprints that allows the player to pick their weapon. You’ll notice that the custom event here is carrying a Struct input/output with values being accessed on the BreakStruct node for the various image and color information needed.
(EDIT: Actually, I guess we ended up just hard-coding color information to 1/1/1/1 pure white for usability purposes, but you get the point… we COULD have accessed that from the Struct had we needed to.)
Hopefully this can sort of jumpstart the creative process of how you want to tackle the interactivity between the blueprint and widget that you need communicating with each other. Feel free to ask any questions
Well, it turns out that I did have a variable that it could read so I was starting to work with that with my original plan and doing away with the event dispatchers since they didn’t seem to be what I needed. I’ve included the screen shot of the variable being set by the trigger (finish line) which would then pull up the main menu ui. The second screenshot shows where the variable is being received. Strangely, even if this variable is set by the trigger, the ui doesn’t get the message some how and the colour doesn’t change, however, if I set the default variable to true, it changes the colour. This is where I’m thinking something isn’t being passed between the two. (I didn’t set a false to the branch because if the check is failed, then nothing changes with the widget and it just constructs as usual, but I don’t think that’s the issue)
I also tested using custom events, which was how I originally made the trigger. It would run a custom event and in the widget, that event would set the variable and it would get called with the same branch. Still wouldn’t change the colour until I changed the default value. Am I missing something here or is there some kind of information not being passed through the two?
Here is the variable being set by the trigger.
And this is the variable being retrieved by the widget. By the way, “SmiteLevel” is the name of the text instead of “BaseLevel”. Haven’t cleaned that up just yet.
I also used make slate colour since that was the only node that would come up and was compatable. For some reason, it was saying that “only exactly matching structures are considered compatable” so I was forced to use slate colour. So far, that isn’t an issue, and it’s more the boolean value not being set or read.
You aren’t seeing any change because the Boolean value in the widget (although named the same as that in the Trigger) is never being acted upon. It will always return whatever its default is set to the way you have it set up. You can’t define this value for this Widget before it’s Construct Event unless you’re storing it elsewhere (say, in the character BP) and then checking that here by casting or other methods of BP communication (custom events, event dispatchers, function(s), blueprint interface).
The long answer:
Involves a lot of arrays, saved game data, and widgets within widgets. Can elaborate if that’s what your project needs, but it’s easier for me to link you to relevant documentation…
Sorry for the late response. With school, I’ve taken a week off from my work. I likely need to set up a save game system anyway so whatever needs to be done can be done. I’m problably going to skip this system for a couple versions until I get it down solid anyway.
