Player removing event doesn't have enough time to complete, please help!

When i have a onPlayerRemoving function that fires a remote event. The remote event doesn’t have time to fire before the player has left.
Here is the onPlayerRemoving function:


Maybe its something wrong with this script:,owns)

I need to have the remote event to save the table, but if theirs another way pls tell me


Generally what I’d do in this situation is Cache the data server sided, and check to see if the player still exists if the player doesn’t exist save the cache and then remove it so it doesn’t get altered any further.


Being the cache is a table, you can update the data frequently without hitting a limitation.

1 Like

It looks like your client’s data is on the client. This is unfathomably easy to exploit. Consider pushing ALL datastore related code to the server.

Also, keep in mind that your second function gives the client direct access to their own data. You should consider only keeping their data on the server, while giving the client its own “readable” version so it can present the data to the player.


There’s no reason to save depending on a remote event. Set up your PlayerRemoving event on the server not the client.

Also set up saving in BindToClose which gives the server 30 seconds to save without interruption.

1 Like

Whether the question was about exploiting or not, I will still help someone get their code to work properly and practical. The code present is 100% not practical and I will offer advice on that.

I’ve edited my reply to be more direct with the topic, but please don’t try to regularize my reply when I patch my note about something so severe about his methodology.


Can you use _G to give the table to the server without remote events?

1 Like

You can not. As @Locard suggested, you should only store values on the server.

1 Like

The roblox data storing isn’t 100% reliable.

Worst case scenario:

An experienced player that plays your game a lot decides to spend 2000 robux on your game’s dev product. They decide to leave the game a little later… The remote event request is sent to the server… The datastore has an error and cannot save the player data at that exact time. The data never gets saved because there is no datastore error handling… The player rejoins and sees that their newly bought items were never saved, even though they paid for it… Then that player decides to never play again.

When the player leaves, you should add their player ID to a table…


local playerData = {}
local saveList = { }

–player leaving --> table.insert(saveList, playerID)

–loop --> executes once a minute --> run through saveList --> attempt to save player data

Datastore --> SetAsync(playerID, playerData[playerID])

1 Like

Remember when Setting or Getting data, you’re using pcalls to make sure you actually do retrieve it in the end because sometimes it can fail.

1 Like

Store a copy of the player’s data in ServerSorage, and use that when saving on leave.

1 Like

Seeing the code that OP is working with, changing the location of the save data isn’t going to do anything. They need to convert their save method to be completely server-sided and get rid of the unnecessary RemoteEvent communication.

1 Like

Oh, I thought the data was stored server sided in the player object. It should be converted to the server in serverStorage.

1 Like

If data was held under the Player object, it would be a replicated instance and have two copies; one on the server and one on the client. It’d still be “on the server” and not require any conversion.

It’s not proper to keep data under the player because the player is effectively removed from the server after they leave unless a memory leak is keeping their Player instance from being garbage collected and dissociated completely.

I think you mean that it should be moved to ServerStorage, which is a more viable solution. Anything under the player should only be used for session data or display.

1 Like

I was trying to get at not storing it in the player, and thought that was the OP’s problem. And yes, by sever I meant server storage.

1 Like