You can usually tell just by looking if a value will desync or not based on what it does:
Things that are direct game elements (timers, unit data, image data, etc.) will not cause desyncs if acted upon.
Things that seem to only have 1 value (meaning they are not an array of values for each player) and are not direct game elements (game timers), or are referred to by 'player' or 'current player' in their names (such as current player selection, player minerals, player name, etc.) will generally cause desyncs if acted upon.
There is no list (that I'm aware of) directly saying if they are client-only or shared, but I'm sure if you have any specific ones in mind somebody would be able to tell you. Also
might be of some use.
If you don't want it to desync or want to read another player's name, you can read from
table.
The addresses of the names for each player are (based on that EUDDB address; 0x0057EEE0 + (36 * 0-based player #) + 0xB):
Player 1: 0x0057EEEB (25 bytes)
Player 2: 0x0057EF0F
Player 3: 0x0057EF33
Player 4: 0x0057EF57
Player 5: 0x0057EF7B
Player 6: 0x0057EF9F
Player 7: 0x0057EFC3
Player 8: 0x0057EFE7
You will have to deal with the first 3 bytes if you do use these ... but using the EUDDB link provided it shouldn't be too difficult. Just in case it is necessary, I've outlined the process here:
Say you want to see if Player 1's name is 'Frosty'.
First you see that the memory address 0x0057EEEB begins on the 4th byte of Player -11551, which means the first 3 bytes are not part of the string and are something else (we'll get to that in a bit).
For now, we skip these bytes by replacing them with a filler value. I put "...Frosty" into the string chunk calculator (as seen
here).
Now we need to figure out what those 3 bytes actually are.
In our results we see "+0 ...F 0x462e2e2e 1177431598". The '2e2e2e' is the '...' we'd put as filler, so delete it and we get 0x46??????. Now we need to figure out what those 3 bytes are.
The first byte, 'Type' in the EUDDB, is the controller type of that player. We assume this player is human, so the value is 02 (as indicated in the EUDDB). Now, remembering that the first byte is at the end of the hexadecimal value, we have 0x46????02.
Next is 'Race'. We'll say Terran, which is 01. Now we have 0x46??0102.
Finally, the 'Team' (which I assume is force ... and appears to be 1-based). So we'll put 01 here. Finally we have 0x46010102.
Now converting that number to decimal, we get 1174470914.
Now just use this new value for the +0 ID ...
' F': memory(-11551,exactly,1174470914)
And the rest are just used as shown by the calculator ...
'rost': memory(-11550,exactly,1953722226)
'y ': memory(-11549,exactly,121)