As long as we’re on the Adrift/Blorb topic, there’s a wrinkle here that will need to be addressed.
It appears that Adrift files are not valid Blorb files. The most authoritative Blorb code (from @Zarf) fails to load them properly. This is both in gi_blorb (for Glk) as well as blorbtool.py, which uses Python’s IFF parser.
In the gi_blorb code, the failure is the condition if (nextpos > totallength), which implies that a length somewhere is being written incorrectly, causing the file to overrun. Basically, there’s an IFF chunk which specifies a size that runs beyond the end of the file.
After a quick check, it seems that the size of the whole file (i.e. of the overall FORM chunk, specified by the 4-byte value at offset 4) is written incorrectly. The value here should be the size of the file minus 8, but Adrift Blorbs have a smaller value. As an example, Anno 1700 is 880810 bytes long, but the FORM size is 880004.
The header validates as Blorb, so in Gargoyle’s case, it tries to run it as a Blorb file; but that fails when it can’t parse it. Even if/when Gargoyle supports Adrift 5, its Blorb files won’t work, as they will be considered invalid.
The Blorb specification notes that Adrift files can have either “.blorb” or “.adriftblorb” extensions. “.blorb” can’t be unilaterally associated with Adrift as that would break other game types, but if necessary, Gargoyle could add a special case for the “.adriftblorb” extension, and avoid the Blorb code for them.
An alternative would be to add custom IFF reading code to Gargoyle which short circuits as it loads chunks, stopping if it finds an Exec chunk of type ADRI… but I’m not sure how much I want to do that. It might be the only way to support the invalid Adrift files without requiring a file renaming, though.