Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

Howto fix: circular references

If I have an inventory variable in Mycharacter, and a HUD widget. Then the HUD needs to know about the players inventory and the player needs to know about the HUD in order to create it (among others). So they will both reference each other, or at least cast something to another like "CastToMyCharacter". This however creates a circular reference. In C++ that's fine (in this case) but for blueprints it seems to bug the engine pretty badly causing weird side-effects/bugs/crashes.

I tried event-dispatchers, interfaces, not using variables but only CastTo-nodes. But nothing helped. As soon as I either use a variable of the type MyCharacter in the HUD-widget (even if it's not set nor used) or if I use the node CastToMyCharacter, it will immediately count as a circular reference.

I could create a 3rd blueprint and put every single public variable in the game in here. That will solve it. But as you might imagine, that would be extremely and extremely hard to maintain and messy as well.

I also tried an event dispatcher in MyCharacter and only have it input a simple float-variable. No player reference. But sadly that won't work either because the HUD requires a reference back to player for the event to work... sigh... And the engine won't let me bind the HUD to the player, from within the player-blueprint (where I have a self-reference) either :/ alt text

What do I do?

Video of the compile loop: https://www.youtube.com/watch?v=fs6GQ3BZlGs&feature=youtu.be

Update: Also applies to non-UMG classes. It's not limited to widgets only.

I ask this question because of the response in this topic: https://answers.unrealengine.com/questions/185609/lots-of-bugs-need-help-with-short-video.html

Product Version: Not Selected
darn.png (121.0 kB)
more ▼

asked Mar 08 '15 at 11:41 AM in Blueprint Scripting

avatar image

595 92 104 155

avatar image Mortusnyte Mar 08 '15 at 04:10 PM

So your question is, how to communicate from your character blueprint to your HUD blueprint and vice versa?

avatar image Napoleonite Mar 08 '15 at 05:33 PM

Basically yes. I'd like to know how to do that without bugging the editor.

avatar image DG Gage Mar 08 '15 at 07:19 PM

Huh? I have a system that consistently communicates between player and UMG, player and player anim, and more. I use 4.6.1. I never experience bugs or any negative effects from it. It's quite stable as well. Circular references are my jam for quick processes.

Maybe my method can help you. What I do, for any BP communications, is establish those castings and store them as object variables ASAP. I use the player to add the widget, and immediately save the instance output as a variable. On Event Construct in the widget event graph, it immediately casts to the player and saves it as an object variable. All communications are made with those instanced object variables and it never messes up.

In fact, in all of my BPs, this is setup at the earliest possible moment. Any time there is a need for the player to communicate with some other BP, that relationship has been established earlier.

None of this may be news to you but I find it strange that it gives you any problems.

avatar image Napoleonite Mar 08 '15 at 07:35 PM

Saving them in variables was what I originally used to do as well. Epic also does it like that.

But I don't even know if these are the cause of the problem at all. I originally had another problem and a staff member asked me to make sure that I have no circular references. Then I found out that my entire project is filled with them but the Epic tutorials show us to implement it like that as well. Then I asked the question here separately. But it seems more and more that this is unavoidable, or even intended. And circular references should just work (in theory).

avatar image DG Gage Mar 08 '15 at 07:40 PM

Man I can't imagine just NEVER having them. My money is one some process setup being weird. Mind elaborating on your bugs, what systems are related, and how they're setup?

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

2 answers: sort voted first

The only variable that you need to create for this is a variable that will reference the HUD Blueprint inside MyCharacter Blueprint. After creating your HUD, create a new variable inside your MyCharacter. Select the variable's pin type under Variable Type and search for your HUD. In my case, my HUD was called First Person HUD so I chose that. At this point, you still need to fill this variable. To do this; Firstly, create a custom event in your MyCharacter, and add a new input to this event. This input's variable type will be your HUD again. From this custom event, Set the variable that you created earlier with the input value of your custom event. Then, inside of your HUD blueprint, cast to your MyCharacter (mine was called FirstPersonCharacter) using the Get Player Character as the the object. From the As MyCharacter return value, pull the custom event that you created earlier in your MyCharacter Blueprint. Now plug a reference to self in the in value. the result; your MyCharacter Blueprint has a reference to your HUD. And you can reference your MyCharacter from the HUD the same way we just did over and over again using the Get Player Character and Casting to your MyCharacter.

The images below will probably be easier to understand then all of this text. Take care!

The image below is from my HUD Blueprint called First Person HUD. alt text The Image below is from MyCharacter Blueprint called FirstPersonCharacter.

alt text

hud.png (106.2 kB)
character.png (288.6 kB)
more ▼

answered Mar 08 '15 at 05:09 PM

avatar image

916 45 20 77

avatar image Napoleonite Mar 08 '15 at 05:31 PM

You just created a circular reference as well.

  1. Create a new sidescroller project.

  2. Add a new hud widget called HUD.

  3. Add the nodes as listed below

  4. And voila, you have circular reference already...

alt text

I tried your solution with an event but I get the same circular reference:

I can't create the event in the hud widget without circular reference. But as soon as I "CastToSideScrollerCharacter" I get an instant circular reference. BUT also without casting but by getting the character as a reference from a function or interface or just anything... So it still doesn't work unless I misunderstood you somewhere.

alt text

circular3.png (91.9 kB)
circular4.png (92.8 kB)
avatar image Slavq Mar 08 '15 at 06:12 PM

What version do you have? I've had similar problems with circular references in 4.6 (trying to access player character BP from main UMG Widget BP), but i didn't tried it with 4.7 yet - and in 4.7 release notes there is some circular dependency fixes note... I hoped that these fixes are real :)

