In Tanks, a disconnected client leaves a display object in the player list, and is reunited with the display object if they return to the game. This happens in the client.New() proc:
New()
display = null
for(var/obj/display/D in players)
if(D.tag == "[src.key]")
display = D
break
if(!display)
display = new()
display.tag = "[src.key]"
display.suffix = ""
display.icon = 'team.dmi'
display.icon_state = ""
players += display
display.player = src
display.name = "spectator"
..()
All of the mob login codes update client.display to indicate what type of mob they are playing, but when a player disconnects, then logs back in, DreamSeeker logs it into the mob before client.display is assigned. No client can get through the New() proc without a display object, so it seems that mob.Login() is running befome client.New() does.
ID:137593
 Sep 18 2001, 5:57 pm
|
|
That was real helpful. :P
What I meant, is that mob.Login() happens before client.New() when someone reconnects to a game. This seems backwards to me, since a client is attached to something before it is created. | |
Hrm, I think this has to do with a mob with a key matching the clients already existing. Does it also do this with new mobs? Not that that explains why the login is being called before client.New....
-James | |
Shadowdarke wrote:
All of the mob login codes update client.display to indicate what type of mob they are playing, but when a player disconnects, then logs back in, DreamSeeker logs it into the mob before client.display is assigned. No client can get through the New() proc without a display object, so it seems that mob.Login() is running befome client.New() does. Hmm, looks like a bug. The default handler in client.New() should be calling the mob.Login() to reconnect to the existing mob, but as you noted the Login() event occurring independently. Good find. | |
Isnt that how it usually works?
First when a client connects to the server, Login() hits, doing whatever it needs to do, and then calling New() to create a mob for the user to be connected to. In the case of what you posted, Id think that Login would hit first, and then since theres -already- a mob for that key, new wouldnt be needed at all, the existing mob just has to be moved to a playable location.. Granted Im kinda a n00b, but thats how I see it happening.. Elorien | |
Elorien wrote:
Isnt that how it usually works? Close. The client.New() proc is called everytime you login to the world. By default, it checks your key against existing keys in the game; if it finds one, it calls mob.Login() on that mob, otherwise it creates a mob of the default type and logs into that. So client.New() should always be called before mob.Login(). Should. For more info on this, check out the tutorial on the connection process. | |
heh