Access specifier magic in player state

If you look at the header for APlayerState you’ll see that the variable “Ping” is declared with no access specifier which would default it to private. This variable is a 8 bit value that contains player’s ping as a factor of 4.

Trying to access it in a C++ also makes the visual studio intellisense say that its inaccessible! which is correct as its a private variable of player state!

However when I access it in my C++ class (UserWidget) the code compiles without any errors and behaves accordingly. Its almost as if it was a public variable.

Is the PlayerState class Friend with other UObject based class or what? otherwise how does it break the rules of C++?

I suspect that the UPROPERTY() macro might have some generated access specifier.

unit8 Ping might not be private being “replicated” and “blueprint read only”

The UPROPERTY() macro can do its magic with inserting getter setters for private stuff, it doesn’t need to change its access specifier explicitly like this. Theoritically it breaks the rules of the language though coz anyone reading the source would be confused and Intellisense in VS gets confused too.

UPROPERTY() (and all other U-macros) is empty macro used only as a marker for UHT, it does nothing to C++ code

I looked on header file and Ping is public. Note that class i C++ by default is private and classical GENERATED_UCLASS_BODY() unlike GENERATED_BODY() macro adds “public:” and may confuse IntelliSense if UHT generated code is yet to be generated

UHT only does this for UPROPERTY() marked vars right? Well that explains it, I think its more of a logical error from the programmer where he should’ve listed Ping and other things like Unique ID etc as public or atleast have getters.

That said its just a minor nuisance for those who are not aware of UHT magic

Well yes , it does not do it during edit time in visual studio , but its expanded by UHT before the source goes to actual C++ compiler. So it only looks empty in VS because its definition is handled by UHT and is not visible to VS.

Can someone from epic please confirm this and the reason behind this pattern of coding in base classes?