Download

Referencing Variables - Accessed None... - Please Explain

image

Same ‘none’ error, which as i understand it is expected since its ‘empty’. (not that my understanding is worth anything at this point).

Ok, so you can only make this call while team select ref is assigned to something.

Let me put it another way.

If you have an integer variable, you can always use it. If you didn’t spend the time getting it ready, it’s gonna have 0 in it. You have to do stuff with the variable, otherwise you might as well not have it.

If you have a reference to an X thing, you have to say WHICH X thing you mean before you can do stuff to it. YOU know you only have one widget of type X, but the system doesn’t know that, as far as it’s concerned, you could have 14,000. So you have to say WHICH X you’re talking about.

Then, you can process it.

Sometimes, you might need to cast to do this, but very often not. You just have to say which X this reference is pointing at.

You do this, by taking the reference that’s always returned when ever you create anything, and putting it in the variable.

Is it making sense? :slight_smile:

Seems like a catch 22.

In the sequence of events, TeamSelect widget is created which then calls a function in CharacterProfile widget to create a button (widget).

So, when the OnClicked event is triggtered in the button (widget), which is a child of the CharacterProfile widget (i think), it needs to reference the TeamSelect widget.

I understand I need to tell it which TeamSelect widget to use in the REF, but I dont know how.

The TeamSelect widget is created outside of it (the CharacterProfile widget) so the only place I could assign (SET) the REF would be in the TeamSelect widget… except… it would need to REF the CharacterProfile widget to set the REF back to the TeamSelect widget. Sigh… even typing this is confusing.

I am fully aware I need to SET the REF, i just dont see a way to do it.

Further more, I need to call a Custom Event from the CharacterProfile widget to further manipulate the TeamSelect widget, but because the REF is empty, it says it cant find the function.

edit: i should add that creating the TeamSelect widget is in the graph of the Map and is triggered by the F key currently.

Ok, sorry, so it sounds like a widget nightmare.

I think you might need to reorganize your widget structure. I have no idea how.

You have either watched too many youtube tuuts, or not enough :slight_smile:

Bear in mind, you don’t have to make all your widgets separately, if they are all part of the same thing. You can just do the whole thing ( buttons, menus etc ) in one widget. It’s just that separating widgets is meant to give you reusable parts, but it’s not necessary.

If you want to carry on with your current structure, you can always stash variables ( references ) in a common area, like the game instance or game mode ( as you seem to be ).

These are just common areas you can put variables in that are difficult to pass around.

In this case you will need a reference to this area ( game instance or mode ) handy, and you will need to cast you your game mode, because that’s the one the has the variables in it.

Are lights coming on?..

While putting the VAR in GameMode did the trick, because GameMode is easy to SET, i still find myself in the need of creating a REF to a widget, inside a widget.

However, your idea of combining the widgets is something I had considered as a solution, basically instead of calling a function in another widget to make the buttons, then feed those buttons back into the first widget, do it inside of the first widget. The problem there is … well… i guess i could program the entirety of the button via code without the need to make it in designer.

It would solve a lot of problems with this REF nightmare, assuming I can figure out how to translate what i created in designer into graph.

Its just frustrating because it seems like a no brainer… i create a variable with a reference directly to the widget, how does it not know what im trying to reference. Maybe its because you can create childs of it or something?

In the REF VAR details there is a place set the default value, but i cant seem to put anything there.

But yes, in general I understand that a REF has to have a value that has to be SET somewhere. How do I set a REF to a widget A inside widget B, no clue. Cant cast to it, no object to plug into the cast box.

Ill work on trying to figure out how to create buttons dynamically inside of the TeamSelect widget

I’m not a widget expert, I find the whole system a bit cumbersome.

But if widget A made B, you can use ‘get parent’ inside B to get a ref to A. In this case you may well have to cast that to your A widget type.

Imagine there are 10 widgets. How are you going to tell the editor which one of the 10 you meant? You’re banging your head against the very core of OOP. The editor is waiting for the instance you want to test with casting but you’re not sure yourself what is the object. How can the editor know?


How do I set a REF to a widget A inside widget B, no clue.

Many, many ways - all depends on the scenario at hand. There may not even be a need to create a hard reference in the first place (event dispatchers) but, perhaps, if one widget needs to reference another, dynamically created one, it could be as easy as:

From now on, you do not need to create / destroy that widget. You can show / hide instead. But I might be missing the point of what you’re trying to accomplish.


you can use ‘get parent’ inside B to get a ref to A.

This may sound tempting but that would not work. Rather than returning the reference to the outer root of the user widget, it will return to most direct container - whatever is housing that widget. You’ll get the parent’s horizontal box / border, rather than the parent. You’d need to travel all the way uuuupp the hierarchy to get the root.


We need more functionality exposed to BPs :expressionless: This exists in Slate.

2 Likes

I know this hss been marked as resolved… just wanted to add this: Quick Dev Tip #57 UE4 / UE5 - Breakpoint On Error - YouTube

2 Likes

