FFH standardized compressed table suggestion

[Xifanie]

http://xifanie.ffhacktics.com/routine.html

I propose this format (which I will make an excel sheet demonstration on how to compress the data too), and ultimately would lead to a table compressing utility for those without excel.
There are a few things I want to make different... This is not the final format. Those tables would be, of course, read-only. I'm just suggesting this as I thought it would be the best way to save space. And heck, we might even get to the point where we can compress vanilla routines.

The big idea is simply to have a standard format which you can just use by setting your parameters:
r1 = Table Address
r2 = Row
r3 = Parameter (column)
r4 = Returns Result
and then call the subroutine with a jal.

[Pride]

I'm all for saving space, even if I understand nothing of how this works... I have a few hacks that have a table, secondadvent as well, and ALMA.

[formerdeathcorps]

Sadly, here's the problem.  Some tables are far simpler than others.  Xif's standardization saves space only on multiple-linked tables like ARH or ALMA or Square's original tables.  For a simpler table like yours or SA's, I'd simply do:

PROC CHANCE
Item ID
Item ID
Item ID
...
Separator Byte
PROC CHANCE 2
...

The user would then input the table's starting offset, table size, and default value.  You can include moves as well as items if your ID was considered a halfword.  Anything that's not on the table defaults to the fixed default value.  The key to saving space, however, is making your table smaller than the size of all the items under consideration (0x100 if we just talk about items) because we can reasonably assume most people will use default values for a large section of their items (and thus, we needn't repeat the same values across the table).

For ARH, Xif has the way she showed above but considering how the attribute space is already mostly in bits, the only way she could save more on that part is to use dynamic RAM allocation.  Thus, I'd rather improve Xif's table by fixing the item table in the way I detailed above except PROC CHANCE would be replaced with ATTRIBUTE #.

For ALMA, the linkages there are immense.  I'm not entirely sure how to fix it myself, though I just sent Pokeytax a PM detailing my ideas.  He can quote it here if he wishes.

For rewriting Square's tables, Xif's approach works best.  Many of them are large, complex tables that link values in 8-14 byte segments, but contain many repeats between moves/jobs/...  Xif's approach lets us save space by reducing the number of bits used while simultaneously creating a dynamic table.  It is also possible to fuse her method with mine, i.e. reserve enough space on the table for only a portion of the jobs/items/... as non-default values since defaults will still exist in any patch.  However, it should be noted that since most hackers tend to make more features than Square did, the compression ratio shouldn't be too serious or we start restricting choice.