When you make a function in Blueprint and you have input variables. It would be nice for them to somehow to be available as local variables as standard.
when you build bigger functions I usually end up making a ton of local variables, setting them to begin with, and then use them around my blueprint.
If I don’t do this, I end up with spaghetti all over the place.
This is what I usually do to keep my BPs clean. But it’s a lot of work.
Also, you can’t reuse the names from you function input to your local variables making the problem even worse. You get a compile error. So you kind of lose track if you’re not consistent in your naming.
That example there is actually taking a struct that I break… but the problem remains… You have a ton of data that you can’t access unless you draw long lines or make local variables. Or in this case I could reference my struct… but it is a big struct… and even when collapsed, it takes up more screen space than a local variable.
This is a good idea, and one that we’ve talked about before internally. Since there seems to be some support for it from you guys as well, I’ll go ahead and put it on the list to add as we get some spare cycles. Thanks!
Generally, the purpose of local variables is that they only use memory when the context that owns them (a function in this case) is being executed. Regular variables would take up memory the entire time the object that owns them exists. So, if you just need some piece of data to exist for performing some calculations inside a single function, it is much more efficient to use a local variable for that. Data that needs to persist outside of the function would need to be a regular variable, unless you design the functions that need access to it to pass the data around as arguments.
It’s really annoying to do this manually every single time we create a (not-tiny) function, especially in large BPs. I tested in 4.5.0 and it still hasn’t changed.
It’s still on the list to do, but unfortunately we haven’t gotten around to it yet. The current focus on the team is currently to improve the editor, compiler, and load time performance for blueprints, and then we expect to hit usability up in our next push.
