Logout being called before Login

ID:149978
 
Jan 12 2002, 9:06 pm
ok here's my code:
    New()
        if(src.key)
            var/player_sav = "Players/[ckey(src.key)].sav"
            if(file(player_sav))
                var/savefile/F = new(player_sav)
                F >> src
                return ..()

This works, but for some reason, Logout is called before login. Any clue why?
Jan 12 2002, 9:22 pm
I'm not sure what this is New of, but my guess is the sequence of events you're seeing goes roughly like this:

1) A player connects to the game.
2) A client object is generated to handle that player.
3) A mob of type world.mob is generated for the client to connect to. As far as I know, a login should be happening here... not sure why you're not seeing it occur before the logout. I guess it depends on what you have happening during login and logout that you're registering... output may be generated that you don't see, because it happens while you're still connecting, or something like that.
4) In the New procedure for that mob, it is recognized that the mob has a key, so it reads from the savefile.
5) A new mob (a copy of the mob in the savefile) is generated.
6) The client is disconnected from the default mob **THE LOGOUT YOU SEE OCCURS HERE**
7) The client is connected to the new mob. **THE LOGIN YOU SEE OCCURS HERE*
Jan 12 2002, 9:33 pm
In response to Lesbian Assassin
Wow you really hit the nail on the head... Thanks!
Jan 12 2002, 9:38 pm
In response to Lesbian Assassin
What you said must be true (it only says I logged out when i log in if i run that New statement).
But how would I go about preventing this from hapenning? I tried moving it to the Login() but when I ran the game, I just sat at a blank screen.
Jan 12 2002, 9:47 pm
In response to Dreq
That's because you overwrote the default Login() proc, which simply moves the mob from null location (meaning, nowhere... hence the black screen) to the first available square on the map.

Here's an important thing to remember:

..()

means "The parent procedure", or "do what this proc normally does."

Try something like:

Login()
..()
//your code here.

This is not a guaranteed fix... I'm not sure what your code is or what it does. Just one possibility.

Another common technique is to have your login mob (also known as default mob, or world.mob) be a special mob, distinct from the regular player mob.

mob/creating_character

or

mob/login_character

or something like that.

You can have the normal character handling/character creation routines defined under this mob's login or new proc, and what those procs would do is create a mob/player (either a new one, or loading the old one from the save file) and then connect the player to that mob. mob/player would just have the normal Login() proc, or the Login() proc you've defined for your game (if you want to move new players to a specific location or something, Login() is the logical place to do it.)

Just a few techniques to think about.
Jan 12 2002, 9:50 pm
In response to Lesbian Assassin
Lesbian Assassin wrote:
Just a few techniques to think about.

I wouldn't be me if I didn't now mention that all the techniques Lexy discussed can be seen in the demo of my CharacterHandling library...which could save you hassle:

byond://Deadron.CharacterSaving
Jan 12 2002, 10:09 pm
In response to Deadron
Thanks for the help, you showed me right to the answer!

Here's what I ended up doing:
First, I added /var/LoggedIn="False" to the player mob. Then I had the first command in the Login() proc as src.LoggedIn="True". THEN I coded my Logout() proc as follows:
    Logout()
        if(src.LoggedIn=="True")
            src.LoggedIn="False"
            if(src.MHP>=99999)
                alert("You were in god mode, so your game will not be saved.")
            else
                var/player_sav = "Players/[ckey(src.key)].sav"
                var/savefile/F = new(player_sav)
                F << src
            world << "\icon[src] [src] has left the game!"
            ..()
            del src


This is the best way I could figure to do it, since my game is too far along to be adding libraries to it :) (Plus I don't normally use librarys because I learn more by asking people and solving problems manually (And reading the guide ^_^)
Jan 12 2002, 10:22 pm
In response to Dreq
Ah, I knew I was neglecting an alternative...

(Plus I don't normally use librarys because I learn more by asking people and solving problems manually (And reading the guide ^_^)

I don't know that Deadron was suggesting you use his library (although he wouldn't be Deadron if he didn't)... it almost seemed to me that he was (rather uncharacteristically) suggesting that you take a look at its code, to see the techniques in action... which I would suggest as a good way for an intelligent, hands-on person to learn.
Jan 12 2002, 10:32 pm
In response to Lesbian Assassin
Lesbian Assassin wrote:
I don't know that Deadron was suggesting you use his library (although he wouldn't be Deadron if he didn't)... it almost seemed to me that he was (rather uncharacteristically) suggesting that you take a look at its code, to see the techniques in action... which I would suggest as a good way for an intelligent, hands-on person to learn.

Well the demo part is what shows these techniques and is designed to be used/copied, whether the library is used or not.

The library is actually a very small part of it, but it does solve some problems most people don't think about (like how to make sure it will work for a near-infinite number of players smoothly), so it's at least worth looking at if not using.

There is one unfortunate exception to the "near infinite players"...it doesn't check for unique names across the entire player space, and it should.