I believe there are some nice design patterns that can be done in Blueprints if Blueprint Interfaces could support the passing of Events/Event Dispatchers. The biggest idea being that it can be useful to have an interface that expects a delegate to be called, but the implementation of calling that delegate could differ between concrete classes.
Designs with this pattern can already be achieved in C++ but Blueprints currently have no way of passing an event other than the one-off means of the Bind/Create Event nodes.
I don’t think interfaces should contain anything. They should be that, an interface and leave the implementation details to the class that implements the interface.
You should be using actor components instead of interfaces if you want events. Components have all the functionality of an interface:
Cast an actor to an interface-> get component by class
Call an interface function-> call a component function
Implement an interface function-> bind to a component event
Plus you have the bonus of being able write code and store variables within a component.
The only benefit a blueprint interface has over a component is that the interface can be implemented by a component. If anything, blueprint interfaces should be removed and replaced with the ability to add components to component blueprints within the editor.
How exactly are you achieving this in C++? If you implement the C++ defined interface with a blueprint, can that delegate then be assigned to or called in Blueprint?
Interfaces can be put on Actors and Components which is one of the reasons they’re needed. I also can avoid a deep and confusing inheritance chain using Interfaces.
And Allar is right, there needs to be a good way to define/bind events via interfaces.
There is a workaround, a listener pattern, though not as convenient as I would like, but still:
Create 2 interfaces, with one method each:
Listener: will have the required inputs to handle the desired event.
Messenger: will be implemented by the class that normally would be holding the dispatcher, and will accept the first interface as a parameter.
In my case, I needed to detect the touch end event in a widget class, even if it is not above the widget (there seems to be no easy way to accomplish this, as input events are accessible only to Actors/Pawns I forget which).
So I have the player pawn listen to touch events, and send it to the widget.
I don’t want to modify the Blueprint of the Widget every project, so I use interfaces for it instead.
This does still require a bit of wiring in every Pawn that implements this, but it’s very little, and can be used as the base class for player controlled pawns.