I mean it is more of a learning thing, I personally would use this for other small games but more complex games a table inside a table just helps organize code later on. Not really a requirement for me RN so up to you personally.
Wrong, 100%. I donât really care to argue about it, profile service is not for someone new to roblox development. I wouldnât recommended to anyone. I use it only because its the best âadvancedâ datastore saving method. As I mentioned tables inside tables and dictionaries inside a table kind of hard stuff to get into. Anyone new to Roblox scripting opens up PS they will close right out of it. Because no one understand what the crap is going on in PS its impossible, until you learned quite a bit from things like EasyDS⌠Notice how I said nothing is better than the other, because if you donât like one DS method over the other just use a different one. PS is good, and this EasyDS actually is nice IMO. Noticed how I said my opinionâŚ
Kind of ironic considering tutorials exist for it
3 Likes
If I add tables inside of tables, it might start getting more complex.
For this reason, I am considering something like
module.deepFind()
which essentially loops through the entire data structure and returns the first item with that name (instead of having to do:
Module.get(plr, "CurrencyName").data.stats.gamesHistory.wins
you could just do
module.deepFind("wins")
1 Like
Ironic:
happening in the opposite way to what is expected
Find someone new, and I mean first weeks of coding, if they are using PS lol God bless them. Nothing is ironic about it having tutorials, I think you missed it completely⌠Tutorials donesât make anything âLessâ complex. Again open up PS module, no one, and I mean no one in the first week or two of coding or even month will go âYep, I understand everything about DS and PS now and those tutorials, yeah I can read every line of code and understand it.â Yeah⌠unless they are someone that has been coding lua for 5 years I doubt it.
I agree, keep it simple that is how people will learn when they first start out. The more complex we make it, the less appeal it has to help new scripters. If you add it let me know and I will test it.
Well guess what, people new to Roblox Development⌠have the ability to learn. Yes, ProfileService is advanced, but if you use horrible modules like this one, you first off, wonât learn anything, and second wonât have the ability to actually do advanced stuff. Along with all that, the author of this module has a horrible history, and continues to use AI in most of his code and responses. I have no idea what you find appealing in this plugin but you do you I suppose.
1 Like
can you give me some feedback on what you find in this plugin to be âhorrible?â This plugin uses the same fancy features as ProfileService and doesnât have any errors. While its not tested in mass due to it being new, all modules have to start somewhere.
Anyways, what do you find to be horrible?
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