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
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.
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.
To be honest, I’m not even sure if I’m having a REAL circular reference. But didn’t you notice that when you compile the HUD-widget (or whatever class you use), the player get’s a new gear-icon on the compile button (asking to be re-compiled)? And then when you compile the player, the HUD asks to be re-compiled? This (de-)compile-loop repeats forever.
Someone in another topic asked me to make sure that I have no circular references. And I thought that this compile-loop was caused by a circular reference. The reference viewer also shows dependencies in both ways.
A bit off-topic but this is the other topic in case you’d like to know:
But I’m getting this feeling that I’m doing some really stupid. Because I seem to be the only person with this issue (or bug if it is) and everyone else seems to be using the exact same methods for communicating between BP’s.
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
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.
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.
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).
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?
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…
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."
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.
"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.
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.
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.
