FireClient not triggering through a PlayerRemoving event?

Help and Feedback Scripting Support
, , ,
#1

I have made my own datastore system which should work in this method:

  1. Player joins and the data is loaded
  2. Data from the server is replicated to the client
  3. Player leaves and the data on the client gets replicated to the server
  4. Data gets saved on the server

The problem I have is that since I am not aware of any alternative to PlayerRemoving event from the client, I made a PlayerRemoving event from the server which fired a RemoteEvent to the client which should Invoke the Server through a RemoteFunction to save the data, hence the problem being that the RemoteFunction is not triggering.

The issue I think is that FireClient is not triggering.

Server Script:

--Triggering the replication of the cache from the client to the server
game.Players.PlayerRemoving:Connect(function(player)
	FE.Cache2Data:FireClient(player) --The problem ???
	print("this fires")	
end)

--Saving the cache into the datastore.
function FE.SaveData.OnServerInvoke(player, cache)
	print("not firing")
	if cache then
		ds:Save(player, cache)
	end
end

Local Script

--Get the cache from the client and replicate it to the server
FE.Cache2Data.OnClientEvent:Connect(function()
	print("this is not firing!")
	FE.SaveData:InvokeServer(cache)
end)
#2

I think that it’s because in the time that it takes to send the event to the client, the client has left the server, thus destroying the local script (that i’m assuming is in the player) that controls the remote function firing.

EDIT: Interestingly enough, when I disabled accurate play solo, everything worked as you intended it to… Not quite sure what to say now if i’m honest. :grimacing:

1 Like
#3

That is what I was thinking when I was thinking about it.
I wonder if there is a way to delay the player from being removed. :sob:

#4

There is but there is a bug at the moment with it.

game:BindToClose(function()
    wait(30)
end)

–This would delay the server from shutting down for 30 seconds (max 60 if think).
The bug causes studio to crash when used but it works fine in-game.

Issue can be found here:

1 Like
#5

Trying to figure out how to implement it with my current code.

#6

Not sure if I did it correct, but this doesn’t seem to be working

--Triggering the replication of the cache from the client to the server
game.Players.PlayerRemoving:Connect(function(player)
	game:BindToClose(function()
		FE.Cache2Data:FireClient(player)
		wait(30)
		print("this fires")	
	end)
end)
#7

use a remote function, then it will yield until it gets confirmation returned back that it saved

then you dont need to wait(30)

1 Like
#8

also bindtoclose should be outside playerremoving. it triggers when the game is about to shutdown. anything inside prolongs the shutdown.

1 Like
#9

Ah right. Sorry the game.BindToClose is a separate function. You’d do this:

game.Players.PlayerRemoving:Connect(function(player)
	FE.Cache2Data:FireClient(player)
    print("this fires")	
end)

game:BindToClose(function()
	wait(30)
end)

It stops the game from shutting down for 30 seconds allowing data to save in studio. However as stated this will make your studio crash when you click stop

2 Likes
#10

I don’t think I can do that as I am using the OnClientEvent function.

#11

switch it to OnClientInvoke callback function and add a return

#12

You shouldn’t be doing this at all. Trusting the client with their own data that you’re saving is something that is very welcoming to exploiting. You should be considering the server’s version of their data as the authoritative definition, and then the cache on the client is used strictly for quick access aesthetics.

Again, do not trust the client with handling saved data. Use PlayerRemoving on the server and save the server version instead.

4 Likes
#13

it’s a really bad idea to let the client send their save data to the server; the client can easily manipulate the data in whatever way they want
you should be keeping track of the clients save data on the server, ideally preforming sanity checks to ensure the client isn’t cheating in any way, and save that data when they leave

2 Likes
#14

@Locard @crossStarCross Thanks I will reconsider the way it currently works.

2 Likes
#15

definitely agree with what’s been said here
you leave it very vulnerable, and you should do it all on the server. it will make it easier as well.

#16

Thanks for your help.

#17

Thanks.

#18

euhm why not store data in like a module onthe server side. so whenever a player leaves thier data is still there and can be removed later

2 Likes
#20

It’s still a good practice to let the server know about the changes you made to the data on the client at the time they were made or a while after, that way you have a lower probability of losing your data during a shutdown.

1 Like
#21

You should never really invoke the client with a remote function. There’s no guarantee it’ll return so your thread may infinitely yield

2 Likes