A thought:
If Manual Sorting puts a load on the system, with lots of positional data up loaded, and leads to lag, then perhaps an intermediate suggestion.
Give each Chest it's own query or sort.
Allow only one Chest to be manually sorted/arranged.
Save the manual arrangement as a player parameter that is loaded/saved on a deferred transaction.
This would mean that only people with a manually arranged Chest will see a delay in the system; much of which will be absorbed during the first several minutes of play. So, if you don't go to the Vault keeper first thing, you may not notice the deferred load, but if you do, then you may have to wait 8-10-12 seconds to get you custom arrangement to trickle through...
Not perfect, but it may be more in line with performance goals of the management. I don't know. All we can do is suggest and try to work with them...as long and painful as that may be for us...at least it has a chance of change.
I've thought about it and I can't see the manual sort being the reason behind the lag. It can be done using a sorted array of bits, and done in under a data call (being 64 bits on a 32 bit system). Using 11 chests (1 main plus 10 extra) you will only use 4 bits to determine which chest an item is in. Supposing you are only using 1 chest and using all 150 possible spots, that uses only another 8 bits. That is 12 bits our of 64 for positional data, leaving 52 bits left for items and stack size. Making a stack size maximum of 100 takes 8 bits, leaving 44 for items. At 44 bits, that's a total of 8*10^12 items (8 trillion). So in effect, you can have a stack size of 100, with positional data for 8 trillion items using a single data call. And considering a data call takes 1 clock cycle, that probably isn't the cause of the lag.
Turbine probably didnt code it like that, for whatever reason, but as you can see, it doesn't theoretically take a ton of overhead for this kind of simple data storage.
Originally Posted by zPolarBear
Member
