Could you right-click your output window and screenshot the whole thing? I just want to make sure you don’t have settings enabled that prevent you from seeing some prints.
I don’t really know what you mean, but I checked all the contexts and messages, and that’s the only message when I leave.
The weird thing is that your code works perfectly fine for me. Is there no other scripts that affect this one?
1 Like
I can say that it’s in a folder in ServerScriptService. Not much other than that.
I believe your issue is related to the fact that DataStoreService does not have enough time to save before the Play test actually concludes.
This is very easy to test aswell. Having studio on 60 fps or higher would cause the code to fully save everything before studio stops the play test, however if you were to cap the framerate to lets say 30 or lower THEN studio would simply stop the play test before DataStoreService has any chance to save anything. This can happen even at standard framerates and higher due to a decently long list of other factors but overall any of these factors can cause studio to stop any play test before any DataStoreService gets to finish its job.
Always remember, Data stores need quite a bit of time before they can actually finish saving something.
1 Like
The problem though is that for some reason, the print inside the .PlayerRemoving fires, but the prints after don’t. The script he sent even worked when I tested it in my published place.
I suggest you try too.
I tested it too.
This happens because the amount of time pcall with the data store function need to complete is worlds less than whatever that print needs. Remember, sending data to remote servers requires different sorts of expectations in speed.
Still, i believe you should try to save data while in the middle of the play test and see if it works.
1 Like
As I said, I tried the script he used and it worked. I didn’t remove the saving functionality, I literally used the exact same script.
Wonder if @Den_vers could try testing in a live game though.
1 Like
As said before, there will be different results for other people. It may work for some while for some it wont. You can emulate this sort of behavior by capping your framerate to some low amounts however this is not 100% confirmed to make it not work the first time around, but i believe a fail is bound to happen. This sort of issue is even more likely to happen if you have a large and decently demanding place.
One piece of advice from this, is to simply not always relly on the player leaving to save any data. It’s simple and convenient but data loss issues CAN appear from scenarios like this. Auto save systems designed to save data during gameplay can help a lot.
1 Like
I’m going to try to save in the middle of the session, see what changes.
1 Like
It worked. (some limit I need to get around to post this)
1 Like
I’m guessing now I should implement an autosave system, thanks.
1 Like
By the way, you should also be saving on game:BindToClose.
1 Like
Weird, because I’m still having problems retrieving data, it doesn’t work, even if i save it in the middle of a session.
EDIT: I realized It was because I was returning two values in one tuple, so the other data was being deleted, that was half the problem, the other half is that it was never saving, due to the same problem Xeno mentioned.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.