Descriptive Problem Summary:
If you login to a game and then disable your network BYOND never realizes the mobs client has been lost and takes a very long time to delete.
Numbered Steps to Reproduce Problem:
Login a game
Disable network(internet)
Code Snippet (if applicable) to Reproduce Problem:
Expected Results:
Client deleted
Actual Results:
Client not deleted
Does the problem occur: every time so far
I tested in another game disconnected...switched to my vpn and logged in with a guest key and my character was still in game on eternia
http://puu.sh/1RwbB <--- screenshot
http://puu.sh/1Rwep <--- another screenshot i logged back into my main key did the bug again and there is the guest character.
When does the problem NOT occur?
when you close out your client it will detect client deleted but not when you disconnect your network
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
Workarounds:
not sure
ID:1135870
 Jan 23 2013, 2:47 am (Edited on Jan 23 2013, 2:54 am)
|
|||||||||||||
Not a bug
| |||||||||||||
|
Jan 23 2013, 2:48 am
|
|
Blastcore
 |
I've seen this happen.
|
Blastcore wrote:
I've seen this happen. Yeah I hope this can be fixed it can be abused easily in some games. For games that store characters via login(like mine) this makes a problem for example because in my MUD where you can login to any character and we ignore the byond key pretty much(except for reconnecting to mobs) you can actually duplicate your mob multiple times and kill it and save the benefits.. I have layed in place to delete identical mobs upon logging in which is really only a temporary fix to a bigger issue. | |
It has nothing to do with dreamseeker.
I can connect to a game via telnet and the same issue happens. | |
I've seen this a few times, the most recent was about two days ago, only it has happened as a general issue with clients on the game rather than a isolated client, which would point to the issue I've seen being server-sided.
| |
Just to clarify this situation, I believe the issue here is that when you do a hard shutdown on the network, it's not giving a proper closure for its connection to the other end. Therefore, the server hasn't been notified of the connection being severed and thinks it's still open.
The reason the client remains in the list is that we have an inactivity timeout, which is used to prevent spurious disconnections in the event of network lag. So it sounds like the expected behavior is being observed. Can you elaborate on this any further? I won't rule out that maybe the timeout is taking too long or it's failing to act on a situation it should, but bearing in mind that there are cases where a server will not see the disconnect, this seems like everything is being handled properly. | |
are you using a custom Logout() without return ..()?
if not you should add something like del(usr.client) i would guess | |
Zelldot wrote:
are you using a custom Logout() without return ..()? You should never use the usr var in Logout(); it is not safe there. The usr var belongs in verbs only, or procs that function only as verbs (such as obj/Click(), which is really a proc but is a verb for all intents and purposes). Also, src.client should be null at this point. Returning ..() is irrelevant in Logout() since the default proc does nothing. | |
I always thought Logout() was the script that was called when a client disconnects from the mob... not actually disconnecting from the server, because you can change mobs via usr.client.mob, i was keeping it simple above, not mentioning the if(usr.client), because a player can still be connected to a game with no mobs at all. That's how I have always seen it, first client, then mob in connection terms, so I always imagined the reverse on the exit to. I could be wrong though.
| |
Zelldot wrote:
I always thought Logout() was the script that was called when a client disconnects from the mob... not actually disconnecting from the server, because you can change mobs via usr.client.mob, i was keeping it simple above, not mentioning the if(usr.client), because a player can still be connected to a game with no mobs at all. That's how I have always seen it, first client, then mob in connection terms, so I always imagined the reverse on the exit to. I could be wrong though. It has nothing to do with Logout since this issue is not in only my project but obviously others hence the screenshots i posted. | |
Zelldot wrote:
I always thought Logout() was the script that was called when a client disconnects from the mob... not actually disconnecting from the server, because you can change mobs via usr.client.mob, i was keeping it simple above, not mentioning the if(usr.client), because a player can still be connected to a game with no mobs at all. That's how I have always seen it, first client, then mob in connection terms, so I always imagined the reverse on the exit to. I could be wrong though. You're correct that Logout() is called when a client disconnects from a mob, not necessarily from the entire server. The order in which this happens, however, is not what you think. The disconnect occurs first; therefore in Logout(), the client var should be null. | |
As client.Del() is called before. Taking a closer look at the problem, there is a work around, which is a auto client logout due to no interaction over some time. If I remember correctly a few other games I have played have had this problem and they was created in java and C/C++, and that is how they fixed that problem. I would say this is not just a problem with byond but internet scripting in general. There are many games that are online which would not let you log in because you are already logged in due to being disconnected in this way. I remember this mainly from the 56k days with the 2 hour disconnect time and playing game like diablo 2 and runescape.
| |
BYOND already has code to force a logout after inactivity, so the code should already be doing its job; it just isn't able to immediately detect the connection died because as far as it knows in these situations, the problem is just transient lag. With a normal disconnect, a message is sent to close the connection; when you physically disable your network, this becomes impossible.
Since I haven't seen any evidence to suggest there's any real issue here, I'm going to close the report. The bottom line is that in the event of a physical disconnect or the network going down, no program is capable of detecting that immediately. Nor would you want it to, since that would also punish users suffering from severe but temporary lag. | |
Lummox JR resolved issue (Not a bug)
| |
lol.
| |
Zelldot wrote:
Just pondering. What is the client timeout time to disconnect a client? I don't know but apparently a mob sitting there for 3 hours without a client is considered not a bug. Woo progress. | |
heh...
| |
damn internets..... got me of guard.... <(o.O)>
| |
Gokussj99 wrote:
I don't know but apparently a mob sitting there for 3 hours without a client is considered not a bug. You didn't mention 3 hours in your report. You just specified that the old character stays there after the network is physically disconnected. It would, but it shouldn't stay there indefinitely. Anything longer than 15 minutes I'd say is a bug, unless this is a telnet connection. However I haven't seen anything in the code to verify this; we do have an inactivity timeout. Our inactivity timeout is 10 minutes for DS, 6 hours for telnet. It may take as long as another 5-minute cycle to fully disconnect, but it shouldn't be longer. The code says the server will attempt a ping every 5 minutes, and it increments a counter; once that counter has reached its limit, the client is disconnected. Any incoming message from the client resets the counter. Therefore the server will always disconnect the link after a connection has timed out. client.Del() and mob.Logout() should both reliably be called if a user was logged into a mob. | |
Lummox JR wrote:
Gokussj99 wrote: Why is it 6 hours for telnet that would explain a lot considering 99% of the clients in my game are telnet... Could this maybe be set to 10 minutes as well.. i mean i know telnet clients are probably not common so i don't think a lot of people would mind this change for telnet. | |