Just wanted to ask whether its planned to fix them at some point… We had them in all versions till 4.9.1 now and from 4.8 to 4.9 nothing got better unfortunately (at least I did not notice any improvement).
I still have to compile some child blueprints every time after I compiled the parent because the childs get compile errors after compiling the parent (but manually compiling of course works). It’s especially problematic with UMG, but there it’s the other way around, I compile one child and if I have bad luck, all widgets where this widget is placed in (and all widgets where the widget is placed in where the first widget is placed in etc) get compile errors, are changed to REINST variables everywhere and so on. This can easily force me to manually compile 6 or 7 other widgets after I compiled the first one. Which of course is a huge waste of time, it can take quite a while to compile a widget with dozens or hundreds of child widgets (counting all the childs in the childs in the childs and so on).
The even worse problem this leads to is that sometimes all kind of nodes get disconnected from each other, I guess it’s because REINST nodes don’t fit some other nodes. So then I have to go through all BPs and connect all the wires again…
When I say “child” in UMG I just mean a widget placed in another widget.
I know I have strong cyclical dependency in my widgets, since childs communicate with parents and parents communicate with childs so they all have direct references to each other. But it’s just needed for what I do, I could probably workaround it with using interfaces for the communication but I think that is not how it’s meant to be used.
With regular Actors I only get cyclical dependency problems when spawning a child of itself in an Actor, so it’s by far not as bad as with UMG, but still annoying.
So, is there any improvement planned for this to finally fix it?
I read through all commits which get added to the master branch on github and in the last few months I think I often saw commits which description sounded like they would fix all kind of cyclical dependency issues, were they just not yet added to 4.9, so will all these issues be fixed in 4.9.2 or 4.10?
i too am still having a lot of problems. It makes UMG a nightmare. i had intended to move Jcinventory to a non interfaces everywhere system (just to have cleaner code) because i thought this was fixed but in the end it was a huge waste of time . Im sure epic are doing all they can but i guess its just a very tricky problem.
I have repeatedly gotten these issues whilst working with my multiplayer chat (Consisting of several childed widgets), I fix them by compiling all of my associated widgets, or just the upper-most widget in the chain. I also get that REINST problem, which compiling fixes. Other than that, I haven’t found and permanent solutions. I have had to compromise on features of my chat system which I am making for the marketplace due to UMG bugs:
I think that UMG should be bumped up on the list of priorities, it really can put a stop to things that I’d like to work on.
Compiling just the upper-most widget does not work for me most times, unfortunately.
A few hours ago I got again the REINST everywhere (like always when I do stuff in widgets) but the special thing was, the references stayed REINST even after compiling everything anywhere multiple times and even after restarting UE4, so I had to actually delete the widget, place it again and replace all references to the new one… This is not how I want to spent more than an hour of time where I could work on productive stuff
Compiling from the bottom one up until I am at the uppest one mostly works, but it can take like 3 or 4 minutes because I have really huge BPs with many many childs and references, one compile of one BP can take between 10-20 seconds sometimes and there are a lot of BPs turning dirty, also non-UMG ones, so I have to recompile all of them. Then sometimes childs get dirty again after I compile a parent and so on. But after 5 minutes of compiling everything I mostly get a clean state everywhere, just in what happened today nothing helped and I had to delete the widget and so on.
We need those files when it happens. The blueprints team has been making a test bed for REINST errors and each time a new case is found we add something to be tested in the future. So don’t just delete and start over, send us the project so we can figure out what’s missing and fix it
We’re working on the dependency issue with UMG blueprints; we’ve been making careful steady progress with the circular reference problems. We think we know how to fix the dependency recompiling / reinstance problem with UMG, at least the main one, but we have to make sure we don’t break something else in the process.
So when should I sent you the project? Once the REINST bug appears which is not fixable by compiling everything again manually?
I don’t think I’m doing anything special what you don’t have in your own “test beds”. I just often directly reference the parent widget in the child widget. Are all problems you have in your test bed fixed, so do you not have any projects there where REINST problems appear which are not fixed by compiling all widgets? If you already have a project where you can reproduce this, I don’t need to upload my whole 20GB project :rolleyes:
When I first started up my project today/yesterday I actually noticed that one widget again was changed to REINST and it was not fixable by compiling anything. So I again had to delete it and so on. And even worse, even if I get everything to work again in the editor, while packaging it seems to change again to REINST or for any strange reason all wires to references of this widget get cut and packaging fails, I also wrote a bug report about this today/yesterday on the answerhub: Nodes disconnecting while packaging, packaging fails - UI - Unreal Engine Forums
It’s a bit “unpleasant” to not be able to package the project…
As for the non-UMG cyclical dependency problems which only occur in one of my actors, I already wrote a bug report about this on the answerhub in June and Samantha Sutton was able to reproduce the issue, it’s UE-17866 but she said it’s set as a “minor bug” so I guess it’s not important for you to fix it.
After the 4.9 memory leak forced me to restart my project I again have all references to one widget changed to REINST and all wires cut. Still the same widget which also gives the error while packaging. The first time I started my project today the references did not get corrupted, so it does not seem to happen all the time.
So I have one widget A with the child B inside and B is named REINST_B in the Hierarchy. Widget A is compiling without any errors and widget B is also compiling without any errors. But all wires to references of widget B in all other blueprints (not only widgets) are cut since it’s changed to REINST_B everywhere. And no matter what I do, widget B will always stay REINST_B in the hierarchy of widget A. And I also can’t save widget A because “graph is linked to objects in an external package Engine/Transient”.
Widget A and B don’t even have any extreme cyclical dependency I think… There is no reference of A in B at least. And A also has no reference to it’s parent. So just regular parent and child widget.
The reference viewer is unfortunately quite useless since the minimum zoom level is way too high and I have a much higher depth level than 12 which is maximum to search for unfortunately…
Somewhere in the center here you have the Gamemode. For making it simple, if I want to migrate widget B then my whole project get’s migrated But thats the case for any blueprint I have.
Question is, isn’t that too many childs and references?
And what exactly is a reference, issue coming from, casting?
Because when im checking my spell system actor, which handle everything, from animations to widgets it has references everything to interface and than to actual blueprints and only two widgets which has casting, reference blueprint to blueprint.
Mb that’s an idea, for hardly dependent stuff, to use interfaces?
I’m not criticizing, i’m asking.
I’m not sure I can get your point. You think I am using too many references and ask me why I am not using interfaces? Your English is a bit hard to understand. I can’t use interfaces for everything like spawning actors and so on. But once I spawn an Actor from a widget the actor is referenced, the actor is referencing the player controller, the player controller is referencing all kind of stuff like Gamemode and all kind of managers I have created and so on.
Sorry for that. But as i understand, problem is in compiling a lot of dependent widget blueprints. I have the same, because i made one button widget and placed it 5 times into another widget, so i cant compile panel if button is not compiled. Also i cannot migrate it without cycle issues. So im asking, is that your exact problem and if yes, is that bad design decision and should i make everything self contained in the future and also could you re engineer your widgets? Or is that issue comes from casting nodes too, should i use more interfaces?
Please create a bug report on the UE4 Answerhub (follow the link in my signature). For the project you wish to send, please reduce the filesize as much as possible. Remove all content that is not necessary to reproduce the issue.
You can attach the project to the Answerhub post if it is small enough, or you can provide a link to the download. If you wish to only share the file with Epic, you can wait until one of Epic’s Support Technicians contacts you on the Answerhub post, and then you can use the forums to send them a PM.
Every time I open the project, all the references to one of the widget get cut, the widget is changed to REINST Name and the only thing which helps is deleting it and adding it again to the parent widget. Doing this and replacing all the references with the new one takes ~10 minutes.
Then I use the engine for a few minutes up to half an hour, it crashes, I reopen it and I have to do all of it again for ~10 minutes, use it until it crashes, and so on I have the feeling that I waste a lot of time.
Nick, is there anything like a workaround for preventing a widget to change to REINST? No matter how ugly the workaround is.
Hey John, best workaround i have found is to make all widgets that talk to another use an interface. its pretty ugly, but when doing this i run into no issues.
Also make sure your interface only handles standard variables like aactor or apawn etc, don’t use any blueprints. so if you need to pass a child of a aactor, you need to set the var to aactor. You can avoid casting by using more interfaces and this way your widgets will not have any references to one another (unless its in the designer, but that cant be helped- when i made jcinventory this was pretty big so i made a lot of my pop ups inside the ‘layout widget’ even though it offended my OOP sensibility). Its pretty horrid, but it works!
I think its way more than 15-20 but since its so much I don’t really want to try to count them Let me count the amount of widgets I have… Its 60. And the hierarchies of the widgets are also quite deep.
. Im sure epic are doing all they can but i guess its just a very tricky problem.
I have the feeling that I waste a lot of time.