If you have blueprint functions which return something (which you definitely will make if you have a little programming background and your graphs become too redundant) you will always want to return if it is false/invalid as soon as possible.
Right now this is not possible since there is only one return node allowed per blueprint function.
So you need to chain all checks which you want to have true and return for example a true boolean at end but then it will not return false if they are not all false (not sure what exactly happens there). So you need to hook up all false events to one single return node too which then becomes a mess.
Your next idea is probably to have a bool AND node which connects all your checks and is connected to return node. issue here is that all checks are always executed if those have execution pins (like other blueprint functions) which is slow especially for AI/behavior tree blueprints.
A workaround for that is to add both branches and a final AND node which connects all your checks which seems to somehow work but this is just really ugly and becomes a mess if it is more complex than a few simple checks. See image below.
Just allow us to have multiple return nodes in a single function which we can use to break out of function and return a value as soon as possible. Just talk to any programmer and they can tell you why.
An alternative way to tackle this, while we wait for improvements, is to use a variable for return value. It will be assigned where you would want extra return node would be. Then jump straight to return node at end.
well I can always add additional variables/outputs but this is not how it should work. Also in my example I only want one single answer which is if target in being seen in a sphere or not. Being forced to have only one end point is bad design. Pretty much every programming language I know of supports being able to return a function from any point and there is a good reason for that. You are able to jump into other functions at any point so why are you not allowed to exit them at any point too. This is especially problematic for validation code which was also my example. There are good online resources for why this is good practice: language agnostic - Should a function have only one return statement? - Stack Overflow . Allowing multiple returns per function would still allow users to use temp variables and a single return if they really want so but I doubt that anyone having some programming background would not prefer being able to return immediately.
As long as you’re in a function window you have at bottom of your normal variable window a new one which shows you local variables. They are exactly like any normal variable with exception that they don’t have default values.
Is there any information about this?
This feature would be nice. I dont like they return node functionality too. Every programming language can have multiply returns.
It is hard to work with flow control without this support in blueprints.
Sorry but how hard can this possibly be? Nearly every programming language supports this without any problem. Instead of that I had to make dozents of cruelsome workarounds with temporary ‘output’-variables just because of that.
BTW: Parameter values should also be available as local variables, should make functions a lot more readable.
Your notes have been added to request. As I said, developers are reviewing request for official implementation. If you feel you are able to make change yourself, please feel free to add a pull request for review.
You’re right. Was just a GUI issue in my case. But what I really would like is all input parameter automatically made available as local variables (like in any other programming languages). Would reduce Spagetthi factor.
No news yet, sorry. It’s currently been pushed to 4.9 for earliest consideration. I’ll send an email to devs to remind them and see if I can get some additional information on it.
Would be cool if function arguments were automatically available as local variables. Now I always end up doing a bunch of set nodes like you are in order to avoid connection chaos.
