Disconnect on Death

[sfisque]

using titanium. was unaware that eqemu worked with anything else.

== sfisque

[John Adams]

I'll add my findings to this (just posted under KMRA's bug list too).

If I CTRL-X (camp) on my Windows XP box client connected to my Windows 2003 EQEmu server, with MySQL on Linux, my client LDs every-single-time. Just camping. Not bound in the zone.

Just by chance, I ran a client ON the Windows 2003 Emu server, and camped with no issue. Same char, same bind point, no death testing. But I have seen the LD-on-Death issue, too.

Hope this helps someone find the problem. I don't think you have to die to reproduce it.

[sfisque]

with some detective work, i've managed to narrow down where this might be.

i tried changing the return value of Client::Process() (on line 122 in client_process.cpp - v.871) from false to true or just commenting it out and letting the method continue working along after it decides a person is dead. what i found is:

with the return set to true or commented out, the client didnt disconnect. the client also never left the "staring at your corpse" camera angle if i died in the same zone as i was bound in. if i died in a different zone, i popped at my normal location.

digging deeper...

i followed the execution logic upto entity.cpp. it looks like all the "process" methods, if the sub-called Process() method returns false, the object is removed from the list, otherwise the current list pointer is advanced. my guess at this point, upto now, is that we dont want to "remove" the object in question (the client) but rather just twiddle with it and move them to the right spot. there appears to be something in the "move them home" code that gets wedged if its merely "across town" and not to a different zone. what i'm trying to figure out is why if i dont "remove the object" by returning false, i dont get relocated back to bind and my camera fixed back to normal. (the interface gets jacked up also, all the button bars and stuff get "hidden" leaving only the chat windoid; my guess, not returning false is causing the server to not send some update packet to the client, maybe?)

anyway, i'll continue to dig, but i'm constantly running up against my limited knowledge of the source base, though i'm learning alot about how this thing is put together.

== sfisque