Miscellaneous: 1018 Information Thread

[Rogean]

If you are receiving the 1018 error for extended periods of time, please read the following. The following information only applies to occurrences of this error going forward from Today's patch (July 14th).

Be sure that the error you are receiving is actually a 1018 error code. There are other errors that will prevent you from logging in, such as temporary IP block, which are NOT the same problem or applicable in this thread.

If you have been in a situation where you receive this error longer than one hour AFTER July 14th, please submit a thread in the petition forum with the following information:

Title of the thread MUST BE: [Rogean] 1018 Information

Account Name
Date and Time of when you first noticed error 1018. Be as specific as possible.
Last time you attempted to connect that you still got 1018.
Were you eventually able to connect? What Date/Time?

Chances are your thread will not be replied to or handled, but it will help us find the cause of this issue and fix it.

[gwideon]

[You must be logged in to view images. Log in or Register.] Thank you for looking into this. It is MUCH appreciated!

[Handull]

almost didn't notice this sticky, but omg thank you Rogean <3

edit: what I wrote originally might have only been true pre patch

[Korpskugga]

Thank you [You must be logged in to view images. Log in or Register.]

[enr4ged]

If it's fixed what was the issue?

Cause damn that was an annoying bug and the programmer inside of me wonders what it was.

[Rogean]

Originally Posted by enr4ged [You must be logged in to view images. Log in or Register.]

If it's fixed what was the issue?

Cause damn that was an annoying bug and the programmer inside of me wonders what it was.

In the check for Loginserver: User to World request, there was a variable that was storing the Account ID that was only a signed short, and we have well over 32k accounts.

[enr4ged]

Originally Posted by Rogean [You must be logged in to view images. Log in or Register.]

In the check for Loginserver: User to World request, there was a variable that was storing the Account ID that was only a signed short, and we have well over 32k accounts.

Ahh, I knew it was account related.
Was the ID of newer accounts being truncated when trying to login causing the duplicates?

[iRFNA]

Well, a signed short isn't going to truncate after 32k, it will overflow into the negatives and eventually wrap around at 65k.

[Handull]

Originally Posted by Rogean [You must be logged in to view images. Log in or Register.]

In the check for Loginserver: User to World request, there was a variable that was storing the Account ID that was only a signed short, and we have well over 32k accounts.

I totally called that! Glad it got fixed, even though it took being ignored for months on end.

I still got a 1018 once on my bard once since patch, but I just haven't had time to play him to test it further, hopefully this is fixed and buried.

Originally Posted by Handull [You must be logged in to view images. Log in or Register.]

If devs could just take a look at how the server handles account IDs they could probably narrow this down quickly. Here is my best guess as to why/how there is this truncation error: everyone and their mother has multiple EMU Accounts and LS Accounts. Going off the fact that EQ is notorious for being stingy with data usage for integers (max stats 255, max mob hp 32k, 8 toons per account, etc), I wouldn't be shocked if the integer for Account ID is small (under 20 bits?) and that between all the users playing on EQEmu, all available Account IDs have been used up. This forces new IDs to appear the same as previous ones. Due to the fact that so many account sit dormant due to being used for other servers, logged rarely as mules, inactive accounts, etc, this error is fairly rare.

How does it work? Lets say we have a 3 bit number, call it A. A can be 0,1,2,3,4,5,6,or7. In binary these are
000,001,010,011,100,101,110,and111.
So what comes after 7? The next number in binary is 1000, but since A only holds 3 bits of data, A is now equal to 000. (in 3-bit binary 7+1=0)
Now, maybe A is a 32 bit number, and can hold more accounts than we can imagine, but A has to be passed along from your client to the server and checked against already active accounts. If at any point the code is written to only deal with a limited number of bits, A will be cut off (not quite truncated) and appear equal to another account.

How to fix/test this? Trace the code that retrieves an Account ID from the moment the client hits Log In and Join Server to the moment it returns an output of error1018 to the client. My guess is somewhere along the way the Account ID is reduced to some small bit integer in an attempt to reduce ping. Would you expect people to make over a million accounts over all the emu servers when you first programmed this box? Sounds like a reasonable way for someone starting a server to try and reduce overhead and keep lag down on a small and free sandbox emulator. If this is the problem, it should be a simple fix.

Since this is more of an Emu problem, looks like we need Rogean to weigh in on this one.

Sorry, can't help but say I told you so.

(inb4 forum ban?)