That’s why you should put your data folder and its values into the Player itself or the ReplicatedStorage
1 Like
soo it’s not bad to put data folder with objects under player? it will not be performant heavy?
Putting each player’s data folder under their Player object would pretty much have the same performance impact, because it is the same data under the same game. It would, however, make it sorted per player, accessible to both the client and the server, and overall be a more efficient method than storing it in ServerStorage or ReplicatedStorage.
1 Like
Bare in mind the client would only read from that data - any modification would need to be done server-side for it to save the change properly.
1 Like
Nah it’s not bad as long as you store all data into a table when player is leaving to keep them safe, and it have no impact to performances… otherwise Roblox wouldn’t put the leaderstats folder and values into the player lol.
1 Like
As I have previously stated, placing the folder under the Player object makes it accessible both sides.
If you do use the folder method, make sure that you save the player’s data as a dictionary. This is easier as it only takes one DataStore, and if values get excessive, different DataStores for different values could be problematic in terms of saving data in time. The folder method is certainly useful in terms of accessing player data from both times, so I would certainly recommend it.
1 Like
If you don’t want a client to be able to see other players’ data, then sure, not parenting the stats instances to the player is acceptable.
However, I would advise you to use ProfileService over Instances in ServerStorage if not already. The method of data replication you’re seeking matches how ProfileService is used so might aswell use it.
Explanation
On the server, you’d have a ModuleScript with the functions Get() and Update() for server scripts to access.
On the client, there will also be a ModuleScript, but only with Get() for LocalScripts to access data.
When a player joins, a LocalScript will fire a RemoteFunction for the Server to return a copy of their table of data.
When data is updated on the server, it fires a RemoteEvent to that client to update their copy. This makes it so that the server and client have the table of the player’s data, and changes are synchronous.
If you insist, you can just apply this system with your Instances, both approaches are viable.
Caveats
However, with an approach to data being strictly kept and changed in a table, you naturally would need to use BindableEvents to detect changes in data, or even better - A Signal module.
YouTube tutorials will teach you how to set up ProfileService, but not how to let the client access it or detect changes. This is just the system I have thought of, and I’m not sure if this is the best way to go about it, but its certainly a reasonable way to do so.
1 Like
ok, soo profile Service uses remote event to send data when module on server is changed? if yes then for instance if we have game where player change for example coins every 2seconds, it wouldn’t be performance heavy? i know that remotes can get messy.
As far as I can think of, there isn’t a better way to replicate data to the client without using RemoteEvents. If you don’t like the idea of RemoteEvents, then sticking to Instances that replicate to all players seems like the only way to get around it.
Ok, i found a solution for me, i’ll use your idea from ProfileService, i’ll send remote with data that would change, for example
remote:FireClient(player,{Coins = 50}) -- in table we have a name and new value for coins
thank you for help
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.