If you use bing AI and you dont trust that was a real response, simply give this prompt:
“Write me a datastore script using the best practices”
Compared to the competitors, my method of autosaving in the Roblox Easy Datastore module is superior. First, the module requires its developers to strategically place module.save(plr) calls in major events to accommodate various gameplay types. Compared to the continuous autosaving every X seconds, my approach is more optimized and simply better.
The following are the main advantages over the competition when important events are prioritized:
- optimizes the use of resources in your games.
- I also reduce pointless calls.
- It guarantees that important data is preserved, contributing to a more selective system in the event of a crash.
Certainly! When creating a datastore script, it’s essential to follow best practices to ensure reliability, efficiency, and robustness. Here are some guidelines to consider:
1. Singleton DataStore Instance:
-
- Never create more than one instance of DataStore for a given file in the same process. Doing so can break all DataStore functionality1.*
-
- Use a single instance throughout your script to manage data.*
2. Immutable Data Types:
- Use a single instance throughout your script to manage data.*
-
-
The generic type of the DataStore must be immutable1. This ensures consistency and prevents accidental modifications.*
3. Avoid Mixing SingleProcessDataStore and MultiProcessDataStore:
-
The generic type of the DataStore must be immutable1. This ensures consistency and prevents accidental modifications.*
-
-
Never mix usages of SingleProcessDataStore and MultiProcessDataStore for the same file1. Choose the appropriate type based on your use case.*
4. Cache Loading:
-
Never mix usages of SingleProcessDataStore and MultiProcessDataStore for the same file1. Choose the appropriate type based on your use case.*
-
- Implement cache loading to prevent malicious users from slowing down your servers.*
-
- When a user leaves your game and rejoins quickly, load their data without making a datastore call. This prevents attacks and keeps your game efficient.*
5. Error Handling:
- When a user leaves your game and rejoins quickly, load their data without making a datastore call. This prevents attacks and keeps your game efficient.*
-
- Manage errors through a series of attempts.*
-
- By default, the module will repeat calling for the data up to 5 times. Adjust this inside the data script as needed.*
6. Efficient Data Management:
- By default, the module will repeat calling for the data up to 5 times. Adjust this inside the data script as needed.*
-
- Store all data within the same script that saves it.*
-
- Sets you call are stored during runtime and saved only when players leave the game. This allows for quick and efficient data saving.*
7. Anti-Data Corruption:
- Sets you call are stored during runtime and saved only when players leave the game. This allows for quick and efficient data saving.*
-
- Before saving player data, check if the data is accurate through updateAsync.*
-
- Compare the time players first join your game with the returned updateAsync values to avoid overriding existing data with less data.*
8. Encryption and Decryption:
- Compare the time players first join your game with the returned updateAsync values to avoid overriding existing data with less data.*
-
- Utilize HttpsService:JSONDecode and HttpsService:JSONEncode to save space within your datastores.*
-
- Encoded data generally takes up less storage, allowing for a more robust system.*
9. Bind to Close:
- Encoded data generally takes up less storage, allowing for a more robust system.*
-
- Use bindtoclose() to save data in the event of a server structure.*
This is what it wrote, I don’t think Singleton DataStore Instance exists.
It looks like it is influenced by my script. For example it mentions
which is referring to my module.
honestly id rather use my own module or the straight api than anything else
1 Like
thats a valid approach. Just remember that my module uses the best practices and is currently superior to all its competition in its autosaving approach.
i doubt that that is true
they probably used the same AI you did
If you doubt its true, do you have any specific examples of how its false?
Doubt and equals are very different. My module has set new standards for best practices that other modules simply don’t compete with.
My module is innovative, secure, robust, reliable, and, most importantly, extremely easy to use.
The entire code consists of only 3 lines:
Module.get()
Module.set()
Module.save()
Yet it outcompetes competition in its effectiveness and reliability.
let me know if you have any other questions about Easy Datastore! I value your contribution to the module!
You keep saying they’re the best, but you’ve never actually proven they are the best.
you say “it just consists of 3 lines!”. That means less functions, that does not mean it’s “the best”. You calling it superior right now is an opinion, but if you’re going to try and state it as fact, please provide actual evidence, instead of hearsay.
1 Like
Thank you for the feedback! Let me know what you think of the new section outlining the advantages of Easy Datastore!
how is constantly autosaving a bad practice?
If you do it everyone 5 - 10 minutes you’re fine, remember the amount of calls you can make to datastore are 6 * PlayerCount per minute. Which means even if you were to save every minute you would still have 5 calls left over.
And trust me it’s very hard to have your game set up where you need 5 calls every minute, let alone 6
Constant autosaving is unoptimized. Using Easy Datastore is better as it uses the best practices within autosaving
-
Constantly autosaving, even in situations like every 5 minutes (which is too long), puts a constant and frequent load on the game, even on players who do not need frequent autosaves (like AFK players)
-
Constantly autosaving can lead to more server load and datastore costs. This means that Roblox intentionally makes your datastores of poor quality because of the constant autosaving. Furthermore, larger servers mean more constant autosaves, which is not good at all.
-
Constant autosaving can lead to inaccurate representations of data in the event of a crash. In contrast, autosaving only after critical events (like leveling up) can represent the user’s data at a more accurate and focused level of importance.
-
Constant autosaving is constant, regardless of whether the game actually needs this level of autosaving. For example, a chill hangout game that only uses datastores for moderation actions. Constant autosaving is simply unoptimized in such situations. Doing module.save() adapts to different games and represents their needs better.
So why is this better than using something like ProfileService
1 Like
No, no it doesn’t. This is because roblox has a limit, if you are within said limit, you are fine.
First off, where is the evidence that roblox makes your datastore worse, once again it is well within the limitations of roblox datastores, you’re just making stuff up now
if you autosave after every little change you’d end up using more autosaves than by waiting a constant time. What if the player levels up 5 times within a minute? you’d end up using more of the limits.
Can be solved by modifying the autosave to only save if data has actually been changed.
You can’t claim you’re superior when literally your only stated better quality is autosaving.
Do you even have session locking?
Listen, I get you have an ego and it needs filled, but you’d get more out of it by bringing something of substance to the table instead of just pulling stuff out of thin air.
As a bonus, I’ll even use your fantastic method of AI.
Guess that means ChatGPT endorses constant autosaving /s
Give chatgpt the content of my post, then reask that question.
Simple say:
Since that’s the only point of the post you’ll respond about, I’ll bite.
GPT says both methods are good, doesn’t say one is better than the other.
Those are the same results I got. However, I want chatgpt to consider my outlined points about autosaving more. I appreciate your honestly, I know a lot of players would have tried to manipulate the results to make me look bad. So really thank you a lot!
Here is the message I will further ask:
Voilà
https://chat.openai.com/share/b4baddb2-4c14-437e-8623-53cfe3346179
Your point about efficiency is Null and Void, because they are once again within the outlined limitations of roblox. To prove my point with evidence.
(infact, it seems my old numbers were outdated, they buffed it.
)
Let’s disregard the 60’s as they don’t multiplier with players.
That’s 10 Gets, and 10 Sets, per player, every minute.
So every 5 minutes that’s 50 Sets, and 50 Gets per player.
If we autosave every 5 minutes, it’s 50 Gets, and 49 Sets per player.
That’s clearly efficient.
I’ll wait for your numbers.
1 Like
we can talk more about this later because its getting too late. Thank you for helping me out with Easy Datastore. I appreciate it a lot and the information you are finding for me. I look forward to talking more about it tommorow. I will give you a response on the bus. Good night!