Disconnect on Death
 

Every Time someone dies when connected to my server (internal lan settings) They are disconnected from the server.

Any Ideas?

Thanks in advance :)

Do an advanced search here for "Disconnect Death" and you'll find many threads discussing this. But in summary, it's a known issue and you are not alone.

That's a "feature" that's implemented so people get a taste of the harsh reality that is death...okay maybe not...but I had to try.

I was told it happens when you die in the same zone your bound in.

People have different experiences with this. It's not always the same. Like my toon can log in, move a few steps, then sit and camp no problem. But if I zone and camp, I am disconnected.

I think dev knows about this one.

personal experience is that it doesnt happen if you use a seperate machine as your server... but it happens almost all the time if you are running the game on the same machine as your server.

I have found a workaround but it's just as annoying... if you static your zones it wont drop world, thing is that you will either need a LOT of ram or keep yourself in a small area between gameloads...

to set static zones (since there is no help file I could find) use the http command console included with the server... if you dont know how to do that... well... download my Apophis Edition of the server it has info for all these kinds of things.

...
 

Whats Apophis Edition ?
is that something you modified from PEQ/Cavedude/Sesmar ?

i have found some good info.
 

to use the http server editor thing..

http://www.eqemulator.net/wiki/wikka...rverWorldLogin

this link got me up and running with it.

Case in point, my world/zones are always on a remote server, and I crash on death/camp after moving around a bit. I haven't tested this with static zones yet, but all my cities are static now so I'll give it a try.

I can confirm. While playing on the same machine as the server is hosted, if I am bound in the zone I die in, I go LD. If I am bound elsewhere, everything works just fine. I have not tested this on a machine that is not hosting the server.

tested on split setup. server running on slackware server, game on separate windoze box. bind in zone, die in same zone, insta-disconnected and popped out to the login window (or rarely, the toon chooser).

== sfisque

What client are you all using as I am not havign this problem using the 6.2 client and my server is running on three different computers, 1 for SQL, 1 for world and three zone launchers. the last for 3 more launchers, in total I boot 104 zones on two different computer. None of my dynamic of static zones show effect.

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

== sfisque

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.

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