9999 ***

[DataBeaver]

Regardless of whatever is limiting the quantity, it takes up the same size in the database, whether it's 256 or 65535.

If fact you could probably squeeze a max size of 256 into a single storage byte with a little trick. A stack can never have zero size, or the entry would not be present at all. Thus, you can subtract one from the stack size when storing it. Think of it as the count of additional items beyond the first one. A stack of 256 becomes 1+255 and only the 255 needs to be stored in the database.

 

Granted, this is overly complicated and prone to bugs while offering no practical benefit, but it's possible regardless

[Draqsko]

If fact you could probably squeeze a max size of 256 into a single storage byte with a little trick. A stack can never have zero size, or the entry would not be present at all. Thus, you can subtract one from the stack size when storing it. Think of it as the count of additional items beyond the first one. A stack of 256 becomes 1+255 and only the 255 needs to be stored in the database.

 

Granted, this is overly complicated and prone to bugs while offering no practical benefit, but it's possible regardless

 

Actually you open yourself up to overflow errors when you do that. That's not something you really want to do considering in this case it would be resetting the item stack quantity to 0 once it overflowed. The rage that follows would be an instant internet classic.

[demotivator]

Of all the changes that have been made in the last 6+ months, THIS is the best one and 100% positive.

 

All of my crafting mats now go into my Legacy storage, and all my characters can share from the giant pool. Alts leveling up can replenish the general stock as they go. No more taking up 1 or 2 tabs on every character and most of my Legacy storage on mats, and no more toting around stacks in my inventory waiting for a good price point to pop up on GTN.

 

As much as I've hated some of the changes (levelstink, gearless companions, cookie-cutter companion abilities, etc, and so forth), I absolutely 100% support this huge QoL improvement.

 

This! 5 bays of Legacy Storage can finally store all the mats you need with so much room for all the things that can be shared across your account, event tokens, companion gifts, etc. Before that patch 2 of my crafters had to use their personal cargo bay to keep their mats.

 

So it freed up a lot of space both in Legacy Storage and cargo bays, how can anyone whine about it?

[TX_Angel]

I realize that, I was replying to the person I quoted that the database limit would be a power of 2 not a multiple of 10, and the structure is probably similar to SQL given that C++ and C# also follow the same limits when declaring variables.

 

Regardless of whatever is limiting the quantity, it takes up the same size in the database, whether it's 256 or 65535.

 

^ This... But it is worth noting that in 2016, storing a 16-bit number in a database is not a big thing. Storing a billion of them is not a big thing. Storing a thousand trillion of them is STILL not a big thing...

 

Moving from a 1 byte (8-bit) number at 99 to a 2 byte (16-bit) number at 9,999 is not going to break any computer worth using in 2016.

[TX_Angel]

This! 5 bays of Legacy Storage can finally store all the mats you need with so much room for all the things that can be shared across your account, event tokens, companion gifts, etc. Before that patch 2 of my crafters had to use their personal cargo bay to keep their mats.

 

So it freed up a lot of space both in Legacy Storage and cargo bays, how can anyone whine about it?

 

I'd still like another 5 legacy storage bays, or at least 2 more, which would fit on the physical screen without scrolling, as it is designed today.

 

Yes, this change is wonderful and makes a ton of difference. My Artifice went from 5 completely full personal storage bays (with overflow to other toons) to having all mats on one page. But I still can't store all my mats in legacy, there are just too many types when you include lower than grade 8/9 in the list. But I now can keep all grade 8/9 for all types in legacy with only below that in personal storage.

 

2 more legacy bays would allow me to move all of it to legacy.

[Draqsko]

Moving from a 1 byte (8-bit) number at 99 to a 2 byte (16-bit) number at 9,999 is not going to break any computer worth using in 2016.

 

Well it's not the end user's computer that is the issue here, it's the server where all that information is stored. Sure there's not much difference between an 8 bit number and a 16 bit number as far as storage size on an individual basis, but as I pointed out in another thread there are over 18 million unique accounts for SWTOR, times however many characters on each account, times however many items they have. That adds up pretty quickly.

 

Your personal database of items only contains the id number, quantity and location, after that stuff like graphics and tooltips are read off a separate database section and that all has to be done before it can be displayed on your screen. This is one of the reasons why you experience lag when you open your inventory or cargo bay, and why that lag has increased since launch. Some of it might be the UI but most of it is just the increased amount of entries in the item database that slows down the processing. Website forums run into the same issue if they aren't properly pruned as the number of forum posts continues to increase.

[TX_Angel]

Well it's not the end user's computer that is the issue here, it's the server where all that information is stored. Sure there's not much difference between an 8 bit number and a 16 bit number as far as storage size on an individual basis, but as I pointed out in another thread there are over 18 million unique accounts for SWTOR, times however many characters on each account, times however many items they have. That adds up pretty quickly.

 

And as I posted, that still doesn't matter...

 

Even if all 18 million accounts each store 50,000 items between all toons in all storage bays, moving all of them from a 1 byte number to a 2 byte number still doesn't matter.

 

That is only 900GB of additional storage, across all servers, all accounts.

 

Now in reality, due to imperfect systems, it would likely be higher than that. But you're still talking about a single 2TB hard drive, give or take.

 

---

 

TL;DR - the storage space demands of this change are trivial compared to the storage needs of the game as a whole.

[DataBeaver]

Actually you open yourself up to overflow errors when you do that. That's not something you really want to do considering in this case it would be resetting the item stack quantity to 0 once it overflowed. The rage that follows would be an instant internet classic.

That's hardly unique to the scheme I described. In fact an overflow can happen whenever the limit is more than half the maximum integer value. Suppose the limit was 130 and you tried to combine two full stacks - badly written code might try to calculate 130 + 130 = 260, but with 8-bit variables this would overflow and wrap back to 4, which is smaller than the stack limit.

 

The obvious solution is to use larger temporary variables when performing arithmetic. In fact the registers in modern CPUs are 32 or 64 bits wide, so there's no benefit at all for using 8- or 16-bit temporary variables.

 

If small temporary variables are for some reason necessary, the logic needs to be changed to avoid overflow (or utilize the fact that an overflow in unsigned addition produces a result that is smaller than either of the operands). As I said, using such tricks is prone to programming errors.