Just a few questions as I’m rather new with using this module. With clans/factions having no session locking (not releasing the profile, not listening to release, and having different servers load the profile) could it be setup like this?
local module = {}
local ProfileService = require(script.ProfileService)
local ClanProfileStore = ProfileService.GetProfileStore("ClanSaveData",{})
local ClanProfile = ClanProfileStore:LoadProfileAsync("Clan","ForceLoad")
function module.ReturnClanProfile()
return ClanProfile
end
return module
--planning to add more functions, which is why I'm not just returning clanprofile
I’m planning to add real time cross server updates to these clans. Would using messaging service and informing all servers of new changes and then having those servers save that data be the most effective/efficient way to provide real time updates?
For example, in server A someone does something that makes their clan score go up by 3, another member of that same clan is in another server, server B, now server A would send a message to all running servers to update their clan score. This way any changes server B makes reflects the true amount of clan score they have (and of course server B would be doing the same for any changes it makes).
ProfileService is designed for profiles that are acessed by one server at a time - this will not work.
Yeah, you can use ProfileService for anything other than players as long as the individual profiles are used on one server at a time - otherwise you’ll need to make custom code with update listeners and messagingservice.
I’ve been wanting to experiment with ProfileService and took the time to do so today after looking at @EncodedLua’s tutorial.
Is there any reason why I should be getting the following warning:
The code is nearly identical to the script provided in the tutorial (except a few variable name changes.) Did I miss a step in the tutorial? Code can be provided if it helps solve this issue.
From the info and personal experience I’ve gathered, such warnings are not dangerous at all as long as you don’t get like a ridiculous amount of them at a time (like 10 every second). I tried to avoid such warnings while coding ProfileService as much as possible, but there are cases where it’s necessary to put a request on queue immediately.
Thank you, I feel like an idiot for missing this portion of the documentation.
I’ve also stumbled upon the script not working in Studio (works just fine in a regular game session), is this just something I’ll have to get used to in regards to testing?
Not sure if this was answered but if you update the ProfileTemplate, will old players be able to get that data saved, or are there special steps needed to be taken for that to be possible?
You can use the Reconcile() method on a Profile, this will compare the existing profile data structure with the data template being used and will fill in missing values.
It’s actually a poor use of ProfileService to save data on profile release - this will leave you prone to data loss much more than having Profile.Data updated all the time.
I added some prints before, and it doesn’t even get to the “if profile ~= nil then” part. I didn’t touch the scripts in a few days and it was working fine before
What benefits/security this has over normal data stores using GetAsync and UpdateAsync?
I know session locking, but what else other than that. I want to know it before I revamp my whole saving system.
And does it work with existing data stores? Because data stores in my game have some data of different players (not a lot) on it, any way to transfer that over to profile service? Is it possible to make global leaderboards with this? In DataStore2 as far as I know there is no way to make global leaderboards, and that is one reason of me not using it. Does this have the same issue?
ProfileServices handles a lot of things so that you don’t have to think about them. Assuming you already have proper error handling (which ProfileService does for you), when you use GetAsync and UpdateAsync normally, your data is still sometimes susceptible to being overwritten such as when a player joins and leaves quickly.
Since ProfileService doesn’t use DataStore2’s OrderedBackups method, transferring should be easy. However, you should note that you will have to convert old player data to another format (ProfileService stores some metadata along with your actual data).
As for global leaderboards, I’m not sure what the best method is, but right now I simply use a FastSpawn (or spawn/coroutine) in my :ListenToRelease() connection that saves data to a global leaderboard.
