mob never loses client

Page: 1 2
ID:1134974
 
Jan 22 2013, 9:01 am
(See the best response by Magicsofa.)
Code:


Problem description:

So basically in my BYOND creation ( a text mud infact ) i try to prevent people from running from fights by checking if they logout properly if they disconnect by closing out the game it will make them go linkdead their mob loses a client and sets them as linkdead and they may reconnect to the mob while this is happening but the problem is if someone loses internet connection it bugs out and the client is never deleted from the mob and then this causes the mob to never exit at all and then this lets them relog back into the game and then there is now a duplicate of their character...is there any reason to as why their client would never be set to null while this happens?

Jan 22 2013, 9:15 am
UPDATE: It literally took like 15 minutes for the mob to realize it's client was missing...Why would their be such a huge delay.
Jan 22 2013, 10:29 am
Sounds more like a software bug to me.
Jan 22 2013, 10:59 am
:| well anyways i fixed the duplication bug but still they never go linkdead which causes a mob to sit in game for up to 15 minutes before actually leaving...during that whole time i guess a client is detected for some odd reason..
Jan 22 2013, 11:21 am
Well we can't help unless you show us the code. Also, try to use periods more often.
Jan 22 2013, 3:15 pm
In response to Magicsofa
Magicsofa wrote:
Well we can't help unless you show us the code. Also, try to use periods more often.

How can i show code when i have no idea what would make the client not delete?

There is literally no reason that it should do this lol.

        Logout()
        {
            if(quit)
            {
                dropDBS()
                if(!invis) mb_msgout("{Y-->{x [ClassColor][name][Reset] exited [worldname]!", worldmobs)
                Communicate("/world/proc/QUITGS", "[ClassColor][name]{x†[worldname]")
                worldmobs -= src
                loggedIn = 0
                quit = 0
                inArenaFight = 0
                src.Save(src)
                del(src)
            }
            else
            {
                src.Save(src)
                mb_msgout("[ClassColor][name]{x went linkdead.", oview(0, src))
                linkdead = 1
            }
        }


But the Logout proc is never called... and obviously since that isn't called then the client/Del() proc is also never called so I'm not sure what else i can show you.
Jan 22 2013, 3:34 pm
In response to Gokussj99
Gokussj99 wrote:
How can i show code when i have no idea what would make the client not delete?

Well, you should have some general idea where the problem MIGHT be. Logout() is obviously a relevant proc, and you knew that, so I think you are selling yourself short when you say you have "no idea." Besides, how are we supposed to know what's going on if we can't even look at any part of your project?

There is literally no reason that it should do this lol.

There is always a reason. Sometimes the reason may be a bug in the BYOND software, or even in your computer. But, it's usually because there is something wrong with your code. And you should be glad, because that means you can fix it yourself.

But the Logout proc is never called... and obviously since that isn't called then the client/Del() proc is also never called so I'm not sure what else i can show you.

I doubt that. This is from the reference page on Logout():

Called when a player's client has disconnected from a mob. This happens in client.Del() when the player logs out of the world. It may also happen when the player switches from one mob to another.

Logout() doesn't initially do anything, it is only there for you to write in your own behavior for a disconnecting player. client/Del() is called first.

I think the problem is somewhere other than Logout(). Did you override the Del() proc? What about the 'quit' variable, are you sure it is being properly set?

Jan 22 2013, 5:55 pm
In response to Magicsofa
Magicsofa wrote:
Gokussj99 wrote:
How can i show code when i have no idea what would make the client not delete?

Well, you should have some general idea where the problem MIGHT be. Logout() is obviously a relevant proc, and you knew that, so I think you are selling yourself short when you say you have "no idea." Besides, how are we supposed to know what's going on if we can't even look at any part of your project?

There is literally no reason that it should do this lol.

There is always a reason. Sometimes the reason may be a bug in the BYOND software, or even in your computer. But, it's usually because there is something wrong with your code. And you should be glad, because that means you can fix it yourself.

But the Logout proc is never called... and obviously since that isn't called then the client/Del() proc is also never called so I'm not sure what else i can show you.

I doubt that. This is from the reference page on Logout():

Called when a player's client has disconnected from a mob. This happens in client.Del() when the player logs out of the world. It may also happen when the player switches from one mob to another.

Logout() doesn't initially do anything, it is only there for you to write in your own behavior for a disconnecting player. client/Del() is called first.

