Miscellaneous: 1018 Information Thread

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

[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?)