The logic inside of the script, such as the joined even and leave event should not be placed inside of the module script. This is because the module script is meant for functions, not handling events. so you are wrong, and the original approach was correct.
Personally, being a bit biased as I am the creator, I disagree with this statement due to the simplified nature of Easy Datastore and its emphasis on reliability. Basic datastores cannot achieve the same affect as Easy Datastore without going out of your way to support the best practices.
base datastores dont lose data unless roblox’s servers lose data
what happens is people dont do proper error handling and wipe datastores if they return nil for some reason instead of doing the right thing of preventing further datastore reads and writes
Module needs a lot of work before anyone uses it seriously.
Some criticism, some of it copied from here (but is still applicable to this module):
You don’t check if the data successfully loaded before saving it in PlayerRemoving. This means if the player joins the game and their data fails to load then there’s a chance it will save when they leave.
I verified this by setting my coins to 300 and then leaving to save it. Then I added an error inside of your PlayerAdded function in the pcall containing GetAsync. Afterward, I joined the game, loaded 0 coins (default amount), and left the game, which overwrote my data. My coins were still 0 even after I removed the error.
There’s no autosaving, if the server crashes then players will lose their data. BindToClose is not sufficient in the case of a hard reset.
There are random task.wait(n) lines added throughout the script. These don’t serve any purpose except to make the module slower.
There are a lot of code smells here, particularly several loops that wait for some value, i.e:
repeat task.wait(.1) until serverPlayersData[plr.UserId]
repeat task.wait() until serverPlayersData[plr.UserId]
module.devide is spelled incorrectly, it should be module.divide
All functions should be properly documented as this is a community resource. Additionally, types should be added to all parameters.
Thank you for the feedback. I will be exploring the playeradded error handling soon.
Purpose: waits for the player to be fully loaded into the module. I am going to improve this system by canceling the wait after a certain amount of tries
repeat task.wait() until serverPlayersData[plr.UserId]
Autosaving: Instead ot implementing autosaving, i plan to make a function called module.save() which is the developers responsibiliy to call after major events. Im doing this for multiple purposes:
Priotizes critical data to be saved and important events in contrast to autosaving which is time based
Reduces overall request count, improving game preformance
Adapting better to the game’s needs rather than constant updating
For autosaving, i will batch requests as such:
When a developer saves, start a 1 minute timer
If module.save is called within the 1 minute timer, it wont save but instead it will wait for the 1 minute before authorizing the save.
In responding to other players saving requests, i will create a “line.” Which will go through all the save requests and authorize the oldest request before removing it from the line. There is a delay between each save in the line to ensure that the autosaving abides by roblox’s guidlines well
Just a heads up, this thread is extremely misleading.
Not only are there numerous practices in which should be avoided or aren’t implemented, see the responses above- but this is also just more or less straight lying.
Microsoft does not officially recommend anything in which you have made. You are simply taking an output from microsoft’s artificial intelligence and saying that’s them endorsing and or recommending you.
Thank you for giving me feedback, but I disagree with you. My script currently uses the best practices in Roblox.
If there is anything missing, please let me know. I’ve adressed all previous concerns and added them through the implementation.
As for the title, the goal is to catch your attention. But the main focus is the datastore module. So what feedback do you have on the datastore module not the post?
You do realize, it’s only recommended because it’s what it found for the most recent result(s) right? This compares no where similar to ProfileService.
Your version is simply the same update loop which could be turned into a function, even then is a “basic” datastore system, nor would I use a module for this. At most, I’d change the title to basic datastore class or something.
Incredibly misleading post.
Does not work as intended
“Best practices” would involve not using AI, and knowing when to use functions
A side note, falling on AI for anything is incredibly unreliable. You’d much rather listen to a robot, rather than a community full of Developers that are knowledgeable within various aspects.
By all means, take what AI says with a grain of salt.
I appologize it seems there are misunderstandings. The module is an extremely robust and easy to use datastore module.
all of the previous replies, such as the one you quoted, are outdated and have already been adressed.
Furhermore, you are incorrect in your understanding of the autosave functionality of easy datastore. Easy datastore requires you call the module.save() function for autosaving whenever a major event has occured. This have multiple benefits in contrast to the autosaving system you suggested.
Easy datastore uses all of the best practices and is created to have an extremely low learning curve. It is efficient to use as you only have to call the three main functions to get it working:
Errr, I’d much rather use my own autosave function. ProfileService is Robust… as in, I can create my own function, and retrieve a Profile with Data content as needed, versus running a yielding GetAsync per data retrieval. (another disadvantage here)
And yet again you’re still using AI for responses… why?
I appologize but it seems like you do not understand how easy datastore works, yet you spread misinformation so confidently.
i recommend you check out the code for easy module before giving feedback about incorrect functionality.
To clarify for readers, getAsync() is only called once per player
In the case if failures, it will attempt to recall the data for 5 attempts. You can edit the amount of attempts and the time between them in the module.
There are still failsaves and recovery systems for data in the case of all 5 attempts such as using module.save(). Module.save() not only autosaves the data for your users, but also checks if the data you player currently has is outdated. If its outdated, it will assign them the correct data!
This functionality prevents both invalid data from overriding existing data but also automatically fixes invalid data during run time!
Both they and @KrimsonWoIf have lied in the past, and even to me it’s still impressive how @KrimsonWoIf is liyng so hard on the DevForum.
The Roblox DevForum is mean’t to be a formal place to ethically share your creations, discuss about development, help others and report bugs/requests. (I searched in the DevForum Rules if it’s not allowed to clickbait, and haven’t found anything. But I have to clarify the DevForum is not mean’t for this type of lies.)
At least @KrimsonWoIf renamed to make it not considered ‘liyng’, that’s acceptable I think.
AI responses do not equal endorsement, I don’t know where you get that from.
AI is built on machine learning, which means it will say whatever it’s fed from a large database such as the internet, it never means that Microsoft endorses your module.
I could convince the AI to support war crimes, by your logic that would mean Microsoft also supports war crimes.