I think the problem is somewhere other than Logout(). Did you override the Del() proc? What about the 'quit' variable, are you sure it is being properly set?



This has nothing to do with quit logging out that way works fine this is not the issue at all.. I am saying the client is never realized as missing until 15-20 minutes after the client actually disconnects no client/Del() was never changed quit doesn't need to be set because there is a proc running on the mob every so often to check if there is a client and if there isn't then it will set quit to 1 then logout properly.
Jan 22 2013, 6:03 pm
Best response
Well, I think you can accomplish this without ever checking the client itself. Perhaps it is just a limitation of BYOND that you can't get an accurate real-time reading of the client? I didn't think that was true but I have never tried what you are doing.

Anyway, why not use a counter that keeps track of whether the mob is in combat? When an attack happens the counter is reset, and it slowly decreases until it reaches 0. If the player disconnects suddenly while the counter is above 0, leave the mob there until it does reach 0 and then save/delete the mob. Would something like that accomplish what you want?
Jan 22 2013, 6:12 pm
sorta but it has its disadvantages.

guess i have no other choice.
Jan 22 2013, 10:07 pm
This seems to definitely be a BYOND bug, and something I'd wager would receive enough attention to get a relatively quick fix. If client/Del is not being called upon a player exiting the world, something is really messed up. Or it could simpyl be that you have overriden client/Del somewhere else and forgot to call ..()
... infact, looking at your logout() code up there it wouldn't hurt to have a ..() in there too, for good measure
Jan 23 2013, 1:55 am
Logout is an empty proc. ..() should not do anything

Goku, try some debug messages like this:

client
    Del()
        world << "[mob] is logging out..."
        ..()


You could do a similar thing in Logout() to output the value of 'quit.' This should verify the procs are executing when they should
Jan 23 2013, 2:16 am
In response to Magicsofa
Magicsofa wrote:
Logout is an empty proc. ..() should not do anything

Goku, try some debug messages like this:

> client
>     Del()
>         world << "[mob] is logging out..."
>         ..()
>

You could do a similar thing in Logout() to output the value of 'quit.' This should verify the procs are executing when they should

Yeah i already tested that and it never output anything in the world log at all.

so that means client/Del() never happened. and client/del was modified but there should be no issue here is the code of where it is modified.

client
    var
        mb_application = BYOND
    New()
        MUDbase.players += src
        if(findtext(key,"@")) mb_application = TELNET
        else mb_application = BYOND
        return ..()
    Del()
        world.log << "[mob.name] no client."
        MUDbase.players -= src
        return ..()


But i have determined if you closeout the game suddenly client/Del() is called fine but if someone say loses internet access or dcs due to packet loss their client is not recognized as lost... it seems to be a bug within BYOND.
Jan 23 2013, 2:56 am
http://www.byond.com/forum/?post=1135870

this is obviously a bug i have reported it and tested it with other games such as eternia and each time the same bug happens.
Jan 23 2013, 3:34 am
world.log is known to behave weird early and late in execution and termination

try out putting text directly to a file.
Jan 23 2013, 3:37 am
In response to FIREking
FIREking wrote:
world.log is known to behave weird early and late in execution and termination

try out putting text directly to a file.

read the above post lol
Jan 23 2013, 9:16 am
In response to Magicsofa
Magicsofa wrote:
Logout is an empty proc. ..() should not do anything

Thanks for the lesson. If you noticed, I said 'for good measure'. In case he has overridden it, or ever does override it, anywhere else in his code.
Jan 23 2013, 2:32 pm
In response to Metamorphman
Metamorphman wrote:
Thanks for the lesson.

My pleasure.

I'm pretty sure Gokussj is smart enough not to have multiple Logout() overrides, and if not then throwing parent calls around "for good measure" is no way to improve his code.
Jan 23 2013, 2:43 pm
In response to Magicsofa
Magicsofa wrote:
Metamorphman wrote:
Thanks for the lesson.

My pleasure.

I'm pretty sure Gokussj is smart enough not to have multiple Logout() overrides, and if not then throwing parent calls around "for good measure" is no way to improve his code.

Its not necessarily a bad thing to have multiple over rides, but only if you know what you're doing, and why you're doing it.
Jan 23 2013, 2:48 pm
True, if you had two different mobs that you needed different logout code for, or some special case that would always be true for one mob which then calls the parent proc. That seems a little obscure though (switching between mobs is already something that people generally do not do) and I don't think it would make any sense in this scenario
Page: 1 2