Compile Errors that after being fixed re-appear after restarting editor.,Compilation errors that re-appear when restarting engine

I have been getting a weird error in an unreal project recently, there are a number of compilation errors in various different blueprints that after being resolved they reappear after restarting the editor.
This issue has appeared recently in at least 5 different blueprints with varying behaviour but each having one feature in common that the issue will come back after restarting. Some of the errors have been fixed, but I have been unable to successfully replicate the fix for all affected blueprints.
I will outline the different instances of the error (I cannot remember the full details of some of the instances due to me fixing them a while ago and being unable to replicate them)

Instance 1 (and 2):

The first two instances are fairly identical - two blueprints that were similar (i.e shared some interfaces and had similar behaviour) would prevent me from using the play in editor function with the warning: “One or more blueprints have unresolved compiler errors, are you sure you want to Play in Editor” followed by the names of the two blueprints.
Upon opening these two blueprints the compile button has the error during compilation symbol and upon pressing compile, the blueprint would compile without error and everything would work when playing in editor. Until restarting when the issue came back

Instance 3:

After a short time of development (approx one day later) another blueprint (animation blueprint ABP_HeavyTurret) I had been working on came up with a similar error. The error appeared after changing an interface (I_TurretAnimation) that the ABP blueprint used.
The error appeared to be identical to the previous instances however upon more investigation the error mutated into a slightly different form.
When looking through the blueprint I noticed that the ABP_HeavyTurrets implementation of one of the functions from the I_TurretAnimation had lost its return pins - the interface defined two return pins (vector and rotator) however the ABP_HeavyTurret implementation of it had no return pins. This did not appear to stop the compile and would remain the same after compilation. I attempted to fix it by refreshing the node, the output pints then appeared as expected and all looked good and everything worked. Until restarting when the issue came back and the return node once again had no output pins.

I then decided to experiment a bit and after refreshing the node to get the return pins back I added a wire leading into the return pins (using make rotator and make vector and dragging a wire from their outputs into the return nodes pins) I then compiled, and everything works as expected until restarting when the issue came back - this time there was an error that did not go away when pressing compile - the return node had returned to its previous state of having no output pins and the two wires coming in were marked as errors as they were connected to nonexistent pins. I then decided to modify the interface I_TurretAnimation since this appeared to be central to the issue. I added a dummy function (called MagicFunctionThatFixesThings) to the interface, compiled and I never had an issue with the ABP_HeavyTurret again. This was the only instance of the bug I was able to completely fix without creating more issues elsewhere
Instance 4:

Again a short time later I was working on some blueprints, structs and interfaces (I modified a struct used in an interface that the affected blueprint implemented) and the issue spread to another blueprint - a blueprint (BP_BaseTurret) had a compilation error (that had not been there before closing the projectm this only appeared after opening the project agian)
This one actually had an error that required fixing before it would compile:

232453-instance4beforecompile.jpg

This was fixable by simply refreshing the two nodes and reconnecting the pins, and everything worked. Until restarting when the issue came back. The error itself appears in the implementation of the function Damage from an interface I_Damageable (this interface was an old one that was scheduled for removal, in a later attempt at a fix I replaced this with a newer interface to no avail)
The errors given were the following:

Can’t connect pins Damage and Damage Instance : Only exactly matching structures are considered compatible.
and
Can’t connect pins Damage Instance and Damage : Only exactly matching structures are considered compatible.
Upon hovering over the damage pin of the function input node it had the following popup:
Damage

Fallback Struct Structure

As I mentioned before, these errors were fixable by refreshing the node, reconnecting them and recompiling, and the errors re-appeared after restarting the editor.

Instance 5 (and a temporary 6, 7?):

This one appeared after attempting a fix for instance 4 - in the process I modified the interface it was using (adding another dummy function similar to when I fixed instance 3) and modified the struct the interface used (adding a new dummy variable)
This fixed instance one and two of the bug (???), however as well as not fixing instance 4 (BP_BaseTurret) it also broke the HealthSystem blueprint (which made use of the interface), and broke BP_PrototypeEnem and a blueprint TestEnemy. Out of these new broken blueprints only the TestEnemy blueprint seemed to be broken and upon restarting, instance 1 and 2 re-broke while BP_BaseTurret and TestEnemy remained broken while the other two blueprints suddenly resumed to normal.
The test enemy blueprint was fixable by refreshing the nodes, however broke again after a restart.

