Glamour and why it's poorly designed

[Maeka]

It would be slightly more memory, but not hugely so!

The current system, I would imagine, uses at the very minimum, 800 bytes of data:

400 slots, 2 bytes each (1 byte would only give you 255 possible things, which is nowhere near enough) allows for 65,535 different possible things that could be in each slot. This is assuming that each item number has a 2-byte ref# ranging from 0000 to FFFF. Now, it is possible (and quite likely) that they might use an EOF-type function (you don't actually store null values in the empty slots, you just read until you come to the end of the list), but yet when you're programming a list like this, if you tell the user that they CAN have 400 slots, then you need to allocate enough memory in case the user (or all the users in the case of an MMO) really does use all 400 slots.

So this means that you would need at least 800 bytes of data to store the contents of the glamour dresser in its current form, which is a pittance by today's computing standards.

My suggestion would take a bit more memory, but still not that much.

Looking up on xivdb, there are roughly 4,000 weapons and 14,000 armors with about 300 glamour items. However, a lot of these have duplicate models (such as the Aetherial _____) and we don't really need to duplicate the models to be honest.

If we went with my idea, you would need (currently) about 19,000 bits (or 2,400 bytes) which sounds like a lot (3 times as much as we currently use), but still a pittance by today's computing standards. This is with the duplicate models, mind you. I'm willing to bet we could shave off a good 2,000 or so of those entries if we got rid of the duplicate models.

Just as a reference, this post is ~2,300 bytes in pure-text form.

This is assuming you do not compress the data. Given that this is a system that is not accessed often, this data could be compressed on the server, sent to the client, and uncompressed at the client to populate the list (which places most of the burden on the user's machine rather than the server or the bandwidth). Since this is only going to be done while in town, and such decompression can be done in an instant by any computer strong enough to run XIV, I don't really think this would be a problem to be honest.

[Callinon]

It would be slightly more memory, but not hugely so!

The current system, I would imagine, uses at the very minimum, 800 bytes of data:

400 slots, 2 bytes each (1 byte would only give you 255 possible things, which is nowhere near enough) allows for 65,535 different possible things that could be in each slot. This is assuming that each item number has a 2-byte ref# ranging from 0000 to FFFF. Now, it is possible (and quite likely) that they might use an EOF-type function (you don't actually store null values in the empty slots, you just read until you come to the end of the list), but yet when you're programming a list like this, if you tell the user that they CAN have 400 slots, then you need to allocate enough memory in case the user (or all the users in the case of an MMO) really does use all 400 slots.

So this means that you would need at least 800 bytes of data to store the contents of the glamour dresser in its current form, which is a pittance by today's computing standards.

My suggestion would take a bit more memory, but still not that much.

Looking up on xivdb, there are roughly 4,000 weapons and 14,000 armors with about 300 glamour items. However, a lot of these have duplicate models (such as the Aetherial _____) and we don't really need to duplicate the models to be honest.

If we went with my idea, you would need (currently) about 19,000 bits (or 2,400 bytes) which sounds like a lot (3 times as much as we currently use), but still a pittance by today's computing standards. This is with the duplicate models, mind you. I'm willing to bet we could shave off a good 2,000 or so of those entries if we got rid of the duplicate models.

Just as a reference, this post is ~2,300 bytes in pure-text form.

This is assuming you do not compress the data. Given that this is a system that is not accessed often, this data could be compressed on the server, sent to the client, and uncompressed at the client to populate the list (which places most of the burden on the user's machine rather than the server or the bandwidth). Since this is only going to be done while in town, and such decompression can be done in an instant by any computer strong enough to run XIV, I don't really think this would be a problem to be honest.

You forgot the dyes in the current system but yeah that sounds right. Part of me kind of expects the item id#s to be full 4-byte integers just because that'd give the system a functionally infinite number of items to allocate and it wouldn't ever have to be a consideration. I will say that their item structure absolutely considers duplicate models as separate items. For the purposes of glamour, yeah they should pare that out and get rid of the dupes, but the current system doesn't work that way and SE is all about making excuses based on existing code.

I will point out that even though the individual memory cost for this is vanishingly small, we have to consider the impact of thousands of these co-existing all at the same time. Ultros, for instance, has about 95,000 active players according to the census data. So your estimate of 2300 bytes per loaded player means you're potentially talking about 218MB of data for this one system alone. That's a lot more impactful.