Below are considerations for processing existing CatSystem2 files for faster speed and saving space, due to their excessively large image asset archives. Most of this is aimed at simplifying and lightening the load for game development and reverse engineering. This could also have practical use in distributions of game patches, where instead of diffing everything, only the modified archive files would need to be changed.

First off, decrypting KIF archives then saving them is a simple solution to save time spent on filedata Blowfish deciphering and filename Beaufort deciphering.

When a game utilizes multiple archives for a single type, such as image00.int and image01.int (but not pcm_a.int and pcm_b.int). These two image archives may be may be referenced from a plain text .lst file.

The directories prefixing each .int archive listed below likely specify the path to load loose files (outside of archives) when debugging. It is unknown whether these are required. Because of how these paths are used, it's likely impossible to change the directory where archives are loaded from. However, the ability to change the name allows us to make use of symbolic or hard links (both of which CatSystem2 supports without issue).

image.lst:

image\bgimage/image_bg.int
image\evimage/image_ev.int
image\fgimage/image_fg.int
image\system/image_sys.int

To support archive lists, they must be registered in config/startup.config. Below is how image.lst (shown above) is registered for NEKOPARA Vol.3:

config/startup.xml:

  <INT>
    <!-- ... -->
    <int00>
      <name>image</name>
      <int>image.lst</int>
      <ext>hg3</ext>
      <dir>image</dir>
    </int00> 

All that needs to be changed here is <int>image.int</int> to <int>image.lst</int>.

Relocating entire archives is feasible for certain types, as long as they are decrypted. Archive types like kcs.int, mot.int, and occasionally ptcl.int often contain identical files, since most or all of them are provided by CatSystem2. kcs.int, for example, contains only CatSystem2 binaries used to run everything, even starting the game.

Because of this, plenty of archives could be decrypted, moved to a different location, then symbolically linked.

Many CatSystem2 games (like Grisaia) have large numbers of duplicate image assets, primarily due to the way sprite assets are combined. Because of this, many entries in an archive will contain identical file data, but each point to a different point in the archive.

• Decrypt and save the archive.
• Split archives into assets unique to each game and assets reused between multiple games.
• Remap identical file data to a single location in the archive.

Remapping smaller files into sections of bigger files is theoretically possible, as there is no other required data surrounding the blobs of file data in KIF archives that could interfere.

For example, with file A aabbbbaaaaa and file B bbbb, file B could be remapped into A as: aa[BBBB]aaaaa. Another scenario, now file C ddccccc and file D eedd, file D could be remapped into C as: ee[DD]ccccc.

However, the stored file formats themselves will make this task essentially impossible because of general differences in structure and the required signature at the beginning of many files. In reality the two formats that have any chance of sharing mapped space are ZT Packages (which have no signature), and raw text files (which have no required terminator). But saved space granted from sharing space with these files will be negligible.

The cs2.exe executable comes with every game, it may not have the same name, or even the same extension, but it must be present in order to run the game. In almost every scenario this, executable will have the same version information such as executable name of cs2.exe, company of ARES inc. (c), etc.

One common difference in executables is the CatSystem2 engine version (as seen in the file version info). Newer versions will usually have (at most) a higher build number: Major.Minor.Revision.Build. For example, NEKOPARA Vol.3 has a Version of 2.6.1.76, which is two builds higher than the engine provided in the CatSystem2 toolset v4.01! This difference is enough for the added support of .cstl scenes, and leaps and bounds of improvements to localization support.

For the most part, you can run any game with slightly different engine versions, as long as they don’t depend on any newer features (when going down in builds), or use outdated formats (when going up in builds). For example, it's possible the added localization support in 2.6.1.76 may be problematic, as many files are now read in UTF-8 encoding. It’s unclear if the game can determine the difference.

Encountered with Steam's distribution of The Fruit of Grisaia, and NEKOPARA Vol.3, both executables have significant differences from those obtained elsewhere like Denpasoft.

For The Fruit of Grisaia, the executable had all of its resources changed to the language ID 1033 en-US (different from translating), there's even a comment in the file version created by the tool used to modify it. This is non-standard, and not done in any future games, but it’s good to watch out for, especially when looking for specific resources with a language ID.

For NEKOPARA Vol.3, it seems the entire assembly was encrypted or obfuscated in such a way to decompiling software would fail to find more than 4 functions due to excessive use of function pointers. (It's possible this was just corrupted, but very little has been looked to into on this, it's only known that other distributions of NEKOPARA Vol.3 can be inspected normally.