Making Blueprint function inputs - local variables, would increase readability of Blueprints and their maintenance. It would reduce number of wires stretching across the graph. Moreover, it makes sense that input variables are local variables.
Surely you can do this already though, right? If you want the input data stored as a local variable you can just do that and reference it when you need it.
How? Duplicating them? If yes, it’s not cool.
I mean it makes sense if you create a new input for a function and the editor promotes this input to Local Variables.
Maybe I miss something?
This is something we’re definitely planning on doing. It will really help with wire management and readability in large functions.
As zerofiftyone mentioned you can promote the inputs into local variables to help for now.
This would be a good feature
I’ve actually got a prototype of this shelved for input pins (output pins need more discussion RE: return nodes in general), but the approach I took makes params feel different to locals in a lot of ways (e.g., details panel display/etc…).
I probably want to go a different route and make the local variable list the authority for parameters, so the UI ends up looking the same for both, but that’s a bigger refactor, hence why it hasn’t happened yet.
It’s nice to hear you’re planning on doing it.
At the moment I’m using reroute nodes to clean my graphs a little and once Blueprint prototype is working, I convert it into C++ code.
Thanks for the rapid response! You guys are awesome.
It’s been a while now, is this still planned?
It’s currently backlogged.
Another year and a half have passed… Why is it so difficult to just un-hide the input parameters from the local variables list? Because that’s simply what they are…
If it were that easy it would have been done already. In the final compiled bytecode the two are effectively the same, but in the ‘source code’, inputs/outputs are currently handled completely differently to local variables. Locals are done like class member variables with an array of BP variable decls, while inputs/outputs are done with the pins on the input/output nodes being the authoritative data source. This is what I was saying earlier, the ideal way to add this is to make the parameters of a function just be done in the same way as locals are done, but that entails a bunch of extra backwards compatibility work to convert from the old to the new way, so it’s not a tiny quick feature.
hi Michael, no link with this topic but as Paper 2D Creator and 2d lover could you throw one of your eye on this topic :
Ori and the blind forest GPU Water and dynamic wave - Rendering - Unreal Engine Forums , i guess for everyone working or loving modern 2D it can be very interesting as btw it’s already the most view topic since couple of days.
thanks in advance and keep the good work !
I don’t mean to interject where I have no knowledge…
But considering that you cannot have a local variable named the same as a parameter, can you not automatically create a traditional BP local variable so that we could use that? I’d be okay with it only doing this when you create a parameter, but not deleting it when a parameter is removed. That’d mean that you don’t need to handle old params, only new ones, but that we can benefit going forward until the better solution is found. Of course, I have no idea if that’s even feasible but I think it could be a temporary solution.
Yes, that sounds like a good solution. Just automatically create local variables with the same name automatically (in fact, that’s what I do manually for most methods for many months now). As it’s forbidden to create variables with the same name, I’ve to prefix them with a “_” (is ignored by the getter name anyway).
I wonder if it’s possible to vote for this feature (as it was backlogged despite the interest from the community in this)?
This suggested feature would be especially helpful for Call-by-Reference variables. As far as I know there is no alternative for having wires all across the function.
Aaaand another year has passed. Local variables coming from parameter values are still hidden.
Don’t know why is that so important. Never wanted to have such a feature, with reroute nodes no problem with parameter wiring. And also always can create local variable if it is needed. And also keep functions small - that helps a lot.
It’s a matter of convenience and UX.
If you have some data as function input it means you definitely want to use it inside function. If number of usage is higher than 1 and happens not right at the start - you would like to have it as local variable for convenient usage and clean looks. If it happens often(and it is) then such feature will definitely save a lot of time and improve UX overall. You can do it manually every time, but it’s really a nice case of useful automation IMHO.
Support for function parameters showing up as local variables in the context menu is coming in 4.16 (it’s already in the Main branch, after whichever copy-up included CL# 3251903). The functionality is a little rough around the edges (e.g., they only show up in the context menu and don’t show up in the variables tree, so no drag-dropping them), but it’s nice to finally have it in.