Nothing “rude” about that. Events are just a way of scripting specific to visual scripting tools like blueprints. The default of scripting anything is a function. Events and macros generally should be used only if there’s you can do with function, i.e. reacting on ComponentHit event - which could also call function.
Technically speaking - and that’s what matters most - functions are the cleanest way of scripting. Any kind of “subscribing until event finish” is a redundant and more complicated version of simply waiting on function’s return - which does work always, doesn’t matter if you’d place Return node in your blueprint or not.
And finally, 4.24 “fixed” the fundamental things about functions: specifying the level of access. Now every function can be:
- Public: available to call from any other class/blueprint
- Protected: only available to call from the class which defined that function + all child classes/blueprints
- Private: only available to call from the class which defined that function, inner logic of class that should be never accessed outside
The advantages of this should be clear, you can control access to the methods. It’s bread and butter of the Object Oriented Programming. This should work in blueprints since forever, as this is a fundamental thing…