May I use "PlayerID" as my ustruct member variable name?

[TimGS]

If I use this name (PlayerID) as my struct member variable name, then in ModuleName.generated.cpp i get this generated line:

UProperty* NewProp_PlayerId = new(ReturnStruct, TEXT("PlayerId"), RF_Public|RF_Transient|RF_Native) UIntProperty(CPP_PROPERTY_BASE(PlayerId, FPlayerData), 0x0000000000000000);

instead of:

UProperty* NewProp_PlayerID = new(ReturnStruct, TEXT("PlayerID"), RF_Public|RF_Transient|RF_Native) UIntProperty(CPP_PROPERTY_BASE(PlayerID, FPlayerData), 0x0000000000000000);

and this causes error about that my struct doesn’t have PlayerId member.
Is this some kind of engine restriction or is it a bug?

[Jamie_Dale]

That looks like an FName issue.

Unfortunately, due to the way FNames work (which is what the UHT uses when parsing those variables), if it sees a variable called PlayerId before PlayerID, it will always produce code using PlayerId (as FName is case-insensitive, and not case-preserving)

Using PlayerId as your variable name should “fix” the issue for now.

• When creating UStructs sometimes the compiler chokes on certain variable names - C++ - Epic Developer Community Forums
• Renaming Blueprint with same name but different case does not work - Blueprint - Epic Developer Community Forums
• [BUG] Blueprint editor does not allow renaming a variable if there is only case change - Editor Scripting - Epic Developer Community Forums

[Jamie_Dale]

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.