Wouldn’t this contradict your earlier statement about how using 1 out of 50 data store SETs every 5 minutes was somehow bad for roblox to handle?
Or do you just change your mind when it suits your view?
1 Like
My friend, you seem very upset, can I help you with that? You can talk about it, just don’t let it all out at once lol. Honestly speaking, opening up this module script and going through it was very appealing. You fail to understand the name of this datastore completely. Can you tell me what it is called? EasyDS… You are missing it on so many levels, you might just be on Mars at this point. I just personally would never recommend PS to someone EasyDS all the way. Now later on in the world if they are asking me if they should use PS to code pets, save parts or buildings, and more complex data saving then we can talk about PS. For now EasyDS… come on man its in the name.
Hey, TheRealWayMan, I’m considering adding @Heimskeet 's suggestion for constant autosaving but I have some concerns and I want to hear both of your thoughts on them:
Pros for constant autosaving:
- Roblox appears to have a large limit for requests per minute
- It could be less work for both new and experienced developers using the plugin
Cons (potentially)
- Even though they allow you to send a lot of requests, it feels simply just unoptomized to send constant requests.
- While their limit is large, that doesnt mean it wont impact preformance but I am not sure how much.
- I know that roblox promotes games that preform better via their metrics page.
- module.save() could engage new developers with concepts like data saving slightly more
Anyways, what are your thoughts? Do the pros outweigh the cons?
This thread has gotten argumentative, that’s not the spirit of this forum. As for the module, I have some criticisms you really should address. I looked through your claims as to why this module is better than Datastore2 or ProfileService, but I’m going to address those here too.
The first thing I tested is whether or not your systems handle 403 forbidden errors (Studio will throw this if your studio place doesn’t have API access turned on.) You can detect 403 errors, and if you detect a 403 error you should stop the module from trying to function entirely. Its a fairly minor thing, in fairness.
It seems like the module does work to save data, which is the goal, I’ll give it to you. But better than ProfileService or DS2? No, definitely not.
The first reason you listed is cache loading, which is unnecessary and inefficient. The way ProfileService (and I think DS2 as well, idk i don’t really use it) handles this issue of repeated joining and leaving is called session locking. It also stops one server from loading the player’s data while another server has it loaded. Overall, just a safer option. I could be misunderstanding how your code works, but that is how I read it.
The second reason you said that this is better than other data alternatives is error handling. This is not special, as all of the alternatives you listed internally handle important errors.
The third thing is just a dev’s choice on whether or not they want it. Not sure why that’s an advantage, I see no additional benefit.
The fourth thing is avoidable by not autosaving, autosaving is not necessary. You can just save their data when they leave, or when the server closes.
The fifth one is just inaccurate. That isn’t compression, that’s encoding. You CAN compress encoded data, and I’d be happy to provide you with some resources to actually compress the data. A warning about compression tho, it has to be perfect, or it won’t work perfectly and you risk data loss or falsification.
The sixth thing is basic data management practice, it isn’t an advantage of this module.
The next one is the seventh. Like I said in #5, autosave while in game isn’t even necessary.
I’m not sure what you mean by the 8th thing. If you’re properly handling data, there should not be issues on the runtime. Evade has not had data loss issues, and we don’t have something constantly “fixing” data on runtime. If you could explain this a little bit more so I understand what it’s actually doing, that would be great.
These are my criticisms and questions about this module, and I respect you for trying to make another database alternative for beginners. I just think it doesn’t have any advantages. Yes, you have made an easier and more beginner friendly datastore module than ProfileService. Better than ProfileService though? No. There’s a major difference between being a beginner’s resource and being better.
Edit: I also don’t think your database is easily updatable with new data for existing users. Correct me if I’m wrong. That is one advantage of profile service and its reconciliation function.
1 Like
To clarify advantages wasnt the advantages over alternatives, it will the “fancy” features of the module itself.
-
Autosaving is used by all major modules. My autosaving, however, requires you to use module.save() after major events. In the event of a server crash, a server can close before being able to process player-removed events. This is why having some kind of autosaving mechanic is essential
-
In clarifying how my datstore “recovers data” during runtime is through the save() function. Within the same function when I call updateAsync(), I use it to check if the current data is outdated. This system both ensures that existing data isnt overriden but also that the current data represented in run time is accurate.
-
Caching is more efficient because it temporary stores the data when a player leaves, and automatically assigns them the data without having to make another datastore call. To note, this isnt supposed to be an alternative to session locking but I will get there.
I am interested to hear some features as it seems you are knowledgeable about some aspects:
-
You mentioned session locking. Do you have any idea on how I can do this without taking up a lot of resources? When I think of such a thing, I think of something like messagingservice to do this. Can you help me figure out how I would incorporate this?
-
You mentioned being able to provide some resources from compression. I would really enjoy if you did that, and thanks for the help!
So for session locking, there are a lot of great resources for it, but i highly recommend this one. It explains fully in depth how it works.
As for compression, I highly recommend squash, it’s a great resource for true data compression, but like I said use it with caution.
- Caching is more efficient because it temporary stores the data when a player leaves, and automatically assigns them the data without having to make another datastore call. To note, this isnt supposed to be an alternative to session locking but I will get there.
Responding to the above, caching just sounds like you’re creating a memory leak. You’re unnecessarily using more performance than just unloading the data and reloading it if they rejoin. There’s a good chance they join onto a different server as well, where the cache won’t even be helpful. Ironically enough, I’m pretty sure this actually makes your system MORE vulnerable to a malicious abuse. Someone could just load their data, even completely unintentionally, onto like 90 servers.
Then just do the template system having folders can sometimes have loading issues with could easily screw up the process.
template = {
Coins = 0,
Gems = 0,
}
Just because this datastore is easier doesn’t mean you have to lose features of other datastores. Just because there are tables inside of tables and it might get a little more complex doesn’t mean you should disclude it, I think it would be better if you made this a beginner datastore module for extremely new scripters to datastores, not a competitor to profileservice but like a baby’s first toy, this would make the actual existence of this module make atleast a little sense and probably end the current arguement.
Future Projects / Off Topic
For your future projects please try to avoid drama and using AI, it’s just going to make you seem worse (which you already are pretty bad) and have even more people hate you then the current amount of people that already hate you.
1 Like
I wasn’t gonna say these things cuz I didn’t want to seem like a jerk but yeah I fully agree the module is pointless. You are far better off learning ProfileService the correct way the first time rather than having to relearn your entire concept of databases.
As mentioned, data is not retrieved from folders, it is retrieved from the datastore and stored/retrieved/managed as a dictonary
If you read what he said, he was saying that even your method of config is fundamentally flawed. You can do it with a table, like I show in the attached image here. Funny enough, your method is actually MORE complex than how ProfileService does it!
I dont think its appropriate to use language like “completely useless” and “fundamentally flawed” as when I hear others using such terminology on my creations, it makes me become defensive and feel personally attacked. Instead I think it would be constructive to provide feedback respectfully. Even if its true, its still better to communicate efficiently without involving emotions.
For your suggestion of creating a table structure like the one you said, the only thing I am really worried about is that it may make the module less easy for new players. However I think your approach can also offer more flexibility so I am seriously considering it.
@TheRealWayMan I dont want to make any changes you disagree with though. Do you think that instead of the folder system we should change it to using a table they must create within the script?
1 Like
I will use the terminology that I choose when I’ve worked with databases, both on and off platform, for years. Your module is fundamentally flawed. It is not helpful, and anyone who uses it later on will have to re-learn their entire concept of datastores. The table structure will effectively make it easier for new players, its unironically harder to use the folders.
1 Like
I understand you’re very blunt on the issue. To emphasize my suggestion regarding your terminology wasnt to say that your communication isnt already effective, but that it can be enhanced through respect.
You can still include the table structure infact its actually better cause it will help the newbies learn how to make datasaving with profileservice or almost every other datastore
Also I have 0 clue why you decided to rant about us saying fundamentally flawed because it is quite honestly the truth and could actually really depend on the roblox servers since you are in reality saving data through memory not just the server
There is just a level of professionalism, intelligence, and maturity that comes with being respectful. While the phrase “fundamentally flawed” is effective at conveying critical information, it can be enhanced in tone to be less aggressive.
If we are gonna mention “professionalism, intelligence, and maturity” does using AI for responses, scripting and design for advertising fall under those categories?
6 Likes
You spelled “Setup” wrong in your initial documentation, don’t bring up intelligence as a reason for us to not state our opinions of your module
3 Likes
I have clearly expressed that I am not comfortable with imprudence and dismissiveness in our discussion, and in response, I have merely been further dismissed through insults pertaining to trivial issues. For this reason, I will not be responding today. I hope to see a more professional and respectful environment in the future.
Could I get those resources please. Thank you :)
I don’t know if anyone has stated in your post already but I highly recommend for you to not use
repeat task.wait(sometime) until something
I see you doing this a lot in your data store module
As this is bad for performance, instead you should be using RunService.
I have a real quick question here, I think you should stay consistent when it comes to organizing your script, I’m kind of confused here why you added a bunch of blank lines in the middle.
1 Like