Issue on latest CO version.

Quote:

Originally Posted by -impulse- It's not a bot check as far as the client is concerned... the client doesn't return a packet back... and the client wouldn't need to receive the timeGetTime() for the char creation. Beside this packet is always sent after 1004 answer_ok (2100 or 2101)...

How dumb wold it be if the client returned the packet back :rolleyes:

Beside.
New role seq packets
Server -> Client 1059
Client -> Server 1124
Server -> Client 1213
Client -> Server 1214
Server -> Client 1055
Client -> Server 1100
Client -> Server 1052
Client -> Server 1052
Server -> Client 1004 NEW_ROLE
Server -> Client 2079
Server -> Client 2078

Login seq packets
Client -> Server 1001
Server -> Client 1004 ANSWER_OK
Client -> Server 1052
Server -> Client 1044
Client -> Server 1044
Server -> Client 2079
Server -> Client 2078
Server -> Client 1004 ANSWER_OK
etc
If just if that makes any sense to you.

Quote:

Originally Posted by -impulse- m7mdxlife ... check the title of the thread ... :confused: does it tell you anything?

The title told me that you have an issue with the latest version, then in the 1st line you stated that the problem started a while back since the login sequence changed a while back.

anyway best of luck mate

Quote:

Originally Posted by m7mdxlife The title told me that you have an issue with the latest version, then in the 1st line you stated that the problem started a while back since the login sequence changed a while back. anyway best of luck mate

Sorry for my ambiguity then.

As for { Angelius }:

Serverside you don't need to sent to the client a specific packet to be able to store the value of timeGetTime()... if you get what I mean.
Example:
Client logins, I reply with NEW_ROLE, and I store in client.CreateTime = timeGetTime();
When the client answers with 1001, I can do timeGetTime() - client.CreateTime to get the seconds that passed :S... no need to send other packets.

Quote:

Originally Posted by -impulse- Sorry for my ambiguity then. As for { Angelius }: Serverside you don't need to sent to the client a specific packet to be able to store the value of timeGetTime()... if you get what I mean. Example: Client logins, I reply with NEW_ROLE, and I store in client.CreateTime = timeGetTime(); When the client answers with 1001, I can do timeGetTime() - client.CreateTime() to get the seconds that passed :S... no need to send other packets.

Whatever you say :P

Quote:

Originally Posted by -impulse- It's not a bot check as far as the client is concerned... the client doesn't return a packet back... and the client wouldn't need to receive the timeGetTime() for the char creation. Beside this packet is always sent after 1004 answer_ok (2100 or 2101)...

Did you read my reply? It could take the values to be used for a bot check performed later.

Quote:

Originally Posted by Lateralus Did you read my reply? It could take the values to be used for a bot check performed later.

I must have missed that. I really gotta go to sleep :S.

Quote:

Originally Posted by -impulse- For a while TQ made the character creation so you wont have to login again to be able to play directly after you create the character. That works fine for me until I find myself in-game without half of my GUI. Keep in mind that it works fine if I login without creating a character. Has anyone found the actual login sequence for character creation on latest patch? Has anyone any idea what 1044 and 1033 are used for? What about 2079/2078? (You can login without them...) [Only registered and activated users can see links. Click Here To Register...]

thats happen when you have something wrong with your GameServerEncryption , check your Encryption when you ReInit your IVs and the Key, it happened with me , when I was not Encrypting the whole bytes after making handshake, also I was setting wrong IVs :p, so basically make sure that your Encrypting everything before sending it , and check your IVs , it has nothing to do with the packet order.

Quote:

Originally Posted by Mr_PoP thats happen when you have something wrong with your GameServerEncryption , check your Encryption when you ReInit your IVs and the Key, it happened with me , when I was not Encrypting the whole bytes after making handshake, also I was setting wrong IVs :p, so basically make sure that your Encrypting everything before sending it , and check your IVs , it has nothing to do with the packet order.

You do understand that if your IVs or your GameServerEncryption is screwed up the client disconnects at first invalid packet right?

Quote:

Originally Posted by -impulse- You do understand that if your IVs or your GameServerEncryption is screwed up the client disconnects at first invalid packet right?

not quite right if you made a hand shack and you Init it with mixed IVs u will still can login , try this you should have a method that ReInit(IV1,IV2,Key); yeah?

try to change the IVs so : ReInit(IV2,IV1,Key); test it should work tho!

Fixed. Done some debugging along Mr_POP and found the issue.

Never send NEW_ROLE and ANSWER_OK at the same time :P.
(forgot to use some return;)