[Bug] Cannot use same Local Variable name twice in two functions!

Try to use a Local Variable in a blueprint function and then create another function using that same name for another local variable. The system will not allow this.

Hey Tom-

Were both functions part of the same blueprint or were they in separate blueprints? What happens when you create a local variable in each function without renaming them? Creating a local variable should give it the default name of “NewLocalVar_0”. What name does the engine default the variables to when you do this in different functions?

Cheers

They were in the same blueprint.

I just tried this again and can’t seem to repro the warning. I guess you could mark this as resolved for now until I hit this again.

Glad to hear that things appear to be working for you. If you encounter this problem again let us know and we will investigate further.

Cheers

This is still actual, you can create same local variable names but you cant edit them.

Hey -

Are you creating the local variables in separate functions of the same blueprint or in different blueprints?

Same blueprint, two different functions.

What do you mean when you say you can’t edit them? I am able to create local variables with the same name in separate functions and then change the type, tooltip and category. Do you have any reference to the variables in the function?

18208-fnc.png

I only have references to OutPnt1 in function 1.

I assume then that you’re referring to not being able to change the variable’s type? Do you have any reference to the variable placed inside the function? Also, which version of the engine are you running?

Function with boolean OutPnt1 is an empty function, so the variable is not referenced anywhere. Engine version is 4.5.

Steps needed to reproduce.

1.create function 1.
2.add local variable named test.
3.reference local variable named test.
4.create function 2.
5.add local variable named test.
6.and now you can’t edit variable type in function 2

Having a reference to the variable in one function should not block the ability to edit the variable in another function. This has been bugged in our internal tracking system (TTP #349833) for further investigation.

Cheers

To anyone who’s facing this bug, do this to work around it:

Whenever you want to create a local var, after you hit the + button, before entering the name, first choose its type and only then rename the var to whatever you want. That’ll do until the bug gets fixed.

Disclaimer: There might be another bug lying around that will represent itself to your project if you go this way, waiting for official word yet. my comment right above this answer first.

Hey , since you mentioned this has been marked as bug, can you please confirm this issue related to it (or lack thereof):

One of my blueprints is so big, it has over 30 functions, which none can be converted to macros either, I am using the workaround I mentioned below as an answer, to workaround this bug for now, for instance I have maybe 8 or 10 local variables in them called bResult and TempIndex.

Now I am facing a logical bug in this BP, that I can’t for the life of me find any issue with the code, but it still doesn’t result as expected. I threw out every possible idea, except maybe having this bug with the local variables, also makes the engine confused about this variables that are having the same name, but are in different functions, therefor overwriting the wrong variable.

I wanted to see if you guys are aware of such issue or not, otherwise, the only thing I can think of is changing all those variables to have unique name through the whole project, just to see if the issue will go away or not.

Thanks.

I’m not sure it would be related to the same issue. You may want to start a new post with what it is that you’re seeing in your blueprint.

Adding more info:

A. The last version I tried this with is 4.5.0.

B. This is just a part of the function list that i could fit in the shot:


The logical bug (unexpected output) happens in the part which decides whether an item is connected to base or not, it includes this four funtions in the middle of the screenshot:

-Is Connected to Base
-Is Connected to Base Recursively
-Get Neighbour Index
-Has Opposite Dir

C. Just to be clear, I’m mainly a programmer, so I don;t expect you to to help me track down this issue in this project, I’ll take care of it one way or another, I’m only asking if you know this might be a result of the bug mentioned in this thread (that is having the same name for local variables in different funstions of the same BP).

Let me know if more info would help. Thanks.

Thanks for the reply , I guess I first try renaming all local variables to unique names, hopefully the issue will go away as I presumed, but in case it didn’t, I’ll post a new thread about it.

One question though before I close this comment here, this is the first time I’m trying a recursive function in the blueprint, is there any limits to call a function recursively in the blueprint that you might know? (the number of recursive calls isn’t too high to hit the call limit though)

This is a screenshot of this function that I wrote in UnrealScript for UE3, and am now trying to migrate to UE4, if it helps to see the way I’m calling the function:

http://img.prntscr.com/img?url=http://i.imgur.com/18EBIJs.png

I’m not sure what would be causing a problem there. If you do begin a new post, be sure to explain what you are expecting to happen and what is actually happening when you try to run the code/blueprint.

Thanks . Finally a few minutes ago, after 3 days I got to the bottom of this issue, the problem I was having is gone now and it wasn’t related to neither local variables nor recursive functions.

So what was the problem then? The problem is, ForEach continues to go through the elements of the array, EVEN after you return from the function, I mean what the heck?? (I fixed it for now with a silly method, using break on those for and foreach’s that shouldn’t even need one)

I posted a question here under bug report, though the guys who designed BP might consider it a weird but expected behavior. More on this in the question’s description:

UPDATE:
The above workaround is SAFE, use it without worry. The problem I was facing came form silly loops.