This is an unfortunate limitation of FName.
They are case insensitive and only store the first version of the string they find, so the FName “MyTHING” and “MyThing” are the same, but the FName will only ever show “MyTHING” since that was the first version it saw.
That is indeed very unfortunate. Thank you for letting me know!
Um… this is a bug that is filed and being fixed right? after deleting the asset and recreating a blueprint it still uses the deleted assets case?!? Looking at a deleted assets case seems like bad implementation to me.
I occasionally have this and it’s incredibly annoying, i have to make up completely new names for variables after accidentally using the wrong case. Just now i wrote “BallS” which should’ve been “Balls” for a public gamemode variable that gets used all over the place. I really don’t like this and it should be considered a bug.
I agree, it should be considered a bug. I’m now fighting with it when naming my assets and it’s, as Rens2Sea already stated, “incredibly annoying”.
I always end up adding an underscore to the end of the stubborn text.
This at least forces the system to see the string as unique and accept the change. I’d rather see an underscore than an undesired variant of the name.
We’ve made a change for 4.5 which will make FName case-preserving for the editor and UHT. This should address the FName case issues you’ve been seeing.
I’ve checked that you’re able to rename asset, actor, and blueprint components in a way that changes only their case. I’ve also tested that you’re able to have a variables in different UObject/UStruct types that vary only by case, and that the UHT will generate code that actually compiles.
As the Name is actually an ID used by computer, maybe there should be another parameter represents the nickname used by human, say, Name1.
If I remember correctly this solution worked for me:
Rename BP_New_ACtor to temp, then rename temp to BP_New_Actor.