Unlike names, strings are not case insensitive. However, strings are not replicated if only their casing changes.
Eg. if a replicated FString property has a value of “Hello World”, changing it to “HeLLo wORlD” does not replicate the new value.
Discovered this while changing player name by calling PlayerState->SetPlayerName() on the server, then fixing a casing mistake, resulting in the server seeing the fix, but not the clients.
This is actually normal and expected. The underlying replication code is using the == operator on FString, which is case insensitive.
Right, so that’s the cause. I still don’t see how it’s not a bug though. I don’t think players seeing different names for the same player is a minor thing. Or any other replication for that matter. I guess I’ll either have to change the engine code or rely on RPCs for string replication.
I think your idea of using RPC’s is a great one. It would be a lot more efficient. Replicating strings will require the replication path for that actor to compare each character of the string every time that actor is considered. With RPC’s, since you know when the name change occurs, you can take advantage of that knowledge, and only send when it changes.
I’ll bring this up internally though, as it’s definitely an interesting case. The only concern is when someone doesn’t expect the value to replicate when the case changes (maybe this is rare?). On the receiving end, if they use the standard equality operator of FString, it will still say they are equal, and that could be considered strange. I’ll definitely bring this up internally though.
Thanks for bringing this to our attention.