At one point while experimenting when instead of restarting I attempted to fix the errors:
All four were caused by the same function node (the damageable interfaces damage function input node, however the individual nodes had different issues:

232458-thefourerrorsoftheapocolypse.jpg

In cases 1, 2 and 4, the error given was:

In use pin Damage no longer exists on this node. Please refresh node or break links to remove pin.
and the damage struct pins that were unused upon hovering my mouse over them I got:
Damage

STRUCT REINST Damage Instance 0 Structure

To fix these errors I simply refreshed the nodes and rewired them as needed, then it compiled and ran the project in editor - it gave no errors and everything seemed to work (after fixing the other errors). However upon restarting, I got the first two original instances of the issue back, the fourth issue and the TestEnemy blueprint.

Conclusion

A number of different blueprints have had errors, with the reocouring them that after fixing the issues they would reappear after restarting. They seemed to be related to an interface (except instance 2 which was related to a different interface and is now working, but for a brief period of time had the same issue). Possibly it was triggered by changing an interface that was in use by another blueprint however in this case I would expect after refreshing the relevant blueprint nodes and saving the issue to remain resilved after re-opening the engine.
This issue is making it quite difficult to proceed with the project as for each broken blueprint I have to ‘fix’ them after launching the editor before I can test my project. This slows me down, and I am concerned about working with the blueprints due to the possibility of the issue spreading.

My project is using Version Control (GIT), I am able to revert to the different stages of development experimenting with different fixes, all to no avail. Here is a rough overview of the history of the issue (with branches being areas where I attempted two different fixes using git to revert back):

There is another developer also working on the project who also get the compile errors - whatever the cause of the error it is something that gets synced when using git so it would seem unlikely that it is anything to do with the local engine installation or anything in the intermediate/saved folders as they are added to our gitignore.
I still have some ideas of what to try to fix the error, but it seems clear there is a bug, as either the blueprints are broken and it falsely reports them as working after pressing compile, or the engine incorrectly saves/loads the blueprints so when restarting the error comes back.

Sorry for the long and rambling post, I wanted to include any relevant information I could think of.

2 Likes

Some more development: I have managed to modify the first two instances of the error such that it will not instantly fix itself on compile, and it then takes on the form of the other two issues - they all seem to be related to a single interface (other than the one that got fixed). Specifically a single return node of a struct DamageInstace. Something about the blueprint seems to be incorrectly linking to the interface, in such a way that refreshing the blueprint fixes it, and restarting the editor breaks it again.
EDIT: upon creating an identical copy of the struct used in the interface and then changing the interface to use the new struct (and fixing all the errors it caused as a direct result) I have managed to get it to fix all the errors with the DamageableInterface - however it seems the first two blueprints had another error as well that disappears on compile but reappears when restarting the editor - I then went through and striped out all the interfaces they were using until after one restart, suddenly no errors - so it appears to be an issue with interfaces, there have been three different interfaces that have caused this issue so far,

Another update: Deleting a cast node completely unrelated to the DamageInstance interface in one of the two broken blueprints fixed both of them. This while not ideal (adding the cast again broke things again, and it was a moderately important feature it was part of) did provide a solution for those two assets. The only one left was the BP_BaseTurret - this seemed to be related to the damage interface. I then renamed the interface and it seemed to fix it. I have finally got the project into a ‘working’ state, however one of the fixes was still less than ideal, and I still do now know how to avoid this issue reoccurring. This is the first time I have encountered this specific issue in the unreal engine, and I am concerned about the issue rearing its ugly head again - and that doesn’t change the fact that there was a seeming bug in the unreal engine.

Hello,

We’ve recently made a switch to a new bug reporting method using a more structured form. Please visit the link below for more details and report the issue using the new Bug Submission Form. Feel free to continue to use this thread for community discussion around the issue.

https://forums.unrealengine.com/unreal-engine/announcements-and-releases/1410408-unreal-engine-bug-submission-form

Thanks

Was there a final solution discovered, or a related issue entered in the new system that we could track for those of us having the same issue?

In terms of solution, I managed to fix the issue by renaming the struct related to the issue - somehow this fixed things, however probably will only work in some cases as previous instances of this issue did not involve a struct.
If you can find the node that is causing the error (sometimes it remains hidden and is impossible to find even when looking in compiler results) deleting it and remaking it and all incoming connections might work, or renaming any structs/interfaces that have the issue. Be careful though as it can make things worse so make sure to either backup everything or use Version control (git/perforce) before experimenting.
It seems to be an issue with unreal not updating other blueprints properly when you change an interface/struct.
Not aware of a related issue in the new system. If I get round to making a simple minimal repeatable instance of the bug I will then file a report with the new bug reporting system.

Yeah, I’ve been resorting to remaking the class. Thankfully it has been small.
There have been a number of BugFixes in the 4.18 release notes that could have fixed this issue as well, so this is probably low prioritiy for them.

Renaming the struct fixed it for me.
So I:

  1. Renamed
  2. Saved
  3. Restarted
  4. Tested - It was fine with renamed name
  5. Renamed to original
  6. Restarted
  7. Tested - It was fine with original name

Thanks kinloch

1 Like