#How do I sync TMP texts? I want to
1 messages · Page 1 of 1 (latest)
NetworkVariable<FixedString32Bytes> playerName = new(string.Empty,writePerm: NetworkVariableWritePermission.Owner);
public TMP_Text playerTag;
public override void OnNetworkSpawn()
{
if(HasAuthority)
playerName.Value = new FixedString32Bytes(AuthenticationService.Instance.PlayerName.Split('#')[0]);
playerName.OnValueChanged += OnPlayerNameChanged;
OnPlayerNameChanged(string.Empty, playerName.Value);
}
void OnPlayerNameChanged(FixedString32Bytes previousValue, FixedString32Bytes newValue)
{
playerTag.SetText(newValue.ToString());
}
}
I don't use NetworkSpawn, because there is no spawning done in the scene right now. All I do is serialize the string with Inetworkserializable, then assign a playername, and then make a server rpc send the TMP's text through.
@plucky river what would you do in this case? Is this a bad code principle right here?
RPCs have to be in a network behavior on a spawned Network object. So it needs to be spawned regardless of RPC or Network Variable
Well, right now what I do is just have 4 objects (networkObjects) and whenever a player joins, it sets 1 more active.The script itself is NetworkBehaviour, so what am I missing?
I probably have to spawn the object but do I have another solution?
no, it has to be spawned if you are sending data
You could use Custom Messages if you don't want to deal with Network Objects
A brief explanation of Custom Messages use in Netcode for GameObjects (Netcode) covering Named and Unnamed messages.
I'm fine with NOs I believe, I just don't understand how could I spawn the object when it is already on the screen? Do I just spawn it on awake as a one-liner?
also keep in mind that late joining clients will not get previous RPCs or Custom Messages
In scene objects are automatically spawned
I won't have late joining in my game I know that thanks.
Then why is the RPC not going through I wonder?
Do they have to be a prefab?
just make sure that you are loading the scene with NetworkManager.SceneManager
Well I have only 1 scene.
If they have to be a prefab fine, but they're not. They're just called 'LobbyPlayer' 1-4
They don't have to be
https://docs-multiplayer.unity3d.com/netcode/current/basics/scenemanagement/inscene-placed-networkobjects/#using-in-scene-placed-networkobjects
If you haven't already read the Using NetworkSceneManager section, it's highly recommended to do so before proceeding.
Let me read this through
Okay so apparently the RPC now runs (it didn't run before) but the text still didn't change
For the host if the name is WASD and the client its ASD, it shows on the host that both names are WASD on the client, both are ASD
If your Lobby players are scene objects they are all owned by the Host. You will need some way for the client to send its name to the host so the host can assign the proper name to that Lobby Player
But it seems I'm doing it wrong I believe
ServerRPC should work. Make sure you aren't using any Sinlgetons. That tends to not work well with networking
ServerRPCs don't really work, maybe its just me being silly.
I'm not using any singletons
You need to send the playername in the RPC
Seems to not do anything else
playerNameText needs to be set to the playerName that the RPC is sending and not the public one in the class
I'm sorry I don't understand this statement.
this code is grabbing whatever playerName is set locally. The client needs to send its playerName as a parameter in the Server RPC to the server
This was my code
That should work. You don't need the isOwner check unless this was spawned as a player object
Well the way this works is on the host both lobbyPlayer names are the same, on the client both lobyPlayer names are the same as well, but the names are different
But where should the serverrpc be located?
Inside the LobbyPlayer script or a manager script?
It needs to be on the lobby player object that has the text element
It could be on a manager object if that manager is also keeping track on lobby players and their nam
Well, it is, I don't know whats causing the issue that the name is the same on the host and the client
Can I somewhere find a sample or a video where they explain or I can look into this @plucky river ?
You can check out Code Monkey's Complete Multiplayer Course. There is a lecture on RPCs
Yeah I watched the full stuff and did it like months ago
Guess I'm gonna watch it again
But he doesn't sync this particular case
I found the problem @plucky river . The problem is that The PlayerData.playerName is always the Host's name which is weird.
Other than this, the RPCs and everything works. I just don't know how the playerName is the same for all (btw I'm using Lobby, and the OwnerClientID is 0 on both instances because I test it on the same pc, however I have different names setup in the lobby player settings)
For in scene objects the owner client ID will always be 0. normally you would spawn lobby players in dynamically so they have the correct owner.
PlayerData.SetPlayerName() looks like a static function. that will get overridden when each player name you set
Yes you were right! I solved it before reading this but nevermind
Now there is just one issue left, the testing. Whenever I try to test with parrelsync, it says that the player is already in the lobby, and the ownercient id is 0 in both players
You need to change the Authentication Profile when using the same PC to test.
try updating to NGO 1.11. I belive there were some fixes to FixedStrings
How do I do that? Thats not a stable version?
That is still 2 or 3 versions behind the most recent stable version. If you are not seeing in the package manager then you can add it by name and specify the version number
I don't use that version because it generates various problems and errors for me. The last problem I believe is that both OwnerClientIDs are 0 but the profiles are different. Can that be a problem?
I still think that this Ownerclientid problem generates that error.
Have you ever met this error?
Not since updating to Unity 6 and NGO2.0. There was an issue with using Fixedstrings in network variables but it's was fixed a while ago.