avatar image Napoleonite Mar 08 '15 at 06:14 PM

Happens in 4.6.1 & in 4.7.2 (and probably every version in between as well). Is this a known issue? That would be a massive bug and stopping most people from creating any games at all in UE4. I need to test it with a non-umg class now.

Update: Yup same here. I spawned a regular BP class in the level derived from Actor with a function that takes the MyCharacter as an input parameter. The compile-loop also becomes active right away here with just a print-string on the acceleration-property again (or any property from the player).

Basically it comes down to this: If an object/class, used, referenced or in any way, is known to the player class, then that object/class may NOT have any reference back to the player in any way at all, not even an unattached CastTo-node or an empty variable, event or interface. Obviously this is a major problem for me. Basically the player-class can't do anything then... And that, I do not understand. Because every programming language that I know (except UE4 Blueprints) allows this.

avatar image lonerider543 Mar 08 '15 at 06:39 PM

I don't quite get this whole circular reference thing, but I think the issue is known already: https://answers.unrealengine.com/questions/142416/46-breaking-umgs-with-circular-references.html

avatar image Mortusnyte Mar 08 '15 at 06:51 PM


He uses Interfaces which you mention did not work for you but might be worth a watch. He uses the GameMode to communicate.

This issue seems to be Widget related

Sorry for the miss-understanding

avatar image Napoleonite Mar 08 '15 at 07:02 PM

Quick video of the problem: https://www.youtube.com/watch?v=fs6GQ3BZlGs&feature=youtu.be

Just to be sure: My issue is NOT widget related. Happens to any class

avatar image Mortusnyte Mar 09 '15 at 12:56 AM

I've been working on a pretty big project, and I hadn't even noticed that this was occurring in my project also. Aside from the endless compile loop, I hadn't ran into any noticeable problems. Now that it is mentioned, I had been under the impression that I was compiling/saving often...

Blueprint Fundamentals

"CastTo dependency and workaround

This is a tricky issue, sometimes when you cast around in blueprint, you will run into circular dependencies. Ie, compile one blueprint and editor mark another blueprint requires to be recompiled. If you have this happening, it will likely break when you want to run a standalone game. There are usually a few methods to work around, here is 2.

1.Before sent events with object reference to another blueprint, if you only want to access basic info(like location), then only cast to native class(ie Actor), it will still have function available to you and will not cause dependency. That being said, if your blueprint is being castto a lot, you might want to consider making it a native class.

2.Make sure you understand the hierarchy of Unreal Engine 4's classes, it's out of scope of this wiki but when you pass object reference, try always pass up to possible owner of this current blueprint. Say, pass Pawn reference to GameMode, HUD to PlayerController. When you maintain a more strict relationship of how reference can be used, it will actually help you to understand how Unreal Engine 4 works."

Native or Blueprint Class Object

avatar image Mortusnyte Mar 09 '15 at 02:23 AM

So according to this and other research, it seems that referencing blueprint class' will always cause dependency. And it is up to us to structure our Blueprint references in a way that will not cause a circular reference. Or at least avoid certain circular reference scenarios that would cause bugs/crashes. In which case it would seem that creating a native class with c++ would be the work around.

"The Engine is working as intended"

I will continue to investigate this.

avatar image Mortusnyte Mar 09 '15 at 04:20 AM

Another useful thread regarding this.

"So I ran into this before and talked to our UI team about what is happening. You can run the game and have an "uncompiled" blueprint without any issues, because the blueprint was actually compiled after all of the changes were made. The "uncompiled" issue arises because compiling one changes a variable in itself that the other is looking at, so the observing blueprint thinks that it has also changed.

The solution is to just compile them both once, let one be "uncompiled" and use that blueprint anyway. It won't hurt anything, it's just percieving itself as being changed and therefor not compiled (even though it is). Let me know if that does not help or if you have any questions."

If you run into crashes/bugs regarding this, contact the Unreal Engine Support Staff from that thread. Seeing as this was dated from last year, I assume that this, as mentioned before, is intended to work that way.

