I just don’t know why would you want saving OrderedDataStore with ProfileService :D.
How would I use ProfileService to do the same thing I would with normal DataStore?
1 Like
[05/04/2021] Profile.MetaTags now retains the same table reference after every auto-save
Before this fix, trying to store a reference to Profile.MetaTags to a variable would not work as expected since whenever ProfileService updated MetaTags it set Profile.MetaTags to a new table reference every time.
You may update the module through github or the Roblox library .
4 Likes
Just swapped from DS2 to ProfileService, heavily recommend ProfileService if you’re making an RPG game with multiple instances. Working flawlessly for me!
2 Likes
I assume that ProfileService will be updated immediately when DataStore v1.1 releases?:
https://devforum.roblox.com/t/sunsetting-legacy-data-persistence-systems/1206245
Because if I correctly remember, ProfileService only uses UpdateAsync(), and the new DataStore v1.1 (currently being tested and is private) appears to focus on updating. I highly doubt it will affect anything however.
1 Like
How would I go about granting myself or specific players all the gamepasses on joining the game?
1 Like
local AdminTable = {8994,4494,16597494} --insert players userid's
local function OnLoad(player)
local Module = require(game:GetService("ProfileModule"))
local MS = game:GetService("MarketplaceService")
local GamepassID = 11111
if MS:UserOwnsGamePassAsync(player.UserId, GamepassID) or table.find(AdminTable,player.UserId) then
--do your stuff
end
end
game:GetService("Players").PlayerAdded:Connect(OnLoad)
3 Likes
Great module! One question though, if I wanted to reset a player’s data, how would I do this?
I’d expect few people are using the Scope argument in ProfileService.GetProfileStore() so I’m not gonna make a huge announcement - it might be completely removed after the DataStore 1.1 Roblox update if Roblox decides to deprecate Scope. Prefix your scope along with the store name in the same store name string.
If Scope happens to be removed from ProfileService, a ProfileStore will be loaded with the Default scope and the scope argument will be silently ignored.
Please remove the check that sees if the key is a string in LoadProfileAsync, as Roblox already converts it to a string if possible when calling any internal data store methods. This check is redundant and kind of ruins my work flow because I have to forcefully convert the key to a string my self.
Nope! I encourage being explicit about the key types. Some people’s implementations might rely more on this type safety than others.
Well, fair enough. Will ProfileService be updated and expose a small API over the new data store backup updates when released?
Additionally, ProfileService should only auto save data (not release) when the data is actually updated to prevent unnecessary writes, and I would greatly appreciate a signal which fires whenever the profile is saved - this is so that I can notify players in game and have a nice feedback system and would be great for debugging as well.
ProfileService uses every auto-save as a ping for the DataStore key which also holds the session lock - other servers using ForceLoad will initially request the owner server to release the Profile on it’s own. This way we can ensure that Profile:IsActive() is completely reliable and saving data when it returns true is guaranteed to be saved in most ProfileService implementations (assuming it’s a 2 server conflict).
So I think I have been experiencing the Race Condition described in the wiki, though up until today it has only seemed to affect mobile players. It is preventing user data loading for up and over 10 minutes at a time for some players, though it is infrequent (player counts are low right now, I’m worried about this becoming worse in the future).
I have read through the wiki, and have installed the latest version from GitHub. I have also made sure that i am releasing the profile when the player leaves as quickly as I can, like so:
Players.PlayerRemoving:Connect(function(player)
local profile = profiles[player]
if profile then
profile:Release()
end
end)
After my recent update of the module, I get the added to queue warning EVERY TIME I test in studio and also when a game server starts up, this didn’t happen before my update.
And now today I seem to be getting that race condition in Studio testing perhaps? I am not sure what this warning is:
Really at a loss on how to solve this. I have other scripts that use the PlayerRemoving event throughout my code, could it be one of those yielding before ProfileService can release the profile?
EDIT:
For whats its worth, I have been using this datastore module for some months without issue, but now that I am getting more players these things become more obvious.
3 Likes
Experienced the same issue today, I suspect it was due to Roblox’s update.
2 Likes
This appears to be related to DataStores themselves rather than ProfileService, as I am experiencing the same queue and 429 errors without using ProfileService.
1 Like
While i am experiencing critical issues today that are blocking me from loading into studio test half the time, my issue in this post is persistent. I have players not able to connect runnign back a few weeks now.
I probably should not have conflated these issues in my post.
You have loaded two ProfileService modules at the same time - if you happen to access the same keys with the two modules then you’re gonna have session conflicts.
1 Like