With allowance for the extra two jobs, we can say that, for example, slip 10 needs to be able to hold 5 * 22 = 110 items.

Slip 4 needs to be able to hold 6 * 22 items (5 armor, 1 weapon, assuming the new jobs get their standard AF set), so 132 items altogether (though only 120 right now). Similar for relic: 5 armor + 1 accessory per job.

Since that requires an on/off bit for each item stored, we know we need at least 4 32-bit fields to store all the present items, and potentially an additional field for handling the new jobs' armor.

If you tried to store all the armor from all 13 slips in one item, it would need 52 to 65 32-bit fields. Somewhat excessive. Granted, some of them won't need the full expanse of that, but you still need room to expand (eg: can the new NeoLimbus gear be stored in ticket 2? will we be adding all the new Salvage gear to ticket 1 (which has to store both all the sets and all the component pieces, plus Nyzul, etc)?).

Most games of this type might describe item objects with maybe 20 fields at best (probably less), some of which will be reserved for things like item name, icon, status, stack size and so forth.

We also know things like, each piece of armor is limited to storing 5 unique pieces of information (not counting augments). That implies it's probably limited to 5 32-bit fields for 'general data'.

Similarly, it doesn't matter if you have a single ticket that lets you access different storage 'compartments'; you still have flag all those stored items individually, which means you're back at 5 fields per ticket type, and needing 60+ such fields.


In principal it seems like a fairly easy fix: just make an item with tons of storage data on it. In practice, not so much. That item has to be understood by, and tracked/stored/retrieved by, the underlying engine that's been programmed with the data structure design of everything in the game. Introducing something entirely new means not only having to adjust every function that such an object could go through or be manipulated by, but also the memory pressures of storing such objects. The easiest adjustment being to just expand the size of the base object, if you had to triple the size of the data structure, you pretty much just tripled the memory requirements for a huge chunk of the game for a fairly minimal benefit (most objects won't be using all that new empty space), and figuring out how to convert all -existing- objects to the new one, should such a changeover occur.


A different trick would depend on whether the game has the concept of 'inside'. In some other games, if you have a bag to put stuff in, the bag itself is an object, and 'contains' the other items put inside it. You can do fancy trickery by putting one object inside another, but not allowing the player to actually see inside. So, you have a 'global' ticket that holds the 13 individual tickets inside it, and use the flags on the global ticket to indicate which individual tickets are available.

I suspect that's not possible, though, due to the way inventory is managed in the game. The data on each of the sub-tickets would still need to be managed, which means the game has to be aware of them when moving things around, which means it probably runs up against the whole 80*2 item memory limit from the PS2.


.. I think there was some point to this post, but... whatever, just solidifying the probable basis for Okipuit's post.