ID:2918183
 Mar 24, 4:50 pm
|
|||||||
| |||||||
A way to differentiate between when a client naturally logs out, versus when they are disconnected (i.e., loss of connection, client crash, etc.)
| |||||||
|
Mar 25, 12:14 am
|
|
Lummox JR
  |
If the client sends a quit message first then it should be possible to determine this on the server side (with the caveat it might not be perfect), but what would the syntax/language setup for this look like?
|
In my head, the BYOND way it might look like:
if(client.disconnected) | |
What about an argument for client/Del() to tell how the client was disconnected?
| |
client.connection_status status of 0 = not finished connecting status of 1 = currently connected status of -1 = intentional disconnection status of -2 = connection died This would be set prior to client.Del() | |
While I'm not against arguments being added specifically to client/Del(), historically, Del() doesn't have arguments across the board.
I'd much rather be able to see the connection state of the client via var access. If that's not feasible, then eh. | |
Spevacus wrote:
While I'm not against arguments being added specifically to client/Del(), historically, Del() doesn't have arguments across the board. Backwards Compatibility ftw I'd much rather be able to see the connection state of the client via var access. If that's not feasible, then eh. Once the client disconnects you'd usually not have access to it, if Del() arguments were to be added while it's being disconnected you could handle the client's mob as needed. | |
Bump. This would be nice to have.
| |
