Author Topic: SetPlayerSave callback  (Read 3596 times)

devomage

  • Sr. Member
  • ****
  • Thank You
  • -Given: 7
  • -Receive: 67
  • Posts: 250
    • View Profile
SetPlayerSave callback
« on: January 01, 2018, 03:06:46 AM »
  1. TNManager.SetPlayerSave(path, DataNode.SaveType.Text);

It would be great if this had a callback!  Or is there a better way than the following?

  1. protected override void OnSetPlayerData(Player p, string path, DataNode node)
  2. {
  3.         base.OnSetPlayerData(p, path, node);
  4.        
  5.         if (p.name == TNManager.playerName)
  6.         {
  7.                 if (string.IsNullOrEmpty(path))
  8.                 {
  9.                      //SetPlayerSave callback
  10.                 }
  11.         }
  12.         else Debug.Log("OnSetPlayerData: name=" + p.name + " path=" + path + " node=" + node.ToString());
  13. }
  14.  

cmifwdll

  • Global Moderator
  • Sr. Member
  • *****
  • Thank You
  • -Given: 0
  • -Receive: 149
  • Posts: 285
  • TNet Alchemist
    • View Profile
Re: SetPlayerSave callback
« Reply #1 on: January 02, 2018, 08:12:32 AM »
OnSetPlayerData *is* the callback :P
If you're only overriding TNEventReceiver you don't need to call the base implementation (it's empty), but other than that everything looks good.

There might be a small bug with TNet regarding this callback though: it's called twice if using TNManager.SetPlayerData while connected to a server. Once during the call and another when the server sends its response. When using SetPlayerSave it's only called when the server sends its response.

Additionally, the callback is used for both SetPlayerData and SetPlayerSave which requires some state management on the user's part to properly handle it, but I wouldn't consider that a bug.

devomage

  • Sr. Member
  • ****
  • Thank You
  • -Given: 7
  • -Receive: 67
  • Posts: 250
    • View Profile
Re: SetPlayerSave callback
« Reply #2 on: January 02, 2018, 07:36:24 PM »
the datanode might possibly be rewrote and if that happens it would cause problems.

seems appropriate that 'SetPlayerSave' has a dedicated callback.

in my case, the authentication process relies on this flow.  if for some reason the player datanode was ever reset - the code would think authentication is happening when it shouldn't.

cmifwdll

  • Global Moderator
  • Sr. Member
  • *****
  • Thank You
  • -Given: 0
  • -Receive: 149
  • Posts: 285
  • TNet Alchemist
    • View Profile
Re: SetPlayerSave callback
« Reply #3 on: January 02, 2018, 09:24:08 PM »
Yeah, you'd need to add a boolean like "isAuthenticating" to your gamecode to properly handle the callback in that case.
I agree it makes sense to have its own callback or at least an additional argument in the existing callback.

acronyte

  • Newbie
  • *
  • Thank You
  • -Given: 9
  • -Receive: 0
  • Posts: 46
    • View Profile
Re: SetPlayerSave callback
« Reply #4 on: January 04, 2018, 09:41:02 AM »
I came across this issue in my project.... I ended up use 'if' conditions like so -
  1. private void OnSetPlayerData(Player p, string path, DataNode node)
  2.     {
  3.             if (mycondition1)
  4.             {
  5.                 //do stuff
  6.             }
  7.             if (mycondition2)
  8.             {
  9.                 //do stuff
  10.             }
  11.             if (mycondition3)
  12.             {
  13.                 //do stuff
  14.             }
  15.