In my scenario, I have a widget that is being used as a list item. Another widget is responsible for confirming that this list needs a new item to fill the slot. The form takes details from an actor in the world and custom details input by the user.
currently I’m using casting while I mock up the functionality of everything. So it goes like this:
Spawn object in the world >
Object generates a unique ID on spawn then sends data to game instance >
After spawn it also enables and opens a widget (form) which retrieves the UID of this specific actor from the game instance using a get last index function and the user then fills in more details about the actor in the form >
On save form it then creates a list item in my main HUD widget which holds the list box. The list item itself is its own widget which has functionality to select the actor, hide the actor, delete the actor associated with the UID.
So without casting or using interface (as I am forced to use a ‘get all’ node) what is the most effective or industry standard way to achieve this communication please?
Just to clarify, even if I use event dispatchers I still need to cast/ get all type function don’t I?
This is more like what I was thinking. Can you maybe explain how this works please. Do I create this delegate BP which contains all event dispatchers? Is this delegate BP then just placed in the world or something?
And I see in the widget there’s an interface receiving a message from the delegate BP, where it says ‘any widget’ what is that specifically? Is it a ‘get widget of class’ or something else?
You need a separate helper class for different delegate signatures.
Each helper has one event and one delegate.
No, every time you need to bind an event to a delegate, you need to create a new helper object that will allow you to pass a “reference to the delegate” through the interface.
This is a reference to a specific widget, but any class that (must) implement the helper delegate interface.
Are you worried about garbage collection? Until you do an unbind, nothing will happen to the object (I think). Therefore, there is nothing more to do with the reference.
I guess what I’m asking is after I make the delegate blueprint, where do I then put that blueprint object so I can use it? Or do I just leave it after creation and I’m able to reference it somehow?
It needs to be created and used to pass through the interface when it is needed (when you want to bind to some delegate). Because for each separate bind - a new instance needs to be created, otherwise there will be confusion between calls.
Thanks, so I’m guessing in my widget I just create a variable and reference this delegate blueprint then? I’ll give it a go thank you
edit: No my mistake, I’m not creating a variable.
ok so looking at this what I’m doing is creating an interface and a delegate blueprint.
Then in the blueprint (the BP or widget I need to sent a message out to communicate) I use ‘construct BP’ and reference the delegate BP that has the recall event dispatch. Then send to the widget in question with an interface message to the interface I’ve put into my widget to trigger the event right?
Thank you, I’ll give this a shot in a test project and learn how it’s supposed to work then implement it. It sounds much better than using hard references and casting for everything
This is amazing by the sounds of it, it’s just the non-replication that complicates thing since it says I can use RPC but I don’t know the implications of that. Soon it’ll need to be fully multiplayer so anything I do as a player and add on my list, is also replicated and others can see this list and add to it too.
First of. You are using dispachers and interfaces completely wrong if you have to cast.
Second of. Nothing wrong with casting per-se its ofc better if you directly IsValid instead, but a cast that fails sort of achieves the same purpose.
Third of.
I really think you should avoid whatever new trash they try and add.
Its a) trash. b) in development and c) going to change on you and break without notice…
I guess that’s probably right regarding the new tech. Every event dispatcher tutorial I’ve tried to learn from uses casting or ‘get all actors’ type functions to achieve the communication which I find weird. Can’t I just say:
widget A needs to sent a message to Widget B, so in widget B I have an event dispatch and in widget A I send a message to that dispatch. Or am I getting it backwards?
In such a direct case you make the top level UI that spawns the widgets keep track of the variables, and apply them to the widget.
Technically, you want to also reduce memory footprint, so it serves no ourpose having 5000 variable instances to the same value.
Practically - you actually void or make it hard to Artemony/cheatengine your variables if you have at least one or 2 “passes” that leave a copy.
But either way:
Something creates the widget and adds to screen.
That something stores the widget, then the next.
Then, if you pull from that stored reference and type the var you can set the var of that widget to the right amount.
For what you describe, this will work without complications.
Re the dispatchers.
The dispatcher is the one that sends.
Then the recevier handles the event.
Dispatcher should check “does x implement interface” before the call. So you limit casting.
The receiver implements the interface and just does what it needs. No casting needed as it works locally to itself.
