Macros, Functions and Custom Events

(background programmer for the last 20+ years from Assemblers to C#)

Ok maybe I am being a bit slow but I am unsure about a these things but why would I use a Functions vs a custom event. As far as I can tell unless I am doing an RPC(network call) I should use a function instead of custom event. My reasoning is that if I create a custom event it will not be called unless I use an event that has a tick or is called so my event can be called. if thats the case why would I make a custom event when I could just put all that code in the event that calls my custom event instead.

As for Macros I am guess they are way to make your visual code look cleaner as all the macros that you use will be replaced by the actual nodes. This is similar to a way a constants are used, 1) they give you one place to fix/change the code if needed 2) make the code more readable.

am I correct or are the more an exciting ways this old fool is not seeing in the visual scripting (pun intended)


Take a look at this article from Epic Games:

The main reason to use Custom Events rather than Functions is when you need to use Latent Actions and Timelines, because Functions doesn’t allow them.

  1. Use **Functions **in BP the same way you would use it in coding
  2. Use Macro Libraries as a set of lightweight static utility functions, which you would like to use not in particular class, but more widely.
  3. Use local Macros for “visual clean” Blueprint

Thanks for the info - cookies for all!!!

To me, custom events is a touch of genius. I seriously don’t know how much iterations or design meetings they’ve put efforts into it. But it is almost as if Epic deliberately can’t wait to teach old and new generation of programmers how things should work in current multi-core/proc era.

In a much simplified sense(from my understanding, Epic guys feel free to correct me if I’m wrong), events like it’s name are starting point of any independent tasks in a task queue system, that’s why it was given Red color(most easily spotted even zoom out of graph). And call event node will have no return values, which means you can’t and not allowed to depend on this event call’s result, you fire it and it will do it’s thing, just wait and profit. In programmer’s term, events are like a generic thread wrapper that you feed a function that do not have return value and fire it off without waiting it to complete.

If you follow this design and manage your graph with events, you are training yourself to think and parallelize your tasks in blueprint. Which will later on translate to much easier C++ implementation because you already break down tasks into non-dependent, can execute out-of-order things that are self contained. It is true you can still use the system badly and results in poorly performed blueprints, but like any other programming language, you have to teach programmer with syntax and design limitations.

@PenguinTD: This!

Also that is one of reasons I started with blueprints. It is easier and faster to learn from them. Blueprints are great.

@PenguinTD - Very well put. Being an old programmers I often fall into the habit top down programming structure with loops vs Object Oriented vs Multi Threads. your post hit me right between the eyes that I was once again think linear. Thanks

@Nawrot You are so correct I am very much enjoying blueprints as my friends are not so much code junkies like me. As I create scripts, Blueprints makes it very clear what is happening.

Well said PenguinTD!