This forced me to think about treating block 0 specially. The
problem was with block.index() returning [1-15], while the valid
range for MemoryCard::operator[] is [0-14]. This discrepancy was
very confusing. A simple solution would've been to just rename
Block::index() to eg Block::id(), and then know that one has to
do -1 on the id to obtain the index. I tried but discarded this
option. I don't think it's intuitive either (what's id? is it
guaranteed to be index+1? is it a random number, rather? I
know I will forget in 6 months).
Treating block 0 normally would, on the other hand, break range
iteration, as the first iteration would always be on the TOC
block, and all for loops would become 1-based. Also implementing
size() correctly becomes tricky (size could never be 0?)
I don't like the current implementation either but I did
it anyways for now, so operator[] works as before, you can get
block 0 by calling toc_block(), and Block::index() returns some
silly value for block 0. This should work in the future too
when there will be the possibility to forge a new block from
scratch. You don't really want to forge a block 0 as that's
calculated from adding the normal savegame blocks, and for the
latter MemoryCard can just do the +1 internally when receiving
a new Block. Besides Block::link_order() seems to like indices
this way, with 0 being the first savegame and not the TOC. So
it seems to be special in the original PSX API, then let's
treat it specially.
King_DuckZ
5688775e6c