Another odd problem

[Arco.]

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.

 Spoiler

Got a player with hero id! 1000003 -- Thu Dec 08 22:36:03 2011
¡ïASSERT(m_idArmor[_PART_ORG])¡ï in E:\CQ2ClientRelease-19.10.2\RoleView\3DRole.cpp, 1198 -- Thu Dec 08 22:36:06 2011
Error: motion(194000100) can't found. -- Thu Dec 08 22:36:06 2011
Action 194000100 and default action 0 cannot be found. -- Thu Dec 08 22:36:06 2011
Error: motion(194000101) can't found. -- Thu Dec 08 22:36:06 2011
Action 194000101 and default action 0 cannot be found. -- Thu Dec 08 22:36:06 2011
¡ïASSERT(m_idArmor[_PART_ORG])¡ï in E:\CQ2ClientRelease-19.10.2\RoleView\3DRole.cpp, 1198 -- Thu Dec 08 22:36:06 2011
Error: motion(194000100) can't found. -- Thu Dec 08 22:36:06 2011
Action 194000100 and default action 0 cannot be found. -- Thu Dec 08 22:36:06 2011
Error: motion(194000102) can't found. -- Thu Dec 08 22:36:06 2011
Action 194000102 and default action 0 cannot be found. -- Thu Dec 08 22:36:06 2011
¡ïASSERT(m_idArmor[_PART_ORG])¡ï in E:\CQ2ClientRelease-19.10.2\RoleView\3DRole.cpp, 1198 -- Thu Dec 08 22:36:06 2011
Error: motion(194000100) can't found. -- Thu Dec 08 22:36:06 2011
Action 194000100 and default action 0 cannot be found. -- Thu Dec 08 22:36:06 2011
Error: motion(194000103) can't found. -- Thu Dec 08 22:36:06 2011
Action 194000103 and default action 0 cannot be found. -- Thu Dec 08 22:36:06 2011
¡ïASSERT(m_idArmor[_PART_ORG])¡ï in E:\CQ2ClientRelease-19.10.2\RoleView\3DRole.cpp, 1198 -- Thu Dec 08 22:36:06 2011
Error: motion(194000100) can't found. -- Thu Dec 08 22:36:06 2011
Action 194000100 and default action 0 cannot be found. -- Thu Dec 08 22:36:06 2011
Error: motion(194000102) can't found. -- Thu Dec 08 22:36:06 2011
Action 194000102 and default action 0 cannot be found. -- Thu Dec 08 22:36:06 2011
¡ïASSERT(m_idArmor[_PART_ORG])¡ï in E:\CQ2ClientRelease-19.10.2\RoleView\3DRole.cpp, 1198 -- Thu Dec 08 22:36:06 2011
Error: motion(194000100) can't found. -- Thu Dec 08 22:36:06 2011
Action 194000100 and default action 0 cannot be found. -- Thu Dec 08 22:36:06 2011
Error: motion(194000102) can't found. -- Thu Dec 08 22:36:06 2011
Action 194000102 and default action 0 cannot be found. -- Thu Dec 08 22:36:06 2011
¡ïASSERT(m_idArmor[_PART_ORG])¡ï in E:\CQ2ClientRelease-19.10.2\RoleView\3DRole.cpp, 1198 -- Thu Dec 08 22:36:06 2011
Error: motion(194000100) can't found. -- Thu Dec 08 22:36:06 2011
Action 194000100 and default action 0 cannot be found. -- Thu Dec 08 22:36:06 2011
Error: motion(194000103) can't found. -- Thu Dec 08 22:36:06 2011
Action 194000103 and default action 0 cannot be found. -- Thu Dec 08 22:36:06 2011
¡ïASSERT(m_idArmor[_PART_ORG])¡ï in E:\CQ2ClientRelease-19.10.2\RoleView\3DRole.cpp, 1198 -- Thu Dec 08 22:36:06 2011
Error: motion(194000100) can't found. -- Thu Dec 08 22:36:07 2011
Action 194000100 and default action 0 cannot be found. -- Thu Dec 08 22:36:07 2011
Error: motion(194000110) can't found. -- Thu Dec 08 22:36:07 2011
Action 194000110 and default action 0 cannot be found. -- Thu Dec 08 22:36:07 2011
¡ïASSERT(m_idArmor[_PART_ORG])¡ï in E:\CQ2ClientRelease-19.10.2\RoleView\3DRole.cpp, 1198 -- Thu Dec 08 22:36:07 2011
Error: motion(194000111) can't found. -- Thu Dec 08 22:36:07 2011

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?

[BaussHacker]

You need to send the kitchen packet.

[Spirited]

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 ***** 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).

[Arco.]

Originally Posted by Fаng

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 ***** 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?

[Spirited]

Originally Posted by Arco.

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.

[Arco.]

Originally Posted by Fаng

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.

[Spirited]

Originally Posted by Arco.

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?

[Arco.]

Originally Posted by Fаng

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 ****** up mesh, small females can't at all.

[KraHen]

Maybe you`re using the wrong offsets for your patch version? :P

[Spirited]

Originally Posted by Arco.

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 ****** 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 ****** up error though. Mine wasn't that ****** 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.

Originally Posted by KraHen

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.

[KraHen]

Not if only the mesh offset is off by a value of 1.

[Arco.]

Originally Posted by Fаng

If it varies like that, it might have to do with the socket system handling packets incorrectly on another thread. That is a really ****** up error though. Mine wasn't that ****** 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.

[KraHen]

Sounds either like an infinite loop, a deadlock or a died thread/socket.

[Arco.]

Originally Posted by KraHen

Sounds either like an infinite loop, a deadlock or a died thread/socket.

But why would it pertain to only certain meshes?

[KraHen]

Originally Posted by Arco.

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.