That example you show to SET after CREATE works when your doing the CREATE part, but if your trying to reference that Widget long after its created, from another widget or BP, then one. The CREATE function doesnt apply then, and the CAST function requires an object, which in the case of Widgets, there doesnt appear one to plug in.

I completely understand I need to tell it what Widget, but outside of the CREATE function, this doesnt appear to be possible.

The work around in my scenario, was to move all the VAR to Game Mode which works fine. Im not fond of it for memory resource management reasons, but it works.

It’s just refencing. No workarounds are necessary here. Keep references in variables, access them later.

The CREATE function doesnt apply then,

Use the reference that you had set.


If in doubt, consider explaining the setup needed, as in:

  • I create 2 widgets in the player controller
  • I need a 3rd widget that I create in the Game Mode to access the 2 widgets from the PC

Currently, it’s unclear what goes where.

There are 3 communication methods in UE4:

  • direct comms
  • event dispatchers
  • interface

Each serves a different purpose.


You keep saying you’re unhppy with memory management but that makes little sense in the grand scheme of things. What exactly are you going to do with the memory the pointer occupies? Because the massive class is loaded all the same…

So, the only place I can SET the REF (to a widget) is in the BP that creates the widget. Agreed?

From other BP i cant CAST to the widget BP in question because there is no associated object, which means I cant use CAST to SET the REF.

Now, maybe from the BP that creates the widget, could SET a REF in another BP, then call that REF from the BP that needs it. Like… chain referencing lol.

I think the real solution here might be an Interface; im looking more into those. That said, moving the variable to GameMode did the trick for now.

================

Currently GameMode contains the graph that creates the TeamSelect widget.

The TeamSelect widget in turn contains the graph that loads all of the characters into the window by executing a function in the CharacterProfile widget that generates a button and variables for each character, then returns them one by one to the TeamSelect widget to load into the selection bar.

Originally the TeamSelect widget had a VAR to keep track of the number of selected characters, and its this VAR that I was trying to reference from the CharacterProfile widget. I couldnt put it in the CharacterProfile widget because 100 button instances are being created, so the count var would always be 1.

I moved that count var to the GameMode which solved the problem.

Yes. But creating hard references is not necessary and not even a good idea (depends on the use scenario). You could create a widget, hook it up to a dispatcher and forget about it. Since we did not create a hard reference, when the widget is destroyed, the garbage collection will scoop it after a while. And you will never access none because dispatchers care not about such things.

From other BP i cant CAST to the widget BP in question because there is no associated object, which means I cant use CAST to SET the REF.

The editor needs an instance you wish to cast to. Casting is a test, not a method of communication.

Now, maybe from the BP that creates the widget, could SET a REF in another BP, then call that REF from the BP that needs it. Like… chain referencing lol.

Yup, now we’re talking blueprints. It’s the core of OOP. Luckily for you, circular dependencies are thing of the past in 4.27. Nothing wrong with treating a Game Mode as a communication hub (unless it’s multiplayer).

I think the real solution here might be an Interface; im looking more into those. That said, moving the variable to GameMode did the trick for now.

You will still need an object, you will simply not need to cast, though.

As a rule of thumb. Keep the game logic out of the widgets. Do the key tasks in the actors, global stuff everyone needs to access can be kept in the framework classes (game mode, player controller, game instance even, and so on). Widgets are supposed to show stuff rather than do the heavy lifting.

I couldnt put it in the CharacterProfile widget because 100 button instances are being created, so the count var would always be 1.

That’s where the idea of managers comes from. You need an outsider to keep things in check. Game Mode can serve as one. Or you can have an actor dedicated to creating characters and keeping track of them. The game mode needs just a reference. Once the characters are created, that managing actors can be destroyed, freeing the necessary resources.

It’s a good idea to encapsulate logic in managing actors as the framework classes will eventually grow exponentially in scope anyway…

I dont know enough about Interfaces or Dispatchers yet to feel comfortable trying to use it for this, but what little I do know, either or does seem to be the ultimate solution if I later on decide to move that VAR back to the TeamSelect widget to free up the GameMode.

FWIW: the reason I dont want the VAR on GameMode is because the ONLY time ill ever need that data is when the TeamSelect widget is active. Once battle has started, or any of the other features are running, having access to that VAR wont be required. That said, its a tiny bit of data, literally a single integer, so im making a mountain out of a molehill.

I see your point, except when the Widget is loaded there are zero actors, just a blank/dark space behind the pretty pictures. I suppose the player controller could be used for this. Ive never done game design, or app design period, so im trying to be pro-active about resource consumption, maybe overly so.

I get it. It’s an itch that things could be optimised better. Do have a look at the bit above regarding the managers.

Another rule of thumb is. Develop it now, optimise later.

Otherwise, nothing ever gets done in a timely fashion.

Agreed. I lost over a day figuring this out and being stubborn about putting the VAR in GameMode. :slight_smile:

1 Like

Folks obsess about a couple of variables and then slap 4k textures on everything. :wink:

1 Like