No idea. As the title says.
If I find out what triggers this I’ll post it. Can’t call the non bool version of IsValid all of sudden at all on widgets anywhere. Creating a new variable in the UserWidget of type “UserWidget” or any other object does not make it reappear.
I think this might be related to something that keeps cropping up.
If you go to any BP that does have an IsValid node, a copy the node, paste it into the offending graph.
From then on, you will be able to find them in the list.
It’s a bit sh*t…
Try to left click the node and convert it to validated get. This will convert the object reference directly into non bool version. After discovering this trick I stopped using the traditional non bool version all together xD
Thanks for the suggestion. I am specifically using the non bool IsValid method instead of the validated getter on your screenshot because that shows up strangely in the “find” panel. Or it does not show up, something was wrong with it.
Confirmed, your workaround does make the IsValid node reappear. Keeping this post open in hopes it is noticed as a bug?
I advice you to use the validated getter because it runs trough C++ while the Non Bool version is valid uses blueprints. In fact, if you will place a break before the validated getter it will literally skip the node while with the blueprint version it will run through some blueprints.
If your project gets big it can slightly impact your performance if your really a lot on validating your objects or have a lot of validations in the animation/umg/blueprint ticks/updates. Personally after 1 or 2 days of development I spend at least 5/10 hours optimizing the code to make it as performant as possible.
This is interesting
Very difficult to replicate ( in the normal sense 
)
I have thought about it but I must conclude that I’d rather not use blueprints at all where I can, this would be the biggest optimization. Just replacing few checks in BP is unlikely to have a big performance impact while moving everything to c++ only has upsides.
The designers (non programmers) who will work with UMG or the skeletal animation panels will not be aware of programming optimizations at all and will still use all those nodes.
I know both C++ and C#. Despite C# is faster I chosen to use Unreal Engine instead of Unity mainly because of blueprints. It helps to organize better your code and debug faster thanks to its visual representation and a lot of debug tools. Also using blueprints speed up a lot the development time considering that you don’t need to write the basic syntax for everything. At the end of the day blueprints are heavy only for the developers. In fact during the packaging of the player build everything gets converted into C++ anyway.
So if your game has a bad performance with blueprint on your high end working station be sure that 90% of players will complain about performance even if you write the code directly in C++.
To finish there are also a lot of pre built systems in blueprints that you don’t need to develop from scratch in C++ so is handy as well.
In my opinion this days deciding to work with Blueprints or C++ is the same as deciding if developing with C++ or Python. In fact Python is 100 time faster but has less applications in game development. Considering the pros of C++ I would always chose it to Python for developing game mechanics. Same I would always choose to work in Blueprints compared to C++ because it takes less time to achieve the same result. Time is money and I prefer saving as much as possible to invest in creativity.
It’s a bit offtopic for this post but…
This is an experimental option and doesn’t result in the same c++ you’d write manually.
All those systems are present in c++ and just exposed to Blueprints through libraries.
Python is used everywhere in visual applications both 2D and 3D take GIMP and Blender3D for example. Not to forget about AI and entire game engines.
There are a lot of downsides and limitations to blueprint, but let’s start with the most obvious that they are binary files. They are big, don’t work nicely with source control like GIT, are bloated with info unrelated to code and corrupt like mad. If the blueprint editor decides it can’t update something, or bugs, you find yourself spending a week clicky clicky on all the pins and lines and nodes where I’d have done a single regex command in c++. I moved away from blueprints entirely (and will never go back) and ONLY allow blueprints for creating variants of say the gamemode and UserWidgets (because UI designers need those…)
Just for the information… Let me grab some old data from my documents:
1. Blueprints have limited access to anything written in C++, this is also true the other way around. Besides that Blueprints also miss c++ features.
2. Blueprint maintenance can not be done with quick text operations as you are forced to work with nodes and editor panels.
3. Moving existing Blueprint assets to C++ takes time.
4. Implementing a core redirect from a an asset to C++ can rarely be done, it simply doesn’t work with structs.
5. C++ file changes are tiny, can easily be compared, logged, merged and restored through version control. With Blueprints this is not the case as they are binary files.
6. Blueprint files can corrupt easily.
7. Large Blueprints, often the case with animation Blueprints save and compile very slowly.
8. Blueprints property / function / meta specifiers have akward / half implementations. For example, the min max clamp on a float property does not enforce the clamp in many situations.
9. Blueprints do not use the protected specifier on the MyBlueprint tab.
10. Blueprints sometimes require a large amount of nodes which would be a oneliner in C++.
11. In Blueprints, distinguishing class members from local variables in the node system can be confusing. In Blueprints I personally suffix any local variable with an underscore and prefix function parameters with “In”.
12. Most modifications made through Blueprint related editors are destructive actions, immediately affecting the directly and indirectly related blueprints where a c++ text edit is not. Think of pins breaking, widgets being deleted, property pointers breaking, localization breaking, animation notify references breaking etc. All unsolved editor issues you don’t deal with in c++.
All depend how you work with blueprints and if you have a best practices. Sure it has a lot of disadvantages if you combine it with C++ but for some issues like the point 7 can be overcome.
Animation blueprints update every tick so if you calculate everything needed for your massive animation blueprint even if you don’t need it for the actual animation state every frame obviously it will be slow. Instead you can create linked animation blueprints and calculate only the data you need when you need it using interfaces.
We can argue about many points but at the end of the day is all in what you prefer to use and if you master the tools at your disposal.
Hello. Roy, I saw you also posted on this thread.
I reproduced the missing IsValid issue you mention in UE 5.1.1 and found that it’s the same bug as that one:
UE-149464 “For Each” Node doesn’t show up in UMG Graph until an Actor BP is loaded
For example, if I start a blank project and create a widget blueprint the IsValid node (just like the ForEachLoop node) don’t appear in the blueprint context menu. If I open an actor blueprint at any point, both those nodes start appearing. So the repro conditions I believe are: don’t open an actor blueprint yet and then start editing a widget blueprint.
I see you’ve found workarounds. 
Opening an actor BP would also be a workaround. This won’t be fixed anymore for UE 5.1 but is fixed for 5.2. You can consider cherrypicking the fix if you build the engine from source. Log into Github and check out this fix.
Hi @ZhiKangShao , thanks for replying and fixing this issue.
Are there plans for an LTS version of the engine? Currently I find it very difficult to imagine supporting the latest 3 versions as a plugin seller and game creator (EPICs terms), with the bugs involved in these versions. I hope to be cooperating with EPIC and the community on a more stable base. I have made a request here.
