ID:179472
 
Okay, I was testing my project by allowing a friend of mine to log in and out. It turns out that when he logged out, his little dude was still on the screen! When he logged back in, he jumped back into the 'body. In fact, even if he created a new character, he would appear where the old 'body' was. How do I come up with a clean logout system which gets rid of those derelict little icons? My save method is one where I manually save mob variables I wish to keep (I do not save the whole mob).

Currently, I don't have any code that tells players where their icons should be placed on log-in (I should probably do this, eh?).

-- John
Felegar wrote:
Okay, I was testing my project by allowing a friend of mine to log in and out. It turns out that when he logged out, his little dude was still on the screen! When he logged back in, he jumped back into the 'body.

We oughta make a FAQ entry for this...anyway that's exactly how it's supposed to work! BYOND was originally designed for MUDs where the mob would persist when the player logged off.

To get rid of it, just delete the mob in Client.Del():

client
Del()
del(mob)
return ..()
In response to Deadron
Deadron wrote:
To get rid of it, just delete the mob in Client.Del():

client
Del()
del(mob)
return ..()

Okay, this has nothing to do with what you just told me, but it has been really bothering me... Why do I see the return proc everywhere? Why would I type 'return ..()' instead of just '..()' ? If it is important, than my project's code has some serious problems, because don't have a return proc once in it. Looking it up in the help-files doesn't really explain its usefulness. Is there a tutorial on that procedure?

-- John
Felegar wrote:
Okay, I was testing my project by allowing a friend of mine to log in and out. It turns out that when he logged out, his little dude was still on the screen!

I don't know anything about your save system or anything, but to get rid of the mob when they logout, just do this;

mob
Logout()
del(src)

Hope I helped

?The Wizard of How¿
In response to Felegar
Felegar wrote:
Okay, this has nothing to do with what you just told me, but it has been really bothering me... Why do I see the return proc everywhere? Why would I type 'return ..()' instead of just '..()' ?

In case the function you are in returns an important value. For example, say you override Enter() to put some extra checking up front and you only use ..():

turf
Enter()
// My special checking goes here...

// Now let the normal checking happen.
..()


Well, nothing will ever be able to enter any turf. Why not? Because you never return a value, so it will always be like zero was returned. If you return the value of the superclass method, then things work correctly:

turf
Enter()
// My special checking goes here...

// Now let the normal checking happen.
return ..()


I always use return for this, even when I know it's not needed, so that I never forget when it is needed.