BP_Item has a function canCollect that evaluates its own state and return a bool value to enable / prevent Item collection
Now I want to evaluate an arbitrary number of states on different instances of BP_Item (Example: Item can only be collected when player has been to a different room and turned on the light). For this purpose, I added an event dispatcher on the item itself: canCollectHandler. This accepts the item as input and is supposedly defined in the level’s BP where all world state is available. This dispatcher is called only when configured to do so and is supposed to externalize the state evaluation.
Unfortunately, I cannot find a way to have this event dispatcher communicate a result back into the item, since it doesn’t have output args. Neither can I pass a boolean by reference, which would be at least a workaround…
Do you have any idea how this is best implemented? Something like delegates would be great, but without the multicast nature of events.
It is late (for me now) i could not make what your really want (probably because i am sleepy). However i try again tomorrow (in 10 or so hours).
And until then it is how i use dispatchers and how i do communication between blueprints:
Single to many:
dispatchers are used for situation when one needs to tell many about some variable
i create dispatcher in blueprint that can be easily found and is in single copy.
such blueprints are: game state, game mode, players hud, player character
so that blueprint of choice gets dispatcher, and sends some variable to everybody interested in it like for player HUD and telling all widgets that HP changed, or telling all lights that its night and they should turn on
Many to single:
i create event in same blueprint i made dispatcher
then i create function library, and in it function: GET_PlayerHUD, i usually add CORE so it would be: GET_CORE_PlayerHud (easier in blueprint to just write CORE and get all my functions that point to such blueprints). That function inside casts to proper hud class that i created. And returns casted to reference. And its PURE function, so no need for execute pin.
so any blueprint that wants to tell anything uses GET_CORE_whatever, and just calls proper EVENT there. And that event can send variables back to MIDDLE MAN blueprint
ps.
DO NOT USE level blueprint. It has one HUGE problem, it loads first and has Begin Play first (before anything else), so it is common and possible that get all actors of class returns nothing, then your game logic is time dependent and loading order dependent
Instead of game level put such logic in game state or game mode. And in level use actors that have their own logic in own bluepritns.
Also second HUGE problem of having code in level blueprint is that for any level you will create same logic, again and again. I have simple RTS with 20 or so very simple maps, doing same even simple logic in every level, then upgrading of fixing bug 20 times, is just nuts.
I just read it all, and you are trying to use dispatchers for something they are not designed for. So again read my yesterday evening post above. You need many talk to one setup for items. However it will require some array of their states (and state is best done as STRUCT). And for array they need integer index. And it should be unique for items.
For situation where ALL items are same class you just make event they all can call and use in one of CORE bluepritns, like game mode (best if game is not multiplayer).
However when items may be different classes. When you game BP_item that has all code for communication, then you make BP_apple as child class to parent class BP_Item (inheritance), then you make more new classes BP_Tool BP_rock BP_wood etc. So you can have many different item classes that should communicate in same way (and have it in BP_item parent class).
For such situation you create blueprint interfaces. Those let all your other classes that are not BP_Item or child classes of it, so everything else can CAST TO interface (that is common for items) instead of various child classes. Simplifies stuff.
ps.
In dispatchers you can add variable they send over to all items. Just click on dispatcher in details panel in blueprint it was declared. There you can add variables. However dispatchers can ONLY send or communicate one way. From blueprint it is declared to anything else that has code ASSIGNED its event to that dispatcher.
Input yes. Output no. It’s multicast, so the calling code would have to accumulate all the responses and somehow deal with them. In c++ there is a way to create delegates, which I think is what would be the way to go…
Each Item blueprint has its key and value.
You create Event in game mode blueprint that accepts key+Value and parameter.
Then you make map variable that uses key and value
Item triggers that event, sends over key+value, event stores that in map
So you have communication from many blueprints to single one place.
And you make dispatcher that sends key + value.
All item blueprints assign to it.
When dispatcher is triggered, blueprint item checks if has same key as in dispatcher,
and reacts to it
And what is left is some way to make keys that do not repeat.