avatar image Napoleonite Mar 09 '15 at 09:59 AM

According to screenshots posted below, circular references are bad. alt text

It's just, that like 8/10 projects, if not 10/10, have these. And Epic's tutorials/documentation also creates circular references. They teach us to create them...

So obviously I'm confused and still waiting for an official answer.

About the solution mentioned in that documentation.

alt text

It's also bugged... Same problem. Why? Because you still need a "CastTo" in the end. And as I demonstrated many times by now, that alone (even if not used nor connected) is enough to cause a circular reference. Yes that one single node, even when using the native BP for the input parameter.

So basically for me it comes down to this: Either circular references are not bad. OR, the whole blueprint-engine is bugged and everyone who is not bugging/crashing out, yet, is then just 'lucky' so far.

I'm in need of official answers. Preferably from a staff member who really has thorough knowledge about this so we don't have to guess or speculate. Tomorrow I believe, I will be stuck on this problem for exactly one week.

circularisbad.png (24.6 kB)
bug2.png (12.8 kB)
avatar image VRMD Mar 23 '15 at 09:07 PM

Hi Napoleon, I've also spent days trying to understand and fix those circular references problems and it's a nightmare for me! I cannot understand how anyone not have a problem with it.

I'm making a simple pickup system with containers and items and obviously a container needs to know the items attached to it and items need to reference their container.

But it's nearly impossible to do such a simple thing because of this circular reference problem.

Epic staff answers are really frightening because it seems normal for them! But I know there is some dirty bugs behind it because in my case I need to compile my blueprints in a certain order otherwise it doesn't work as intended.

Do you have more info from Epic staff or did you found a workaround?

avatar image Napoleonite Mar 24 '15 at 07:47 AM

This issue (among others) has been reported as a bug. You can only wait. There is no known work-around. But circular references do not always cause side-effects so it is not always a problem.

However, like I said in the other topic: because of the huge amount of bugs in this engine related to blueprints, I stopped using UE4 for now and switched to another engine instead. UE4 is just not stable enough for me to use yet. Every hour I find at least one new bug that causes damage to my project. It's too much. UE4 is probably fine for C++ though.

avatar image Mortusnyte Mar 09 '15 at 07:14 PM

I understand that the information is conflicting, in two forum threads concerning this, both staff members claim that the engine is working as intended.


"Our UI team intends for UMG to work like that" Staff Member Alexander Paschall


"The Engine is working as intended" Staff Member Rudy Triplett

But on the Unreal Wiki, it clearly states as you showed that this could be problematic. At this point, it may be worth sending a message to either of these staff members, especially if you are experiencing bugs/crashes. I linked to their profiles for you to easily track them. If you do contact them, it may be worth mentioning the Wiki page, perhaps the information needs to be slightly changed?

Have you tried using the Automation Tool to check for warnigs/errors inside of your blueprint?

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

Confirmed as bug by Epic staff member in this post: https://answers.unrealengine.com/questions/185609/lots-of-bugs-need-help-with-short-video.html

So almost every blueprint project now is possibly 'unstable' then. I hope they fix it fast.

more ▼

answered Mar 09 '15 at 01:21 PM

avatar image

595 92 104 155

avatar image Mortusnyte Mar 09 '15 at 07:47 PM

"As for the effects of this particular issue, this is also unclear." He points out that the compiling loop is due to a circular reference but never accuses it of being a bug/error causing system. I guess we will have to wait and see for your project.

Blueprints have a long way to go, I am sure, but all(almost) blueprint projects have not become unstable guys :P

avatar image Napoleonite Mar 09 '15 at 08:39 PM

You're right. I added the word "possibly" to the sentence now.

UE4 is a strong 3D engine when it works, plus the license looks really nice. BUT, I use UE4 now for about 2 weeks. About 70% of the time went to debugging bugs caused by the engine (not by me), crashes, or corrupted blueprints or silly undocumented things like loops connected to the result of a function don't terminate the actual function (like in every other programming language in the world). They forgot to mention that in the documentation as if it was 'logical behavior'... Things like that. And then you have the missing features like "no level-streaming for dynamically generated levels" or no build-in node for incrementing a variable by a specific amount.

Yes I might just be unlucky and it may work perfectly for you folks. And the engine itself is fantastic, when it works. They fixed a lot of bugs between 4.6.1 and 4.7. But still, I don't exaggerate when I say: "not one single day went by without seeing a bug or crash from the engine"

Or in one sentence: It's usually hard&time-consuming enough to debug my own project, I don't want to debug the engine as well.

(comments are locked)
10|2000 characters needed characters left
Viewable by all users
Your answer
toggle preview:

Up to 5 attachments (including images) can be used with a maximum of 5.2 MB each and 5.2 MB total.

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question