In a Level Blueprint, Can You Pass Actors Into a Macro?

Background
I have a series of sub-levels that each have unique placements for some actors, but are otherwise identical. Its basically 3 lights, 3 mesh-spawing blueprints, a camera, and a level sequence. Its an “end of match rewards” screen that shows you celebrating.

Because each of these levels needs to have the actors placed uniquely, I can’t just reference one sub-level and then move it’s placement in each parent Level by using the Level Details window. Each actor must have a unique placement, not just a shared relative offset.

This creates a sustainability problem because each level has the same blueprint logic. If it has to be changed, then I will have to make the exact same change in every single sublevel. So I decided to try a Macro Library instead. That way I can edit one blueprint function and each sub-level has the nodes injected at compile time, just like how the docs state (or so I thought).

The Crash
The Macro takes in references to the actors placed in the persistent level. The very first nodes in the macro are all “is valid” checks. The macro works fine in-editor, but immediately crashes with this exception in a cooked build:
“Exception thrown at 0x00000103375CFD3D in MyGame-XboxOne-Development.exe: 0xC0000005: Access violation reading location 0x0000000000000020.”

I tried using a Blueprint Function Library version of this instead. It also crashes. It DOES NOT crash if this code exists and runs in the level blueprint itself. This proves that the code is not the problem.

I dont understand how the macro version fails, though. Macros are explicitly described as placeholders for the actual nodes, which are added at compile time. Unless I am misunderstanding something, that is an incorrect description. This crash proves that extra limitations exist when using macros.
“A macro containing a node” does not equal “that same node in blueprint.”

So my question is:
Can you pass actors from a persistent level into a macro that is placed in that level’s blueprint? Or maybe, can you use macros in level blueprints at all?

And of course: why??

1 Like

Quick question: Why not move all that logic to a persistent object like Game Instance and avoid using the level blueprints?

This exactly, in new/next level you will code all that stuff again and reconnect all casts?

This ended up being a solution for me. Thank you for suggesting it. A coworker had made this in the level blueprint and I inherited this task, so I wrongly assumed that it needed to be in the level blueprint because there are direct references to persistent actors from the level. But I learned that you can add regular variables that reference an “object” of a specific class. Then, to set that reference, you place the blueprint actor in the level, select it, and in the details window you can see a dropdown of all compatible actors placed in the level for each variable.

I tried this and made a blueprint called “end of match manager” and put all the code in there, then placed him in each level. That has allowed me to maintain the code in 1 spot while it is used in many different levels.

However, the crash was still occurring. On a whim, I unhooked the “Get Sequence Start/End” nodes that references the end cinematic. Those were causing the access violation crash in cooked builds only, but in editor it was fine. So my crash is finally resolved. No idea why those caused a crash since the cinematic plays successfully in the same function call where those were causing the crash. But oh well! Thanks!