Glam Dresser is inadequate, even doubling it does not solve the problem.

Quote:

Originally Posted by VictorTheed

All my stuff is full and I've had to resort to deleting stuff, I'd delete some of my mog station items but I paid real money for em, so I just deleted stuff I can buy from vendors, etc, really wished they'd fix this.

Yeah, this is a huge problem; I have a lot of "well, I bought this outfit from the Mog Station because I wanted just the boots/gloves/whatever" but where I'm not going to throw it out because I'd have to buy the outfit again if I ever found a glam where I did want those pieces. Now, when they double the storage, I should be able to clear all of that out... but that's still just kicking the can down the road a bit, as more glamour comes out and we just refill the dresser.

That said, I've noted before, my guess at the reason they don't do glamour unlocks -- and that the armoire is so limited -- is that I strongly suspect the backend for this game does not support sparse bitfields, which can be fairly crucial for many reasonable glamour unlock system designs. (Using more traditional lookup tables -- like I imagine they do for achievements and other things -- is fine up to a certain point, but the number of individual pieces of gear in this game is astronomically large; after a certain point, sparse bitfields become necessary just to store the results of your glamour unlocks in memory in a reasonable fashion.)

To explain slightly, let's say there is some thing -- we'll go with 'aardvark minions', mostly because the word "aardvark" is fun -- which players can collect, and which there are exactly 8 of. Since you only need to store whether or not they've collected a given thing, that's eight yes or no answers. Given how binary works, this means you can store it in one byte, with each bit of that byte being like a checkbox in a list of eight things. So, no minions would be 00000000 in binary, or 0 in decimal. All the minions would be 11111111 in binary, or 255 in decimal. And if someone had, say, three minions, and it worked out to be 10010001 (to mark the three they have), that could be stored as 145 in decimal.

Bitfields like that are great... except that when you get over 64 bits (64 yes/no checks) you start running into issues, since you need to start finding new ways to store things other than numbers (as the vast majority of computers don't really know how to deal with numbers larger than 64 bits in a reasonable manner). And there are ways around that, but if you have thousands and thousands and thousands of pieces of glamour, a bitfield quickly becomes utterly unmanageable. Needless to say, even handling it that way, loading a search result for every piece of gear in the game and whether or not you've ever had it pass through your inventory would be, uh, let's go with "computationally prohibitive". (This game has a lot of glam.) And yes, you could break it into multiple pieces -- store all the head bits separately, all the chest bits separately, and so on -- but at best that really just delays the problem rather than solving it.

This is where something called "sparse bitfields" comes into play. This entails Math, so I'll just wildly oversimplify it by saying that sparse bitfields allow you to do things like say, "there are 3 1's, then 24 0's, then 2 1s, then 19 0s, then 14 1s", etc. This makes it much smaller and more easily managed, but if done right, it's still incredibly efficient to be able to query "is this bit a 0/no or 1/yes". Thus you can easily pack a list of all the glamour in the game (or all the glamour in a specific gear slot) into one value. And even if you had every single item on a huge list, it would still be a very small result in memory; "there are 300,000 1s" is a lot smaller than 1 bit repeated 300,000 times.

However, I don't think this game supports sparse bitfields in its backend, and the reason I think that is actually the armoire. The armoire quite clearly does function as a bitfield (or set of bitfields) of some sort, as the gear in there does not contain dye or HQ/NQ data, and you cannot have more than one instance of an item in there; it is storing simply "yes/no" values. But they seem incredibly reluctant to add things to the armoire sometimes, and I suspect that's because they are constrained by those "if a bitfield gets too large to work with" situations and not wanting to push past whatever size the numbers being used to store the armoire (or, more likely, to store each category in the armoire) are.

(I mean, there's also the fact that they clearly have to have a lookup table of some sort, since you can't just use the glamour item's gear ID as the bit position, so you also need a "this bit maps to this item" lookup table.)

Worse still, I suspect that large chunks of the back-end aren't actually written by Square-Enix. I mean, that's the case with most MMOs; why would you spend all the time and energy writing some sort of replicated redundant relational database system in-house when you could just buy a more mature one like SQLServer, Oracle Database, or buy a support contract for one of the open-source options like Maria or Postgres? And the same is true of other chunks of an MMO system where writing a purpose-built solution is far less cost-effective than taking some off-the-shelf thing. But that sometimes means you get trapped by constraints from those systems, especially if for some reason you're tied to an older version of one. If they changed something in a later version that's not backwards compatible, for instance, and so you cannot really upgrade without having to rewrite big chunks of your own system.

So while the lack of any reasonable way to handle enormous result sets on the level of "every piece of glamour gear in the game" in memory on the backend may be SQEX's fault due to being short-sighted, it might also be the fault of some vendor whose software they're beholden to; I'm not 100% willing to point the finger at them there, since I've been the one trapped by a vendor limitation before.

None of which changes the fact that this glamour system is a disaster, and we could really stand to have something better. And I do feel like there have to be some options to make the system less broken that are viable within whatever constraints they have to work with on the backend... even if it's not a blanket unlock.