MadStudioRoblox / ProfileService

Universal session-locked savable table API

Home Page:https://madstudioroblox.github.io/ProfileService/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Question about Profile:Release()

Shariiii opened this issue · comments

commented

I was wondering if it is ok for a Player to call Release() function on Profile when the ProfileService function connected to BindToClose is running. Basic Usage simply suggests that you call Release function when a player leaves but what if the player left when ProfileService is already busy saving data before server shutdown will extra requests to save/release profile cause any issue?

Question 2
For games that load Profile.Data into Folder containing ValueBase instances for all the Stats and constantly update Profile.Data with all the changes made to those ValueBase instances is there an Event inside Profile that allows Dev to update Profile.Data for one last time before Profile:ListenToRelease() gets triggered? There was a similar issue with BindToClose so I had to manually add a function right below the line "2387: ProfileService.ServiceLocked = true" inside the ProfileService module which updates Profile.Data of all players one last time. I did some testing by joining the actual game server and changing some ValueBase Values then quickly pressed play in Studio to trigger the ListenToRelease event and as expected because there was nothing to update the Profile.Data in such situation the latest changes to ValueBase Values didn't save. In the next test, I add a loop to Sync Profile.Data and ValueBase every 3 seconds it worked and the player loaded with the latest Data in Studio but using loop is really not efficient and it is also not efficient to connect a function to .Changed of 200-300 ValueBase instances(per player). So can you please add an event that allows Dev to Sync Data right before ProfileService attempts to Save Profile.Data

A1:
:Release() Does nothing after a profile is already released and BindToClose will trigger releasing on its own. However you should regularly release your profiles after you're done using them as failure to do so will eventually lead to too many auto-save API calls.

A2:
ProfileService was created with some implicit security measures in mind, including steering users away from saving data exclusively before release - this would render player data completely unrecoverable after server crash as opposed to partially or even fully recoverable (with the help of auto-saves which are already done automatically when you use ProfileService regularly). New future versions of ProfileService will still include these features for full control, but for now it will stay as is.

commented

Oh, I understand the importance of the auto-save feature and I did add one for the cache system too so it can keep Profile.Data updated with the latest Value in ValueBase instances after every 3 seconds (around 300 ValueBase per player) but since ListenToRelease can be called at any time even intentionally to dupe stuff and when it gets called the latest data is mostly inside ValueBase instances. I need to find a way to update Profile.Data with the latest Values right before it attempts to force release/save old session so it can load the Profile in another Server. Also, I wanted to further increase the yield time of the cache system because I think that 3 seconds is not healthy for the server though I did try my best to optimize the process responsible for moving the latest values of 303 * 15(No. Players) ValueBase into Profile.Data So it would be amazing if you can guide me lil bit on what kind of patch I should apply :P well if I can find the function responsible for saving data in that situation then i can add something before it which updates Profile.Data for one last time and then release/save it