Another example why Short Circuit Evaluation makes sense:
I get accessed none, because I Access AcceptedAmmoTypes of a non-valid object, although i checked it.
I mean, yeah I could use an impure Branch, but having a single AND is more clean .
Do as does, make a ghetto âorâ and âandâ for x2,x3,x4 with execute and branches macro so you can avoid such issues.
^But it would still be ghetto 
Wait this still isnât fixed? I got hit with some terrible virus, so when I get the I will make a pull request, someone else can do it if they want. Iâm fairly certain the fix is on the first page. iirc the comma operator and return line fixed the sc for the and node. If other nodes do the same thing the should also probably be updated. the assumption is if SC is what is intended, its a bug if no SC.
the file is UnrealEngine/Engine/Source/Runtime/Engine/Classes/Kismet/KismetMathLibrary.inl
also donât just submit a pr, dl the master, edit code and test it.
Edit after some extensive testing im fairly sure blueprint verifies all input to a node before it executes. i will try some other things. although it seems a node like && cannot short circuit because itâs by blueprints design. i originally thought the compiler was doing something but i think its actually bp, which makes much more sense anyhow.
//test1 normal engine
// test2 my edit of the bp nodes
nothing changed. looking back, this is totally expected. it has to be execution order. basically, AND(A(), B())⌠A and B are executed before AND().
i donât think this is possible actually because it acts like a function and must be fully evaluated. this was an interesting little test.
soit is possible with my original idea, the staggered nodes which isnât ideal but at least we have something. I guess if you really need the speed code in cpp, hehe
at some point, you getting used to it 
I have a ghetto dump callstack blueprint macro, zero divide by zero, works like a charm
Surprised among all this no one mentioned that UnrealScript operates this way (stops evaluating AND/OR when a condition is met)⌠after coming from UnrealScript to BP I was pretty disappointed to find it evaluates everything and you need to spam your graph with branch nodes if you want efficiency (and keeping things tidy is even more important in BP).
Doubly disappointed at Select nodes evaluating all inputs as well⌠I made my own pure select nodes in a shared library that do a branch, and I suppose you could just make yourself some compact AND nodes too (one with 2 inputs, one with 3, etc⌠using a BP function probably negates the performance gain from not evaluating both inputs, but after nativization I imagine itâd still be better). Obviously you have the problem there though that you canât keep adding input pins like you can with the coded BP select node or AND/OR nodes (which would be another great feature btw).
EDIT: Actually, looks like they may have fixed the Select node for 4.16?? Unreal Engine Issues and Bug Tracker (UE-20044)
It is marked Wonât Fix.
I researched source code and this goes deeply to a blueprint bytecode, so I am not sure if they will be able to fix this.
And And operator bug is made because And is made as a function, so there will be no short circuiting too.
Bleuprint VM is broken in many ways, so it will need a complete rewrite to make us happy.
âŚyeah this all sounds great actually
Sadly that Note seems outdated Found a way to reproduce UE-20044 - Blueprint - Epic Developer Community Forums
Really was looking forward for that fixâŚ
Checked in UE 4.16 - still call every option node function.
Checked in UE master - still call every option node function.
Here is my test code. Number Log outputs formatted string Option {Number} Log. All three are printed.
I was moved to make this today
+1, here is another case when this would be useful:
https://forums.unrealengine.com/development-discussion/blueprint-visual-scripting/1399937-select-nodes-vs-branch-nodes
+1 here, still waiting for thisâŚ
just ran into the same issues again, as i built some blueprint nodes like i wouldâve done using C++. Obviously the access violations spammed my log and i had to adjust my blueprint using much more nodes :mad:
Not sure how weâve managed 7 pages, but thereâs a reason this feature doesnât exist - it canât. It would totally break recursive functionality.
Edit: as an aside, talking about proper short circuiting - conditions failing early and logic not being evaluated when it doesnât need to be would be a welcome change (boolean condition checks, select nodes) - but this is unrelated.
+1 for the request.
how would this break recursive functionality?
This is neither an âasideâ nor âunrelatedâ, this is exactly what the thread is about, as well as being an example of how terrible people are at interpreting text nowadays.
Anyway, the biggest roadblock to implement this is that all pure nodes in BP like AND, OR, and SELECT are actually functions under the hood and thus need all their arguments before they can run. For short circuit evaluation there would need to be a new kind of node that is capable of lazily evaluate its pins, with very different underlying code. Doesnât sound trivial at all.
Bump. Desperately need this. Donât want to have so many branches and IsValid macros to write otherwise very normal code.
Bump⌠please make it a priority :â)
Wait a minute⌠There still is no short-circuit in BP?
