Blueprint override function creates event

Overriding a function creates an Event instead of making a new function - Community & Industry Discussion - Unreal Engine Forums - basicily this, there’s a workaround, which works, but this bug is pretty anoying, could you please add it to bug tracker?

Thank you in advance.

Hi normal_ST,

I’ve attempted to reproduce this on my end following the steps listed in the linked post, however thus far I have been unsuccessful in doing so. I don’t see any indication that the function becomes an event instead of a function. Do you have any steps I can take to reproduce this on my end in a clean, blank project with no additional content?

Sure thing.

Blank project, 4.12.5 engine version.

Reproduce steps:

  1. Create blueprint let’s call it ‘ParentBlueprint’

  2. Create child blueprint from ‘ParentBlueprint’ with default name ‘ParentBlueprint_Child’

  3. Create a function in ‘ParentBlueprint’, with again, default name: ‘NewFunction_0’, compile ‘ParentBlueprint’

  4. Override ‘NewFunction_0’ in ‘ParentBlueprint_Child’, and we have a ‘NewFunction_0’ event in our child blueprint.

That’s pretty much it, and just for the sake of it, if you will create a return node in ‘NewFunction_0’(in parent blueprint) with boolean to return(or any object to return), then in child blueprint it will create function on “override function”.

Ah, I see what you are referring to. This is expected behavior. The function that becomes an event is because there is no return value. Functions and events are, in most ways, the same. Both can be called from other blueprints when needed and function in the same way. The difference is that functions can have a return value, where events can not.

+1 to this issue. Some other complaints with this unexpected behavior:

  • It does not reflect what I am doing.

  • The overridden function does not show
    up in the Functions list in the child
    object, but in the EventGraph tree.
    It does show as a function in the
    parent BP.

  • It places the ‘code’ on the main
    graph instead of a function, so among
    other things, I can’t create local
    variables.

We recently bumped into this. What about local variable scopes? Aren’t those unavailable in an Event?

Hi thagberg,

You are correct that you cannot include local variables when defining an event’s execution in the Event Graph. There are a couple ways to get around this, though.

First, you could add an unused bool return value to the parent’s function. This would give you a function graph with local scope when you override it in the child Blueprint.

Second, you could use a helper function in the child Blueprint that is called from the overridden function’s event node. This helper function would then allow you to have local scope for any variables that may be needed, while the event node that is calling it overrides the parent’s version of the function.

Tim

It’s worth noting that although “functions and events are, in most ways, the same” I can see a few problems introduced in practice:

  • Local variables cannot be used if an overridden function does not return a value. You can use blueprint member variables, but it pollutes the member list.
  • Events overriding functions can only exist on the main EventGraph. You cannot create a second event graph and copy/paste the event there, or attempt to override the function by name from a secondary event graph. Ultimately this will lead to bloat in the main event graph of a blueprint that has lots of overridden functions.

As you say, it’s possible to call a helper function in the derived class but in practice this starts to get messy. The person writing the base class chooses a sensible name for their function, expecting it to be overridden. e.g.

BaseBP::ResetAll()

The person overriding then overrides that function with:

DerivedBP::ResetAll()

Then they have to write a helper function that actually encapsulates the thing they want. At least that way there’s only one extra call… (plus the call to Parent::ResetAll()).

DerivedBP::ActuallyResetAll()

I could still see this getting unwieldly in the face of many overridden functions since there’s no concept of private functions. An external party using the blueprint would have to check it to compare the difference between ResetAll() and ActuallyResetAll().

Hi Gareth,

Sorry for not getting back to you sooner. I agree that this is a somewhat clunky workflow. Unfortunately this is unlikely to change since it could have a significant negative impact on existing projects.

As I mentioned previously, there are a few ways to work around this, some of which are possibly better than others, and I recently learned that you can also make the function in the parent Blueprint const, and that will also give you a Blueprint function when you override it in the child Blueprint.

Tim