OnPlayerSync not working?

[nah0y]

Hello!

I've just tried to use the TNManager.playerData with DataNode to synchronise some player data. It's perfectly working, but the issue is that in the release notes, you said: "if you wish to be notified, assign a delegate to TManager.client.onPlayerSync: TNManager.client.onPlayerSync += YourListener;"


The thing is that this callback is never sent. I've checked the packages, it's sent (it goes through the send method), but is never received.
Also it's kind of "annoying" to use += etc for this, because all other TNet callbacks are just accessible via simples methods like OnNetworkPlayerRenamed, can't we do that for OnNetworkPlayerSync?


Thanks!

[ArenMook]

Player sync messages can be quite frequent depending on how you're using that feature, while players joining or leaving the channel or renaming themselves are going to be pretty rare.

I have been sitting on an updated version of TNet for a bit -- haven't had a chance to push it out. You can ping me on Skype and I can send you the latest to try.

[nah0y]

Thx for the latest version, but it does not fix the issue.
After looking at how Packet.RequestSetName and Packet.SyncPlayerData are handled, it seems that in the case of RequestSetName, you also have a ResponseRenamePlayer and not for SyncPlayerData.

Inside TNGameServer.cs, I can see that Packet.RequestSetName will send back the player name in another packet (ResponseRenamePlayer), using :

1. BinaryWriter writer = BeginSend(Packet.ResponseRenamePlayer);
2. writer.Write(player.id);
3. writer.Write(player.name);
4.  
5. if (player.channel != null)
6. {
7.    EndSend(true, player.channel, null);
8. }
9. else
10. {
11.    EndSend(true, player);
12. }
13.  

But there is nothing like that for SyncPlayerData.
So I've modified the case Packet.SyncPlayerData by adding at the end:

1. BinaryWriter writer = BeginSend(Packet.SyncPlayerData);
2. writer.Write(target.id);
3. writer.WriteObject(target.data);
4.  
5. if (target.channel != null)
6. {
7.    EndSend(true, target.channel, null);
8. }
9. else
10. {
11.    EndSend(true, target);
12. }
13.  

And it's working using that.
Is it a mistake, or something I don't understand?

Thx.

[nah0y]

Okay, I think I found where the problem is.
Looking at the code, it seems there is a :

1. else if (target != player)

and

1. if (tp != player)

So you're sending SyncPlayerData only to other players

But the thing is, I'm using the onPlayerSync callback to update UI with player data, even for myself :/
In the current configuration, if I want to update the UI for myself, I have to add some code, which is not the case for playerRename etc...

Do you think it's something that can be changed in TNet? Or you designed this specifically like that for a very important reason?

[ArenMook]

Simple reason is I don't want to receive my own outdated player data.

Take this for example:

1. Player has 100 gold. You add 1 gold using the current value from the player's data and adding 1 to it. You than send out this new data.

2. Shortly after, and before you receive your own packet back, you do it again. Now the value is 102 gold.

3. Now the packet you sent out in #1 arrives back, changing your player data to be 101 gold as that's what was sent out. You've effectively overwritten the latest value at this point.

4. You repeat the process again, adding '1' to the latest data, which because of #3 happens to be 101. You get 102, and send out the data.

5. You get 102 from #2, then 102 again from #4. And yet you performed addition 3 times, so you should have 103!

My current approach where your own data is not echoed back to you avoids this problem. You could add "if (onPlayerSync != null) onPlayerSync(mTcp);" to the end of TNet.GameClient's SyncPlayerData() function, but it seems redundant to do so. You know when your own data is changing. You can already call your callback yourself if you need to.

[nah0y]

Hello!

Thanks for the explanation of this post (didn't had the chance to spend time on time since you answered...), but I just saw you updated TNet with :- NEW: TNManager.onPlayerSync and TNManager.SyncPlayerData().

Does this mean you added what I wanted?
If yes, why did you changed your mind?

[ArenMook]

Sort of. You will get the notification for consistency's sake, and it will happen as soon as you do a sync. There is no delay, no waiting for the packet to be sent/received. It's just a local echo for consistency.

[nah0y]

Perfect