Another odd problem

Page 1 of 3 1 23
12/09/2011 06:57 Arco.#1
Alright I've made many sources before, but I've NEVER came across this problem before. Males can login, but females can't. When a female logs in, they either get stuck at initializing or they get disconnected at SetLocation being sent to client. This is for patch 5180.

I login and I check the client's debug log and I see all this.

I check the meshes at login and they are valid.
2042002
2152001
etcetera.

I've never faced this problem before, has anyone ever experienced this?
12/09/2011 07:00 BaussHacker#2
You need to send the kitchen packet.
12/09/2011 07:25 Spirited#3
I actually wrote this response before seeing your immature "inbfangsays" paragraph:
---------------------------------------------------------------------------------

Project Kibou had this problem. I'm pretty sure it was something to do with character info or how I was breaking up the packets. Don't be a bitch and break point it. Where does it hang (not visually, but where does it literally STOP handling the client's login - where and after sending what).
12/09/2011 07:41 Arco.#4
Quote:
Originally Posted by Fаng View Post
I actually wrote this response before seeing your immature "inbfangsays" paragraph:
---------------------------------------------------------------------------------

Project Kibou had this problem. I'm pretty sure it was something to do with character info or how I was breaking up the packets. Don't be a bitch and break point it. Where does it hang (not visually, but where does it literally STOP handling the client's login - where and after sending what).
Obviously I tried that, how else would I know the client disconnects at SetLocation?
12/09/2011 08:08 Spirited#5
Quote:
Originally Posted by Arco. View Post
Obviously I tried that, how else would I know the client disconnects at SetLocation?
You said "or", so find out where it hangs / disconnects using a desk check.

Edit: Desk checks are when you follow a variable along as it goes through an algorithm, in this case, follow the client as it goes through the login sequence.
12/09/2011 08:16 Arco.#6
Quote:
Originally Posted by Fаng View Post
You said "or", so find out where it hangs / disconnects using a desk check.

Edit: Desk checks are when you follow a variable along as it goes through an algorithm, in this case, follow the client as it goes through the login sequence.
I already followed it, when it hangs, its at the same location.
12/09/2011 08:23 Spirited#7
Quote:
Originally Posted by Arco. View Post
I already followed it, when it hangs, its at the same location.
Before or after you send it? Does it disconnect RIGHT when you send it? You said before that it sometimes just hangs and sometimes it just disconnects. Does it do one... the other... both?
12/09/2011 09:50 Arco.#8
Quote:
Originally Posted by Fаng View Post
Before or after you send it? Does it disconnect RIGHT when you send it? You said before that it sometimes just hangs and sometimes it just disconnects. Does it do one... the other... both?
RIGHT when its sent server->client.
It varies, sometimes get stuck at init.
Sometimes disconnects.
And also, its odd, Large females can login, but with fucked up mesh, small females can't at all.
12/09/2011 10:08 KraHen#9
Maybe you`re using the wrong offsets for your patch version? :P
12/09/2011 10:16 Spirited#10
Quote:
Originally Posted by Arco. View Post
RIGHT when its sent server->client.
It varies, sometimes get stuck at init.
Sometimes disconnects.
And also, its odd, Large females can login, but with fucked up mesh, small females can't at all.
If it varies like that, it might have to do with the socket system handling packets incorrectly on another thread. That is a really fucked up error though. Mine wasn't that fucked up - I think it was that my cipher was advancing incorrectly.

When you're doing your desk check, do you follow it to where it stops? If it stops at the end of the receive and doesn't initiate the next receive, then you have a packet / socket problem. If it does the next receive but the length is insane and causes a disconnect, then you know that's obviously a cipher problem.

Edit: Does it really stop RIGHT at the send as you say it does? Or is there another thread behind it? Put a breakpoint on the receive like I said. Hopefully you figure it out.

Quote:
Originally Posted by KraHen View Post
Maybe you`re using the wrong offsets for your patch version? :P
If it were the packet, then it would still advance but show a black screen with the GUI.
12/09/2011 10:23 KraHen#11
Not if only the mesh offset is off by a value of 1.
12/09/2011 10:47 Arco.#12
Quote:
Originally Posted by Fаng View Post
If it varies like that, it might have to do with the socket system handling packets incorrectly on another thread. That is a really fucked up error though. Mine wasn't that fucked up - I think it was that my cipher was advancing incorrectly.

When you're doing your desk check, do you follow it to where it stops? If it stops at the end of the receive and doesn't initiate the next receive, then you have a packet / socket problem. If it does the next receive but the length is insane and causes a disconnect, then you know that's obviously a cipher problem.

Edit: Does it really stop RIGHT at the send as you say it does? Or is there another thread behind it? Put a breakpoint on the receive like I said. Hopefully you figure it out.



If it were the packet, then it would still advance but show a black screen with the GUI.
Lemme clarify something;
When the client disconnects, the source still goes on with everything since the client is still an un-null variable. But when its stuck at initializing, its directly onto the sending of the SetLocation, then the source stops processing said client.
12/09/2011 10:55 KraHen#13
Sounds either like an infinite loop, a deadlock or a died thread/socket.
12/09/2011 11:16 Arco.#14
Quote:
Originally Posted by KraHen View Post
Sounds either like an infinite loop, a deadlock or a died thread/socket.
But why would it pertain to only certain meshes?
12/09/2011 11:20 KraHen#15
Quote:
Originally Posted by Arco. View Post
But why would it pertain to only certain meshes?
Said above. Check if your packet mesh is wrong by 1 offset, that could mean your packetwriter doesn`t work properly neither and causes whatever, like an overflow which could stop the rest of the process. :)
Page 1 of 3 1 23