I have a function that calculates a value - so far, so simple. Depending on a condition the value should be returned as is or it should be (360 - the value). How do setup the blueprint so I can use these as a return node, it doesn’t look like you can pipe two return values into the return node. I’ve got around this by using a variable and setting that but that’s not ideal really (at least to my programming mind). This is what my blueprint currently looks like.
We all want to have multiple return nodes but it seems no one at Epic want’s so implement it 
Another imperfect solution that’s a little bit less offensive is to use a ‘Select Float’ node and feed the result into your return node. At least it avoids using a variable.
Yes! Select Float is exactly what I was looking for - thanks 
I’d assume your after something like this? You can add multiple exec pins for macros which would probably fit the purpose of what your trying to do in your function.
Pattym - thanks for that solution. Select Float is what I was looking for right now as it’s only a choice between two possible values but that looks like an interesting alternative if I have something more complex to achieve.
Why do macros allow multiple return pins, but not functions… Epic hear our cries for multi-pin functions please.
if you need something like macros which do more than one task, you should think about your code and consider refactoring instead.
A function should only do one thing (SRP-principal) and if you had stuff like you wished for it would go strictly against clean code style.
Next is: that a function should be as small as possible and should do exactly like it is called (never do more stuff like your function´s name suggest)
So in the end its better to have more functions with less lines of code, than one function with a huge amount of code/or blueprint nodes.
As for the question:
why do you need something like Select float? Instead, you could do something more readable like this:
And for the future:
if you can read your blueprint function from left to right, only reading functionnames and you are able to understand to workflow. It is probably clean code you´ve written 
1 Like
Multiple return nodes are possible as of 4.9, but not multiple execs. Though it is possible to do it through custom blueprint nodes in C++, using ExpandEnumAsExecs.
For example:
UENUM()
namespace EFileExistsResult
{
enum Type
{
FileExists,
FileDoesNotExist,
};
}
//...
UFUNCTION(BlueprintCallable, meta = (ExpandEnumAsExecs="OutResult"), Category = Game)
static void CheckIfThisExists(const FString& Filename, TEnumAsByte<EFileExistsResult::Type>& OutResult);
There isn’t even much benefit of having multiple execs in that example though obviously, a bool would do the same job.
To me multiple execs don’t really make sense as a function anyway, it’s more of a macro. The function returns a value or causes some change, you handle the control flow outside the function depending on what it returns etc. that seems truer to a regular c++ function really.
It would just be putting a SwitchOn or branch after the function instead of inside it, but I think that is clearer to someone looking at the code, as they can see what is happening without having to look into how the function itself works. The function’s name should make it clear what is intended. Though if you wanted you could encapsulate all that in a macro sure.
Yes, multiple return exec pins is what I actually meant. I understand that you can put a branch after your function node, but it would be so convenient to be able to have the function do the branch for you internally. That way the function node on the blueprint could work in a similar way to the Has Authority or Is Valid nodes for example. Both of these nodes control logic flow internally. Imagine a case where you need to use your function node 20 times in different places. It means you also have to set up a Branch node 20 times, which is a real hassle.
Both of those nodes are actually macros that just branch after the function, you should probably set up a macro library that you can access from any blueprint.
Ah ok, I didn’t know that. I’ll look into that.
Ctrl c ctrl v?
[attach=config]90745[/attach]