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?
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.
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.
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.
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.
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.