I see a lot of people praising BluePrints, for 99% of everything, but they mention C++ at some stage, at least.
So far, I haven’t found much of a need (well, maybe a couple of things but I can deal with it)
But what are the deal breakers? The things that BPs just CANT DO?
Blueprints are great. But at some point when everything grows, it gets just messy. Bigger the graph easier to click something by mistake and break blueprints. For eg. my friend while deleting obsolete nodes clicked one node that should not be deleted, everything went nuts because that node was condition to do certain action , and that action was never done after node was deleted. Or i clicked something yesterday after migrating from 4.5 to 4.6. I am not sure what happened but previously that vector coordinates were always in negative, now i am getting first time big positive values (at begin play) then next tick everything is like it always was. Something spawns in wrong place on first tick then snaps to correct location. It all changed because i moved bunch of nodes and they were refreshed in 4.6. Backup version in 4.5 works just fine.
For next project i will go blueprints with custom C++ nodes that contain bigger tasks (or biggest possible tasks that can be contained in single function). Mlutiple conditions in blueprints are mess, when doing this in C++ is much more readable. Also no bool algebra in blueprints (where are binary operators like not, and xor?).
It sounds like you need some functions! 
Nope functions do not work. There is cool method for optimizing multiple conditions into single binary calculation, i would love to use that instead of chain of conditions (sadly i do not know English term for this, so cannot google and provide link). But blueprints do not have Boolean expressions, well they translate any expression into network of nodes, so my boolean expression would be split into nodes anyway. Closing big condition graph into one function changes nothing, that mess is now somewhere else.
What works is doing that bool optimization, then writing custom blueprint node that tell true/false based on inputs. And compiling.
Btw. Blueprints also fail on arrays that have more than 1 dimension.
But they are totally awesome for automaton things like boids.
Can’t you simply use a “Branch” to achieve a similar (If not, identical) result?
Couldn’t an Enumerator get around this in some form? I’m not too comfortable with arrays in C++ yet, So I’m yet to discover the differences :<
NOT and XOR are available in blueprint…
Also, I generally agree with the non-1 dimensional arrays, but you can approximate them using a single 1 dimensional array so that isn’t really a showstopper.
In general, the places blueprint fails is in the areas that have not yet been exposed to blueprint which covers the spectrum but isn’t concentrated enough to be a huge problem in any specific area. Things like not being able to spawn things into streamed sub levels from BP, not being able to do certain network functions in BP, etc. You can use streamed sub levels, networking, and other things, but you are missing a few tools in each area that makes things harder than they could be with certain additional nodes.
Then there is speed. If you are doing something that is non-draw call performance heavy such as lots of math in a short time, then you are going to want to put that into C++. Most things are fine in BP though.
All in all, C++ has absolute power, but blueprints also have a lot of power and are gaining more patch by patch.
There are only some c++ functions that are not (yet) implemented. If you relay on some of them you have to wait or use them directly in c++. All “other”, i would call them nerve-breaking, things are related to bugs. My favoured one is the still wrong variable scope in functions. Actually I get used to it and name my vars like in the old days.
I guess you can relay on BPs as long as you don’t need the performance of c++. At least I go that way and only change performance breaking parts to c++.
You could consider structs.
I was not precise enough binary bit operators on byte and integer, that is missing, or if they are there i could not find them yet. . So i can store multiple boolean values in one integer. That is direct result of lack of multidimensional arrays.
Also one more missing thing: way to load some data into editor and keep it there, just like we do with textures and meshes, but for integer array or string etc. But this is not specific to blueprints only.
As I said, there are ways around the lack of multi-dimensional arrays. I use 2 methods. 1 is a struct array that has integer arrays inside. The other is to use a normal array, but index it in a way such as a column would be say 10, 20, 30, etc, and the rows would be 0-9. Both methods are detailed at various places in my map generator threads.
I would still like to have multi-dimensional arrays in blueprint just to try them out.
Yeah I am pretty much all for adding every possible node we could need into blueprint. I keep meaning to make a thread that tries to compile community requested nodes/bp functions.
You can create a bunch of structs containting strings, ints and so on, put them into an array and save that array. There is a simple save/load system to support that. Tha .uasset may be even modifable outside of the editor (untested).
PIE start times.
When I wrote iTween in blueprint, my projects using it really started to slow down. This is most likely because I had a separate blueprint for each tweening operation so there were somewhere around 25 different blueprints. Even when I wasn’t using certain operations, the editor still had to load them into memory at PIE time. I ended up waiting up to 10 seconds for the editor to play a simple scene.
I ported the library over to C++ and the PIE times are nearly instant, just like they were without iTween at all. C++ logic takes a lot longer on first compile (and even hot reload!) than blueprints take to compile, but the time I was saving in compile times was being squandered waiting for PIE to get my blueprints straight.
Not to mention BPs have these phantom compile errors where on first load it tells you there’s a BP compile error and it affects PIE. If you go compile the thing there’s no actual problem. It compiles fine and you move on, but then if you restart the editor the compile error is back. No way to fix this as far as I can tell. And as someone else mentioned there are for-no-reason variable scope errors that I can’t seem to squash.
Overall, I love BP and if you’re lucky you can make a full game from them. I do most of my work in BP then move it over to C++ once I have a good idea of the flow of logic (or my BP breaks in some idiotic way I can’t fix). But there are some things BPs can’t do, like file I/O unless you write nodes for them yourself in C++.
Jared, try deselecting “Auto Recompile Blueprints” in Editor Preferences → Play → Play in Editor and the play ist nearly instant. Well, due to some…bugs…you will likely been ask on every start if you wish to recompile, but at least you can skip.
You can also hook up a Select node to a boolean if you want to return a variable (of any kind):
This has helped me in multiple occasions when I handle bone hits etc. 
At the moment there is a pawnsensing bug that is already fixed on the C++ side that irks me, but other than that I have been very happy with BP’s.
For me it has to be Object Library implementation, which still hasn’t been exposed to BP. Without Object Library reading, there doesn’t seem to be a way to get all Child Classes of a certain Parent Class (and yes, I mean CLASSES, not Objects or Actors) which would make equipment selection screens a lot less tedious to make.
Blueprints so far are great, except when you run into weird bugs that can not be easily circumvented. One time I had an issue with blueprint interface comparison simply giving the wrong result: so both == and != did not work properly (Blueprint interface comparison bug - Blueprint Visual Scripting - Unreal Engine Forums). I’m not sure what causes it and I’m not sure how to report it because its inconsistent.
Pure functions are awesome, but refactoring impure functions to pure functions (and the other way around) should become easier. For those who haven’t used pure functions yet, you can flag any function as a pure function. Then it doesn’t need an incoming execution wire, but its simply executed when its return value is required. So pure functions are for getter functions. The problem is that when you are already using a function in several places and then you change it to pure, your graph simply becomes disconnected at those places where you used the function before and you have to find and manually fix that. Kind of related, but I would like a feature for automatically detecting “dangling” nodes: nodes that require an execution wire but do not have one. That would easily solve this problem.
A similar thing happens when you change the name of a function’s input variable. Suppose you have a function MyFunc(int a) in blueprint, so it takes an integer input. You use MyFunc somewhere and connected an integer value to it. Then, if you change the parameter’s name, all prior connections are lost and it reverts to the default value you specified in the function. Not sure if this is changed in 4.6.
I really want the ability to reorder functions. Not just placing them in categories but also for the order in which they appear within a category. I mean, you can reorder them currently by dragging them in and out of categories, so that the last one dragged in appears at the bottom, but come on. Also, I want automatic local variables for incoming function parameters, and the option for multiple return nodes. If I have a long function that performs a lot of checks and aborts when any fails, I just want a quick equivalent of “return false” in multiple places.
To summarize: So far almost anything is possible, some things just very tedious.
You’re right! That’s a neat tip. The messagebox that pops up is annoying, but less annoying than waiting. Thank you!