REINST references bug still exists in 4.8.3

Using 4.8.3, Blueprint-only project.

We currently have a problem with one one particular component referenced in 4 other classes (PlayerController, AIController, HUD and another component). Whenever we edit the CombatComponent Blueprint (adjusting any of its functions), its references in all these other classes are replaced by REINST references, e.g. “REINST CombatComponent C 326 Reference”, which are not compatible with the normal reference and need to be cleaned up manually.

I’ve read that this happens because of circular dependencies, so I’m going to refactor the code to see if this helps. Still, I figured you need to know about this persistent bug.

Hi ,

Does this occur in a clean, blank project with no additional content? Do you have any steps I can take to reproduce this on my end?

Okay, I’ve tidied up my Blueprint connections and now the ReferenceViewer no longer shows any circular dependencies:

The CombatComponent is a component of the LP_Character which implements the DestructibleInterface.
I’ve already moved part of the code in the LP_Controller into the LP_Character Blueprint, so the CombatComponent is directly accessed by fewer classes.

And still wires connecting the CombatComponent with other objects get lost if I modify existing function input/output parameters in the CombatComponent (or add a new function):

  1. Add an output value to an existing function
  2. Refresh any node using the function in question
  3. Save and compile
  4. Press Play

This results in the following pop-up:

54626-combatcomponent_unresolvedcompilererrors.png

If I have a look at the HUD Blueprint, the wires are once again removed…

… and the reference is described as “REINST”

54628-combatcomponent_reinst_reference.png

Any other ideas?

According to the Reference Viewer, the HUD class itself is only referenced by the GameMode Blueprint.

While I could move a lot of the behavior into the LP_Character itself, the reason we split the class into several Blueprints (using Components) was to reduce the headaches resulting from Blueprints not being mergable, so several people can work on different aspects character code at the same time.

I haven’t seen this before our project, while still very small, reached a minimum of complexity. I’ve played around with several dozen test projects (for various tutorials and experiments) and I’ve never seen this behavior.

I just want to make sure I understand specifically what is occurring.

Creating a component that is referenced by a blueprint creates a REINST error if any functionality within the blueprint component is altered and the blueprint calling the component is compiled.

Does this sound about right? If you compile the blueprint calling the component immediately after changing the component, does the error get removed?

Creating a component that is referenced by a blueprint creates a REINST error if any functionality within the blueprint component is altered and the blueprint calling the component is compiled.

Pretty much, yes. It doesn’t happen with all components, just with this specific one so far. I also don’t think it’s any functionality but any change that requires other blueprints to be recompiled.

If you compile the blueprint calling the component immediately after changing the component, does the error get removed?

As soon as the component is compiled (with changes), all referencing blueprints are marked as changed and requiring a save. If I attempt to compile the referencing blueprint, I get a compiler error because of the missing wires. I then am unable to reconnect the wires until I force “refresh all nodes”.

I’m not entirely sure what you mean. I’d assume that as long as I don’t compile my changes, the other blueprints don’t know about it… I haven’t specifically tried that, though.

Thanks for looking into this!

Do you have a sample project that this is occurring in I can take a look at? I’d be happy to see if I can find what is causing this to occur. What I’ve been seeing on my end is that the REINST error does appear, but as soon as I compile the blueprint the error occurs in it returns to normal.

Company policy doesn’t allow me to post it anywhere public. Is there any way I can get the project to you? (It’s still rather small right now and I’ll try to chop off bits that aren’t necessary for the reproduction.)

You can send it to me privately on the forums via a private message to protect your assets.

If you compile the blueprint calling the component immediately after changing the component, does the error get removed?

Ah. Now I understand what you mean. I think it might. I’ve been unable to reproduce the REINST bug in an earlier version of the project where we constantly had the problem. I can’t be entirely certain the problem persisted after recompiling the blueprint.

However, yesterday I got a reliable reproduction in a smaller project built on one of the template projects, and yes, compiling always removed the REINST warning, allowing me to reconnect the wires. It sounds like you got this far on your own, but if you still need it, I could upload the template project.

The real question is why all nodes accessing an attribute in the component (such as the SaveGame or HUD blueprints) lose their wires when an entirely different part of the component (an unrelated function’s output parameter) is added or removed.

A project with reproduction steps would still be helpful in determining what is occurring. Thank you!

I’ve managed to reproduce the bug in a small project using UE 4.8.2 on Windows 7.

It only appears to happen if I compile the referencing blueprints in the wrong order. I think what happens is the following: Changing the component changes all its owning actors. Any other blueprint accessing the component by way of its owner will then be unable to access the variable. This makes sense, but is really confusing.

I’ve extended the Third Person Blueprint template. The new and modified assets are uploaded here:

http://www.filedropper.com/reinstbugreproductionassets

If copying the assets doesn’t work, the entire project (22 MB) is here:

http://www.filedropper.com/reinstbugproject

Here’s what I did:

Setup the project

  1. Create a new Third Person Blueprint project
  2. Create a new ActorComponent blueprint
  3. Add a few variables and functions to the component
  4. Add the new component to the ThirdPersonCharacter
  5. Add events to the ThirdPersonCharacter event graph calling the functions
  6. Create a new HUD blueprint
  7. In the HUD EventTick, query the component variables

Again, the new (CombatComponent, MyHUD) and changed Blueprints (ThirdPersonCharacter, ThirdPersonGameMode) can be downloaded from the first link above.

Step 4 above might not be necessary. I only ever had problems with the HUD.

Steps to reproduce

  1. In the component, add a new function
  2. Save and compile
  3. Play the game: You’ll get a popup about compiler errors in the referencing blueprints
  4. Open the MyHUD blueprint
  5. Note how the component reference is disconnected from the variable getters
  6. Hover the component reference to see the REINST error
  7. Compile the blueprint → REINST errors still there
  8. Refresh All nodes → REINST errors still there
  9. Compile the ThirdPersonCharacter blueprint → The REINST errors in the MyHUD blueprint are gone!

This doesn’t always show the same results. You might have to try adding/deleting those dummy functions repeatedly.

I just want to add, that I’m suffering the same issue.

I have an Human class which inheritances from ACharacter. This Human class has multiple actor components. Furthermore it has two child classes, a Player and an AI class.

Some actor components are holding a reference to the owner (Human class).

I’m accessing the actor components where ever I need them (in Human/Player/Ai and Anim Blueprint), but if I change something in an actor component and recompile, I get the REINST error. Also the connection between the actor component theirs variables are cut and I can’t reconnect them.

Only thing I can do is closing the editor and hoping that it is fixed after a restart. Sometimes it does, sometimes not.

Hi everyone,

I was able to reproduce this error and have entered a bug report, UE-20317, to be assessed by the development staff.