Create blueprint containing function
that returns a value (boolean works).
Create child-blueprint. Override
function in child blueprint.
Disconnect Execution pin from exit
node.
Compile
Selecting the error message focuses the entry node.
The error message reads: “Cannot override ‘parentBlueprintName::functionName’ at functionName which was declared in a parent with a different signature”
This had me recreate functions a few times. I just forgot to reconnect the exit nodes execution pin after reorganizing some nodes and the error message made me focus on the entry node.
I’ve tested it a few times, and I was able to get the error message that you are experiencing. However, this is working as intended. If you fail to connect the function to the return node, then it will prompt this error message to appear. It needs to be connected to the return node in order to compile without error.
In the first case, where the blueprint is being overridden, the error message is telling you that you cannot override the function, and when you double-click on it, it is just taking you to that function.
In the second case, the error message is different because the function is not being overridden, so it takes you to the return node of the function because that is where the error is occurring.
Both of these error messages are appearing based on changes that you’ve made to your blueprints, and are working as intended.
But the reason you cannot override is not because of a mismatch. Entry and exit points match perfectly. The reason is that the function itself is broken. The exact reason is that the exit node is not connected.
So all debugging information are lost when overriding functions? That’s an even bigger problem than I imagined.
Ok, so that might have sounded a bit wrong (i’m not too fluent in english). Let me rephrase that:
The error is found → no problem there
An error message is displayed → no problem there
However, the actual problem is within the function. Why display that the function is broken but not WHY it is broken? I am pretty sure that the problem has been found, just not displayed.
We do not have to argue about this if you think it has to be this way.
Just for the sake of correctness: A nullpointer exception is a bad analogy. Not only does the child function exist in this case (so not a broken pointer), the compiler also tells you that it’s a nullpointer exception (the exact problem). In this case the error message states that the child function does not match it’s parent. That is not correct, it does. The child function, however, is broken (visual studio, to keep your example, would point me to where my class/function has a problem).
This is not a runtime error. This happens during compile time. Debugging information during compile time are (normally) rather accurate (including most cases I came across in the editor).
I can understand your concern, however, the debugging information displayed is just informing you that there is a problem with the parent function. Unfortunately, this information will not point you to exactly what the error is, it will just give you a general location of where you can find the error.
A good example of debugging information would be in Visual Studio. If you create a null pointer, and then a hundred lines later or so you attempt to use that null pointer, the debugger will point you to the use of the pointer, not the declaration, even though the issue lies in the declaration. Debugging information is not necessarily supposed to be specific, it is just supposed to inform you of a potential problem with your code/blueprint.
The error is that the parent function is returning a value (a bool) while the child function does not(void). In terms of code the parent function would be written as “bool TestFunction()” and the child function, when the return is not connected, would be written as “void TestFunction()”. This is why the error being reported says that the function does not match the parent which is what is confusing the compiler.
I managed to fix this.
Double click on the interface on the left side to add it to the event graph
Then I searched in the event graph for the same event as the interface
After compiling, the errors were fixed, steps shown below:
Also I needed a third step.
Delete the ones from the interface if they are still on the event graph, they re-add them onto the event graph manually by searching them. I needed one for each error I had and it fixed it.
to anyone else who encounters this with an inherited blueprint inteface from a parent blueprint. I found a workaround by adding the function or event to the event graph of the parent blueprint, compiling the parent, from there the child blueprint seems to compile just fine.
The event that was just added in the parent blueprint cound then be deleted after it starts working in the child blueprint
