BindToClose not working?

local function SAVE_PLAYER(player: Player)
	local glove = getPlayerGlove:InvokeClient(player.UserId)

	local success, failmsg = pcall(function()
		restoredGloves:SetAsync(player.UserId, glove)
	end)
	
	if success then
		return
	end
	
	warn("[RESTOREHANDLER] Failed to save player")
end

local function RESTORE_PLAYER_GLOVE(player: Player)
	local glove
	local success, failmsg = pcall(function()
		glove = restoredGloves:GetAsync(player.UserId)
	end)
		
	if not glove then
		return
	end
	
	setPlayerGlove:FireClient(player, glove, true)
	
	restoredGloves:RemoveAsync(player.UserId)
	
	if success then
		return
	end
	
	warn("[RESTOREHANDLER] Failed to restore player")
end

local function onGameClose(closeReason: Enum.CloseReason)
	if RunService:IsStudio() then
		return
	end
	
	if closeReason == Enum.CloseReason.ServerEmpty then
		return
	end

	for _, plr in pairs(Players:GetPlayers()) do
		SAVE_PLAYER(plr)
	end
end

Players.PlayerAdded:Connect(RESTORE_PLAYER_GLOVE)
game:BindToClose(onGameClose)

Self-explanatory, BindToClose doesn’t save the player’s glove before leaving. My guess is that the InvokeClient doesn’t get the data by then and the server closes, if that’s the case what are better solutions?

1 Like

I think you’re making some saving mistakes.

First, the game should save a player’s data after they log out, not when the server closes. Saving using this method is just an extra security measure, not the primary method, since the player can log into another server after logging out while the previous server is still running.

Second, why does the server rely on a player’s confirmation to save their data? InvokeClient is so dangerous if misused, especially in this situation. I only see potential tragedies.

I intended for the glove to save upon server shutdown.

Thinking logically, shouldn’t the server have control over everything?
Why does it need to get data from the client, when this should be controlled by the server?
The client should only have something that the server wants to show, not the other way around.

1 Like

I know that the server needs control over everything.

But, how the game works is that;

Players create a glove by customizing it through the UI were given, in order to send the data it gets put into a table called “gloveinfo”. What happens here is the server asks the client for their current gloveinfo (like what they have so far).

I forgot about the vulnerabilities of the InvokeClient, so I’ll work on that.

I see, in this case it is good to use a RemoteEvent from the client to the server.

Have some kind of default table, in case the player is unable to inform the server of his glove, the server already has a default glove.

1 Like

But the client can’t use BindToClose?

To solve this problem, you could make it so that when the client updates something on its glove, this information is sent to the server.

i feel like this’ll lag more cause that’d mean the player would send their data every single time they add an input and it’s too much

Typically in customization games, the client makes the changes and then confirms them. When the client presses to confirm the changes, the information is sent to the server.

yeah, thats what i have. but what if the player never confirmed their thing and it just dissappears?

Don’t let the player close a customization UI without confirming.
If the game closes by accident, it will redo the customization. This is what happens in any customization game to avoid overloading data submissions.

1 Like