Deprecated Darkstar fourms

I have read all reports on this message in these forums. The only thing I can figure out so far, is I am running debian 7 x64. Now, I tried using debootstrap and installing i386 bound to one of my extra IP's and still same error. Even using successfully. I still get that. I even tried to cheat, by putting home coordinates into current coordinates... same thing. This is aggravating, and what is more aggravating is this has been mentioned a few times, but there is no solution.

What I would like to know is how to fix this. I cannot reinstall debian i386 instead of debian amd64. I have wow servers running, websites, and many other programs dependent on the 64bit OS.

What causes this issue and why isn't anyone trying to fix it? I know a little C++ but I cannot figure out the source of the problem. It makes no sense to me why it works fine in 32 but not in 64. and actually, I have not tested in 32bit yet, so I don't know if it works fine there. I notice updates all the time in the svn, so I know this project is alive and kicking. Everything looks so great so far.

Please point me in the right direction to help fix this. I will share if I get it working, but I haven't a clue at this point. I am not familiar with the structure.

Sorry for blabbing and thanks in advance.

EDIT: a little update. I have set my IP in zone_settings. my IP is 70.38.68.194 and the number I get is 3259246150 please let me know if that is correct. it is also set for port 54230 and I hope that is ok, but not sure if it matters. no ports are blocked at all.

lordpsyan wrote:What causes this issue and why isn't anyone trying to fix it?

i've always been told it's something to do with the blowfish encryption, but i've never really looked at it. it comes up when the client is sending a request to change to a new zone packet, but the character isn't in STATUS_DISAPPEAR (faded out) and their current zone isn't null (ie. something weird happened while zoning). naturally, as it's dealing with packets, it's a pain to debug, and i haven't really had the time to do anything big because of school. shouldn't be *too* hard to follow the login process to see where deviation happens (login starts in map.cpp:422ish, then you could set a data breakpoint on PChar->status and another regular breakpoint in SmallPacket0x00A and see why it changes (or if it's going through 0x00A twice or what)