Author Topic: A few questions (ChannelData, TNObject Data, DataNode, Custom Files)  (Read 434 times)

nuverian

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 1
    • View Profile
Hello there,

First of all, I have to say that TNet is great. It's easy enough to use, yet powerful to delve deeper.
After using it for a while though and implementing it into our game so far with success, I came by a few questions.
Our game by the way, can best be described as your typical coop survival genre (crafting, building etc). Think "The Forest".

- ChannelData
So, I understand that ServerData is saved in server.dat and PlayerData is saved in player.dat for example, but I am don't really understand where are ChannelData saved. Shouldn't they be saved in a file like the others, or are they rather buffered RFCs ? Shouldn't there be a SetChannelSave similar to how SetPlayerSave exists for example?
What I am after here more or less, is to save the "game" state/data, that is not really tied to either of the players. Such things as the buildings we've build, the common items in our inventory chest, or the resources left on each mine deposit.
I could probably use the hosting player's data, but I thought that ChannelData would be a better (and cleaner) fit for that, or am I misunderstanding something?

- TNObject.Get/Set
Similar question to ChannelData above, are TNObject data, buffered RFCs as well? If so (which I think is true) can they somehow be saved to a file on the server?

- Arbitrary DataNode / JSON File
I see that there exist a very handy TNManager.LoadFile / TNManager.SaveFile already, so I am thinking that I could use a custom DB-like file for saving the game/world state, either in JSON or DataNode format and would probably prefer DataNode so that serialization stays the same to the rest of TNet. In both cases though (JSON/DataNode), I would like to save the file in text format so that they stay human readable and editable. As far as I understand though, using LoadFile/SaveFile is not possible for text format. Is there any other way already provided?

As you can tell, I am after an (as much as possible) data driven approach, where all saved data can be found as editable files on the server. Considering I didn't misunderstood anything about my 1st and 2nd question, using a custom DB-like file, seems to be bypassing some "data persistence" TNet features, but I think that having half data stored as Player DataNode files, while other data simply as buffered calls, will become a bit unmanageable in the long run, and I would much prefer to keep everything in one place.

--

- Bonus Qustion :) Common Objects
Now this is a noob question probably, but are there any best practices to handle TNObjects that are neither static IDs, nor are they tied to any specific player. They are rather objects instantiated from one player, but where all players are able to use it the same, like once again for example, a crafted chest of common among player items.
My question mostly concerns data, as per my previous questions, but also any other idea, thing or feature that I should be aware of, is more than welcome :)


Once again, TNet is really great. I just need to bypass this "data persistence" issue I am facing :)
Any thoughts, directions or suggestions are very welcome.
Thanks!
« Last Edit: January 28, 2018, 12:20:22 PM by nuverian »

cmifwdll

  • Global Moderator
  • Sr. Member
  • *****
  • Thank You
  • -Given: 0
  • -Receive: 149
  • Posts: 285
  • TNet Alchemist
    • View Profile
Re: A few questions (ChannelData, TNObject Data, DataNode, Custom Files)
« Reply #1 on: February 10, 2018, 11:59:07 AM »
Channel data is saved in server.dat (can also be named world.dat, or whatever you specify as the -fn arg when starting the server). I think saved RFCs should work for what you need (just send the RFC with Target.AllSaved, Target.OthersSaved, etc etc). Server data could be a good place too, it really depends on how you want to organize it. Just remember: if you run multiple instances of the server from the same executable, you should pass a different -fn argument for each instance so they don't accidentally use the same .dat and .config files (unless you want that behaviour).

I've never used TNObject.Get/Set. Looking at the code, they do use Target.OthersSaved so they will be automatically saved as channel data.

There's an overload for DataNode.Write that accepts a StreamWriter. If you have a MemoryStream as the backing stream for the StreamWriter then you can call MemoryStream.ToArray() to get a byte[] that you can pass to TNManager.SaveFile. Aaaaaand I just realized DataNode has a ToArray function that does exactly as I described. Yeah, much easier. You can specify SaveType.Text too.

But using TNManager.SaveFile/LoadFile in place of TNet's existing save system is creating additional work for yourself. It's functionally no different than relying on saved RFC's or channel/server data, only that you're recreating a big chunk of the wheel. Channel / Server data use DataNode's as well and are saved exactly the same way, but it's done all automatically for you. You will be stripping away a huge chunk of TNet's power by not using any saved RFCs or channel/server data.

For your bonus question:
Instantiate it as you normally would, but specify that it should be persistent. This ensures that when the player that instantiated the chest (crafted and placed it) logs off that the chest will remain there for others to use. Its inventory can be synced and saved using saved RFCs.


TNet has great data persistence out of the box.