but it still uses datastore functions 
it doesnt matter if you use any wrapper or what aslong as its best for you
Dungeon quest uses DS2 and had a issue with item duplication, it is now patched, but the original DS2 module is still susceptible to duplication glitches.
Your not getting my point they don’t only use GetAsync and SetAsync
2 Likes
I was thinking of “opening” and “closing” os.time() tables. Basically when a player joins in, a session is opened with their os.time() entry and when they leave, the table is closed with another os.time().
What I was thinking is that every time a player joins, if the table’s closing value is still nil (meaning it has not saved yet), it would yield until a value is set.
I’m still not sure if this would work though.
API calls can error. The reason why ProfileService waits about 80 seconds before “stealing” the session lock is because that should give the other server enough time to sort out the issues with any API errors. There’s still a possibility that it takes longer than 80 seconds for the previous server to sort out the errors. This is still the best and safest way to save player data in my opinion.
The reason why using :GetAsync and :SetAsync separately is bad is because you’re prone to 2x as many network errors as you are with using a single query to both fetch AND update your data. :GetAsync also has a lot of caching headaches that might interfere as well.
To answer OPs question, it’s really only worth it to switch if players in your game already found out how to duplicate items. I would highly advise to use this on all new games you make, but transitioning between data systems can create more issues than it solves if you do it incorrectly.
2 Likes
UpdateAsync doesn’t do much to prevent duplication. Little to nothing actually. Profile service features Profile Locking, which is actually what stops duplication. It’s impossible for ProfileService to not use GetAsync, as that’s the only way to get data without overwriting it.
No it’s not, remember that UpdateAsync passes the previous value of the data, and it will be nil if it has never been set before, I just took a look at the code and it does not use GetAsync, and it only uses SetAsync in studio to see if api services are enabled. (https://github.com/MadStudioRoblox/ProfileService/blob/master/ProfileService.lua)
1 Like
Oh that makes sense. I’m still at Pre-Alpha stages with my game so I could just reset my data or find a way to secure with DataStore2.
By the way, is there any data-loss issues with ProfileService (without any tweaks) or is it as safe as DataStore2? If so, I might be looking forward to switching to ProfileService.
Seems you’re right! However, still doesn’t do much to prevent duplication
I’m not really sure how then how it prevents duplication, and why would that not help with item duplication? From my understanding it is caused by a race condition between GetAsync and SetAsync, thus only using UpdateAsync will stop that issue.
You run into the same problems with UpdateAsync. Session locking prevents duplication, as duplicators use two clients to prevent data saving.
No you don’t, and the session locking is done with the update async.
Actually, ProfileService uses MessagingService to check if the profile is loaded. UpdateAsync cannot give you that information.
It’s hard to read your replies when you assume false information so boldly XD
No, ProfileService does not use MessagingService nor SetAsync / GetAsync. You might want to check the source code / documentation if you’re going to explain how it works lol.
8 Likes
Unfortunate. I’m usually not wrong about these things. cjj: 1 async: 0
1 Like
Sorry for the revive, DS2 and Profile Service aren’t necessarily wrappers. They use DataStores yes, but they have their own system for everything, DS2 is about backups, ProfileService is session-locking, and a bunch more. Wrappers are usually just modules which LINK to another module, or service, but that don’t have anything special; They make things EASIER to understand in such module/service, but mostly don’t have protection agaisn’t problems;
What? DataStore2 is definitely a wrapper. It was even advertised as a wrapper for one, but it looks like as time went on its topic was updated, so it doesn’t explicitly say wrapper anymore. The module wraps around data store functions and exposes new behavior using the data store api. Same can be said for ProfileService.
2 Likes
I don’t like to think of them as wrappers though, they are, 100%, but because they go SO FAR into security and making roblox datastores so much better that it’s almost as if you’re using something which is totally different, you get what I mean? I guess before all the DS2 changes it was a little bit more basic but yeah, they’re so great, it’s ALMOST like you’re using a different system for saving data;
2 Likes