Sorry for the double-post, but I decided to split it because they're directed towards different people and address different topics.
That's the thing, though. I'm pretty sure I did figure it out and I told you what was wrong with it.
That's because the AH listing is inherently different from the inventory listing, and I told you repeatedly why. The inventory is not a static list that can just be read and interpreted and it's not just numbers that are being displayed but entire objects. Each item in an AH list is just a number (displayed as the item name) along with three markers, stack size (probably implemented as two flags as well), whether or not it's usable/equippable and whether or not it is currently equipped. This can be done entirely in a 13-bit array assuming a max of 512 items per category (even 12-bit with some clever coding). This simply does not work with items in the inventory, because they do list almost everything related to that item. WS points, for example, or max charges, charges left and recharge time, number of items, flags for usable or equipped items, etc. Now add on top of that that it's not a fixed item list and the storage size for each item increases. The inventory can't impose a limit of 512 items like AH categories to reduce storing information, because every item in the game can be in your inventory. Last I checked a compilation it was around 14k items (probably higher by now), if I remember correctly, which alone would require at least 16-bit allocated memory for each item. You cannot possibly combine all of that information in under 32 bits (I didn't do the actual math because I don't know how SE implemented it, but this would be the bare minimum). Now you do the math, 512*13 = 6656, divide that by our 32 bits per item and you're at 208 items for our inventory. Half that, to get 104 max inventory (because two storage locations can be up at any time to swap items). That's 104 items, in the same space that the auction house uses to store several hundreds of items. And notice how close it is to the current 80 item limit, and I was assuming the worst for many of those options.
And please note that I'm not saying my math is correct, I don't know how exactly SE coded it. I'm just saying it's plausible. You keep using the AH list as an indication that more than 80 items can be displayed when that's simply not always the case, because the space requirements are fundamentally different between the two. That's all I'm trying to say here.
I already said it would work for certain items (items with no metadata attached), but they're still not comparable and it's still not unlimited. So other means of storage would still be required. So if they added another storage location they would achieve the exact same result, only it would work on all items, it would be a lot faster to swap and it would be easier to implement (this is an educated guess, based on the fact that they've already done it several times). The only drawback would be that it would increase loading times after zoning, by a maximum factor of 15%, quite probably a lot less if you consider that all the key items, friend list and blacklist entries probably take up most of the time. So the entire process would still be within only a few seconds.
You said it would make any past "mass storage system" obsolete. What exactly do you mean by "mass storage"? What is the majority of your items? Because for me, it's gear I use constantly for all of my jobs. You even said yourself it's not for quick job changes, only that it was an improvement from muling (which I completely agree with). But what remains after the gear that I constantly use are some items most of which can already be stored (like event items and old artifact armor) and some old quest rewards or NM drops that I don't wanna toss. They hardly make up any kind of "mass" though (I think I have less than 30 of those items). So in the end I'd still prefer other systems for faster gearing and would barely use this, unless I had items I could store away permanently. I realize this may be different for other people, but again, not trying to bash the idea, just saying it's not quite as rosy as you made it out to be before.
The best reason for this is the increased capacity, because you could strip all those items of their metadata and just store them with much less space, possibly with less than 14 bits per item. However, I don't think SE's servers are a bottleneck for storing item data, so I'm not sure how relevant that would be. They could probably just add another /satchel-like storage and get away just as good, maybe even better, depending on the person and their playstyle.


Reply With Quote

