Custom Events vs Functions

Besides functions being able to return variables, are there any reasons to use a function over a custom event?

Debug, local variables, always fresh(same as local variables, dont need to reopen all gates and stuff), blueprint editor performance (on low end pc), if overwritten function in child blueprint has return it dock into function list instead of event graph, which is basically x2 every previous point.

Those are some good points! What do you mean by debugging? What differences are there in that aspect?

efficiency, small stuff easier to debug

Custom events can be replicated in specific ways, so I use them for running functions that are required to replicate. For example, health regeneration is a function that is run by a custom event on a timer, set to run on the server. You can’t specifically tell a function to replicate. As mentioned above, functions are clean every time you run them. Functions also help to make your event graph look cleaner.

1 Like

Indeed, I loved to use interfaces, events and dispatchers. But recently I start to see that functions are best whatever they can be used. Those other things are specialized and best used only in cases where they shine.

For eg no point in using interface when you put them only in single blueprint class.Easier is to get all objects of class, well easier while developing. As any change to interface can royaly mess project. I had this happened yesterday, after updating interface (we needed one more variable) some nodes of that interface were updated, but some had old functionality. We ended with creating new interface and replacing old everywhere. Editor also does not help with searching those broken nodes. BTW. search in blueprints may be reason I drop that stuff in favor of C++.

So events are great with dispatchers only, i see no reason to make custom event and use it in single graph, well nothing besides readability, but that can be done with functions or macros.
With dispatchers they are great when one needs send to many different actors. Sending to many actors of same class, you use get all actors of class and call function. Sending to many actors of more than 1 class you use interfaces.

But interfaces and dispatchers make troubles when you try to change arguments.

Ps. never use timers, they are worst kind they reference by text name, you change name of timer then have fun finding all nodes that worked with it. Also only one time i had android app crash was when i tried unreal with timers.

timers is timelines?

If I’m not mistaken, Timers can be also referenced by handles instead of names.

But not everything you need d owith timers can be done by references. Or maybe i am wrong here, maybe epic improved this since 4.4 when i gave up on timers.

I found this much easier to maintain than bunch of timers:
Dispatcher in some of globally accessible blueprint like player controller, game state, that fires every 0.2 game second. And some integer counter in that dispatcher. Now everything can fire up nicely, and i did not found task that i need more than .2sec precision for game. This way if i want faster (or slower ticks)
i just change delay for firing up dispatcher.

Timers are nice way to do fire and forget tasks, but i had those strange crashes when using timers.

timers is a component
l26zW.png
so its a lot better than any hacks which u used before, since you have absolute control over them.