Disconnect on Death in bind zone

sfisque · #1 12-05-2006, 10:06 AM

i'm cross posting this from the windows server forum, so that it might get some attention here. my C++ is pretty decent but i'm still trying to find where all the pieces connect together.

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

John Adams · #2 12-05-2006, 03:13 PM

Nice. Is there anything in the logsys you can turn on to capture what the server is saying to the client? When I kick on logging, I get tons of info - some of it actually makes sense sometimes.

sfisque · #3 12-05-2006, 03:18 PM

nothing useful. basically the server isnt complaining and disconnecting the user. which leads me to believe the client is waiting for something from the server and not getting it, or its getting something that confuses it and it disconnects.

i'm not seeing anthing that looks like an exception or error message, just lots of "i'm doing this to that object" stuff type messages.

== sfisque

ps: i'm almost tempted to try running ./zone inside of a debugger, but i'll have to learn how to use gdb first

**cavedude** · #4 12-05-2006, 03:20 PM

While debugging, you should also keep in mind that the 0.6.2 client does not suffer from this bug, only Titanium so any changes made has to allow both to work.

sfisque · #5 12-05-2006, 04:03 PM

how would one acquire this mystical 0.6.2 client? i thought the current evolution of eqemu was designed around titanium compatability?

== sfisque

**cavedude** · #6 12-05-2006, 04:18 PM

0.6.2 is used by us old-timers. It currently is far more compatible than Titanium. The problem is, we can't give it to you. It violates the forum's policies.

sfisque · #7 12-05-2006, 04:45 PM

then i guess my delving is done. i'd put money on the table that something changed in the "death, corpse, move to bind" packets between 062 and titanium and eqemu doesnt grok how to send the correct info to the newer client.

since i dont have a live account, i'm out of the loop now. anyone want to collect the packets and try patching zone to properly update the titanium client upon death?

== sfisque

**cavedude** · #8 12-05-2006, 04:52 PM

Collecting packets won't work, the Titanium client doesn't work on live. In fact, I don't think it ever did.

sfisque · #9 12-06-2006, 05:59 AM

ok.

just so i'm seeing this in the correct light, i perceive the issues are this:

(and chime in if i got it wrong)

1) at some point between 0.6.2 and titanium, something "possibly" changed in death handling on the client.

2) all of the old timers have their "golden" 0.6.2 frozen clients which work fine.

3) at some point, a line was drawn in the sand and titanium compatability was stated as the goal to prevent the constant chase with Sony.

4) there is a reticence or hesitation to fix the "death in bind zone" bug because it might invalidate the 0.6.2 version which eqemu doesnt "officially" support.

5) someone might be working on this besides me, but they havent chimed in yet.

6) my limited knowledge of the eqemu has brought me upto a brick wall.

so, barring anyone stating otherwise on the above points, does anyone want to help me out in fixing this. i chased it a decent way down. from what i can see, the disconnect happens sometime AFTER the ->Death() method returns. i know this because the toon's coords are correct (at bind point) when they respawn after the LD. i'm not an assembler whiz so disassembling the client (which could be considered illegal, i'm not sure on the specifics of that) is technically not an option atm, so i'm not sure where to go from here. there appear to be a few people who are adept at eq packet analysis and are knowledgeable of the underpinnings of the client/server relationship. do any of these people want to help me find a fix for this. i know you all have your pet projects and this is a low priority if you have the magical 0.6.2 client, but i'm sure i can fix it, if i can get a little hand holding. whether we migrate it into the CVS or put it on a branch, i dont care. i just want my server to work with titanium since thats the "communicated" line in the sand.

== sfisque

John Adams · #10 12-06-2006, 06:31 AM

Quote:

Originally Posted by sfisque

3) at some point, a line was drawn in the sand and titanium compatability was stated as the goal to prevent the constant chase with Sony.

4) there is a reticence or hesitation to fix the "death in bind zone" bug because it might invalidate the 0.6.2 version which eqemu doesnt "officially" support.

Priceless. This sounds like the same logical thinking we do at work every day.

Thanks for the chuckle.

sfisque · #11 12-06-2006, 06:54 AM

np man. i'm just trying to wring out some help on this. i know i'm preaching to the "anti-choir" because as far as they're concerned, "it works for me".

/sigh

admittedly, this is a side project for all of us, some more than others. so asking for help to fix something that a bunch of people have little desire to fix is never a fun endeavor to sell. but eqemu is something pretty awesome. for years i've preached that game companies need to tap this market, the "lets sell the engine and design kit" and let others author the product, concept.

if sony/blizzard/bio/etc. were really smart, they would sell hosting and give the engine away. maybe open-source needs to teach them the way. maybe i'm a raving lunatic. who knows. but i want my server to work for my buddies. know what i mean

== sfisque

Angelox · #12 12-06-2006, 07:05 AM

If it were not for things like the Titainium client and the DRP installer, I may not have ever had a start at EqEmu.
Titanium release was an "invitation" for everyone to come and enjoy. I'm grateful for that. I also understand there are very few people working on the Eqemu source, and what they do has priority over other things.
I see a lot of problems that could use fixing in the emulator, but I'm sure the Devs already know about it, and have all this in mind. The drive now is to work towards Titanium, and they only way to pitch in with the source would be to contact the Devs and ask them what I can do, maybe offer them a solution to problems like "disconnect on death - other than that it's just beating on a dead horse.

sfisque · #13 12-06-2006, 07:14 AM

agreed. i'm offering to work on this. i hope that was clear. if its not, then "i'm offering to work on this". :P

anyway, here are some questions i have:

1) has anyone ever put the client in a harness or debugger environment to capture how it responds to the server (not sure if doing so would be a violation of eula, so bear with me if it is.)

2) i looked at the "asm" hint pages in the dev area. its been "a very long time" since i touched assembler, so if anyone wants to shoot some hints or caveats my way, i'm all ears.

3) if someone is already working on this, toss up a shout. no need to duplicate effort. i'll work on the assumption that silence means i'll be slugging alone on this.

4) did i mention that i'd welcome any hand holding that can be made available :P

== sfisque

sesmar · #14 12-06-2006, 07:17 AM

Quote:

Originally Posted by sfisque

4) there is a reticence or hesitation to fix the "death in bind zone" bug because it might invalidate the 0.6.2 version which eqemu doesnt "officially" support.
== sfisque

I do not believe this to be true, I do believe; however, I could be wrong, that this is an issue with the opcodes and since there is support for multiple clients, (the server pulls the correct opcodes file for that client if it is supported and the file exists) this should not affect the behavior of the 0.6.2 client. Now I do not want to send you down the wrong path so you might want to get this confirmed by one of the developers first but here is a link the wiki page that explains how to find opcodes:

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

#15 12-06-2006, 07:51 AM

Quote:

Originally Posted by sfisque

4) there is a reticence or hesitation to fix the "death in bind zone" bug because it might invalidate the 0.6.2 version which eqemu doesnt "officially" support.
== sfisque

Dont want to fix it? The issue is we have one active Developer and he (FNW) has been doing a lot of other things.

There was a time when we had 10-20 active developers but those days are long gone, EQEMU is being kept alive by users submitting bug fixes at this point.