game:BindToClose() doesn't work on the client but game.OnClose (deprecated) does

game:BindToClose() throws the following error on clients, while the deprecated game.OnClose callback works on the client. This is undocumented and I’m not sure if its intentional.
image

I just wanted to append this bit here to clarify why I am making this bug report and what the reason I feel that it is a bug is.

I am not referring to detecting server shutdowns in client code, this is already easily possible to do and would be unnecessary behaviour. What I am referring to is the ability to run additional code when the client’s game shuts down (e.g. when the player leaves) using :BindToClose() and delay the shutdown just a little so that data can be sent back to the server when the client disconnects. This was, and still is entirely possible to do with .OnClose, and, it follows the exact same 30 second rule as BindToClose (it also appears that scripts use significantly less CPU when the client is shutting down and trying to lag the game does not do anything to it).

This bug report is referring to the difference between the two. If the intention is that :BindToClose() doesn’t work on the client for some reason, .OnClose bypasses this and allows for this behavior to begin with. If the intention is that .OnClose would work on the client, which would, like I said, be useful for sending back data to the server, than there is no documented reason as far as I am aware for :BindToClose() not offering this functionality.

A few examples of what sort of data I am referring to:

  1. Simply analytics data. This is what initially gave me the idea to make this report, someone mentioned they wanted to be able to send some performance info back to the server upon a disconnect which isn’t possible to reliably do without usage of .OnClose (which is deprecated)
  2. Knowing when the client shuts down intentionally and acting on that. This would be useful in a game where you might want to give the player some time to reconnect to a match if they lost connection, whereas if they close the game, you could assume that they are done playing. Again, already entirely possible using .OnClose.
  3. Debug information. Let’s say you have a lot of players leave a server at once, and you want to know why. This would let you know that these players left intentionally and would allow you to more effectively collect server/client errors. This one is probably less of a good one since Roblox mentioned potentially overhauling performance stats and adding the ability to collect these sorts of things more reliably.
7 Likes

game.OnClose shouldnt be used. It is deprecated for a reason. Now the actual issue your facing is intentional because the only time the BindToClose() is fired is when the actual server is shut down and not the clients. This is why it should only be called on the server.

2 Likes

game:BindToClose() only works in a server script. I advise you to use fireallclients for when game:BindToClose() fires.

The issue here is about the fact that :BindToClose() does not work on a client to detect a client shutdown, however, .OnClose does which was the old behaviour. This has nothing to do with a server shutdown, I am completely aware of how to use BindToClose properly.

I am unsure of why the behaviour was removed when BindToClose was introduced when no alternative exists and I am unsure of whether or not said removal was intentional because of that. This could have simply been made in error, isn’t documented, and in the original announcement for BindToClose goes unmentioned, on top of BindToClose’s initial purpose, hence the bug report. An example of where this would be useful is in the case of sending data back to the server before the client shuts down. Currently, you can’t send a remote request to the server reliably when the client is disconnecting, since the client will almost always disconnect before the data is actually sent out. BindToClose would be able to delay the client shutdown enough to send data to the server as well as receive data back to signify that the data was actually received at all.

This could easily be employed like so in a client script, since InvokeServer yields for a minimum of two network frames. This will send data to the server, but it will also yield and wait for a response with a minimum time of two network frames, which delays the client shutdown until the server receives the data or the request errors, in which case the client will shut down anyway. (Note: This behaviour is possible with OnClose, I see no reason that it shouldn’t be possible with BindToClose when BindToClose’s entire purpose was to be an OnClose you can use in more than one script)

game:BindToClose(function()
    dataRemote:InvokeServer(theDataToSend)
end)

@jakebball11
I am aware that OnClose is deprecated, and I am aware as to why, the issue isn’t about OnClose being deprecated nor is the reason for OnClose being deprecated relevant, because the reason OnClose was deprecated was because, unlike BindToClose, OnClose could only have one handler function, since its a callback. I and others have already done testing on this, and OnClose does in fact work on the client (and can even delay the client’s shutdown), it does not have to do at all with a server shutdown and this is not what I am referring to.

@ShesSoCuteeee
I am aware that BindToClose only works in a server script, this is entirely what my post is about. This is not about detecting server shutdowns on the client, that can fairly easily be sent to the client. This is about being able to run code on a client shutdown with the same functionality as BindToClose which was (and still is) possible with OnClose that is no longer possible with BindToClose. Being able to reliably send data back to the server upon a client shutdown would be a quite useful feature, and this behaviour existed (and still does exist) in OnClose which is essentially the same mechanism, hence the bug report.

5 Likes

Not sure if this works – killing process = nothing else happens, so people just open up task manager and kill the process that way. You’d subsequently have no way to guard against this to prevent cheating etc if that’s what you meant.

Roblox should be providing us with crashing-related / unintentional shutdown data, shouldn’t be up to devs to figure out how to best record this.

This is a good use case actually so you can correlate it with game events / error logs, but not for this feature, since it’s not clear why you can’t just do this via Players.PlayerRemoving.

For the first thing, this is very much true and it shouldn’t be relied upon to be secure at all because its not. The idea is just that you can know when the player leaves or closes the game and act on it. If they leave generally you would assume they are done playing, since the user initiated the action.

When I am referring to analytics, I am referring to when there is an intentional shutdown, crash stuff should absolutely be handled by Roblox. It’s impossible to send data back to the server when the client closes, meaning you have to poll data back to the server every second or so, which was the solution for the user I had mentioned.

And for the last thing, the same issue happens. You can’t rely on data reaching the server when using PlayerRemoving, meaning you can’t, for example, send recent client logs to the server without sending all logs/errors to the server, which, is kind of a waste of remote transfer.

Additionally, this is sort of a simple flip type of thing. This behaviour existed prior, and does in the deprecated alternative, but is for some reason disallowed in BindToClose. Fixing this discrepancy would likely be a fairly simple thing for Roblox to do.

I don’t see why BindToClose should be restricted to the server when OnClose isn’t, and, regardless of what use cases I come up with, the fact that this behaviour is now impossible without using deprecated features is still true.

This seems like it should be a feature request. Missing feature is not same as a bug.

I guess you can argue that. Like I said, I’m unsure of whether or not this is an intentional or unintentional difference between the two features, I don’t really know whether or not this is or isn’t a bug, I am just assuming it is considering how close the two features actually are.

Hello. As discussed so far, game:BindToClose() can only be used on the server and game.OnClose() is deprecated and should not be used. This indeed is not a bug.

1 Like

This is not what Hexcede is looking for - FireAllClients in BindToClose would tell all the clients when the server is shutting down - which is already possible to do from the client and would be unnecessary. He’s looking for a way to detect when the client leaves a game from the client, allowing some final code execution before the player’s game is closed.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.