There was a problem with Spanish Emerald triggering a crash in mystery_gift_injector.cpp
The problem was that the section30 and script BPS patch FileContainers specify @chunkSize=4096 in their .containerdef files.
However, mystery_gift_injector.cpp didn't specify a chunkSize in the constructor of the FileContainerReader instances in reconstructPregeneratedPayloads()
This resulted in it falling back to DEFAULT_CHUNK_SIZE, which is 2048.
Fix: Specify chunkSize 4096 as a constructor argument!
The gba payload was broken for the BUILD_LANG variant of the gba payload. So if the PTGB rom was english, the english payload would be broken.
The reason for this was because the text_helper ended up trying to convert the same entries twice, because the <BUILD_LANG> RSEFRLG table
would be converted during generate_text_tables() first, and then it would be converted again during generate_rsefrlg_tables_for_all_langs()
But convert_item is a destructive operation, because it replaces the ['bytes'] dictionary field.
Fix: add a "converted" boolean to guard against converting more than once.
Do some more work for multilang gba payloads. Revise the patch structure and make it use the right RSEFRLG table.
But it's broken. For some reason the english text doesn't show up when running the payload. Don't ask me why yet.
first_time entries would be longer, therefore the reference pointers inside the payload would shift.
To avoid that, we now reserve space for the longest entry, knowing that the texts will get stripped after
the payloads have been generated.
Doing so ensures that the text offsets remain constant, no matter if we're dealing with the first_time or othertimes payload.
This also means we need to take that reservation into account on the PTGB rom side of things of course.
To do so, I created a pair array indicating the first time entries and there non-first_time counterparts.
We'll determine which entry is the longest and ensure we use that length for the offset of the next entry.
Recently the GB payload for gen2 changed the arrival address at which packets get stored.
It went from 0xC6DC to 0xC8DC. But for gen1 it remained the same.
This commit makes sure that change is reflected on the PTGB side.
This commit makes mystery_gift_injector re-insert the text entries into the gba payload at runtime.
You may or may not remember that I made gba-payload-generator strip the text entries again after generating the payloads.
I did this to improve compression: it removes the variability of the text lengths. It also ensures that texts are not really part of the BPS patch files
that are generated to transform the base payload into a specific language and game variant.
Therefore, we don't run at risk of storing certain text entries multiple times (or partially multiple times) due to them being stored at FileContainer boundaries.
It should make patch files smaller and more predictable.
Stripping the text entries also made it easy to reinsert: almost every rom uses the same offset for the first entry.
We now only need to store each language variant of the RSEFRLG (variants aren't being generated yet) once. That should be a big boon.
By first generating the payloads and THEN stripping the texts, we also ensure that the pointers/references within the payload remain intact and will become valid
again once the texts get reinserted.
Anyway, this specific commit does the re-insertion of those text entries into the payload (script + section30) using the RSEFRLG table.
Because the text stripping takes out these variable length texts, the text insertion offsets always end up the same, no matter the language:
Section30: 0x97E
Script:
- Ruby/Sapphire: 0x268
- Fire Red/Leaf Green: 0x278
- Emerald: 0x298
