Having finished my inventory saving system, it occurred to me that data loss may finally be an issue.
From my outdated and beginner Roblox Lua knowledge I’ve always saved stats in a folder in the player instance. This can cause data loss from a player crashing for example (or so I’ve heard).
I would like to know, is there a problem with creating the stats folder in the ReplicatedStorage/ServerStorage for example and having the server check regularly to see if the player instance no longer exists, then saving?
Alongside saves at regular intervals to prevent data loss should the server shutdown this should be a foolproof solution to avoiding data loss.
I’m aware of DS2 but I want to stick with using official Roblox resources.
1 Like
If you really want to stick with official Roblox resources then I suggest using the .PlayerRemoving paired with the :BindToClose functions to handle player leaving/servers shutting down.
I don’t see any downside to storing player data in ServerStorage or ReplicatedStorage and then waiting for the PlayerRemoving event to fire so you could find their data in server storage and save it.
As you said it would be a good implementation to add an auto save system which saves every x interval which can prevent data loss depending on your code.
I’d recommend ProfileService or DS2 but as you said you would like to use official Roblox resources which is completely fine.
1 Like
You should store a copy in the server, upon a player being removed try saving their data, if saving was unsuccessful then you will still have data and you can try again in periods till it saves.
Saving regularly is also important however you should not save too much. Saving upon massive progress, or if the player has earned a large amount of something you should save their data, do not save data every time the player gets a coin for example.
There is no point in using official Roblox resources, this is a big beginner mistake where they want everything to be made in vanilla and with their own. This is going to lead to your downfall and scripting crisis where you will no longer want to script. If it exists, and if it is highly rated, then take it. You should use DS2 or something similar in this case to properly save your data.
1 Like
The problem with the PlayerRemoving event is that all the stats are tied to the player instance so in case the pcall doesn’t work, repeating the attempt indefinitely would waste resources and the save cannot be attempted again unless there’s a copy of the player data on the server even after the player instance is removed. My main concern is whether there are issues with storing the copy on the server
Another quick addon, I used to be obsessed with making everything from vanilla, making sure it was all my code and just so on, it tired me out so much and it leads you nowhere apart from making a worse version of what I could have used. Using modules is amazing, if you want to code, make your small module loader, then add modules from there such as DS2 and tons more. Some are very useful!
You can check this out.
1 Like
When PlayerRemoving fires you can still access the players instance and their corresponding data with it, what I meant was when the player loads into the game you can create a folder along with all their stats as you would normally do in a player but this time in ServerStorage, you can name the folder the players userID.
When they leave you can index the players folder using their userID and access all their data for however long you need it and when your done you can destroy the folder.
I don’t see any downsides to storing a copy on the server, if your concerned about the amount of instances then you don’t have to have a copy but you can have only 1 folder stored in ReplicatedStorage instead of ServerStorage so that all clients can access the data if needed.
1 Like
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.