id,summary,reporter,owner,description,type,status,priority,milestone,component,resolution,keywords,cc,phab_field
1110,Archive builder support for non-base mods,Philip Taylor,,"Currently the archive builder assumes that you're archiving a single self-contained mod. If you're not (e.g. you're building an `update.zip` as a way of patching `public.zip`, or you're archiving a user-made mod that builds on top of `public`), that fails in various ways:
 * ~~The `*.DELETED` meta-files are not archived, so `update.zip` won't have the desired file-removal behaviour.~~
 * If the `public` mod has e.g. `foo.png` (stored as `foo.png.cached.dds` in `public.zip`), and the `update` mod has `foo.png.DELETED` (stored as `foo.png.DELETED` in `update.zip` if we fix the previous point), then loading both archives will result in the file `foo.png.cached.dds` still being visible. The archive builder needs to copy `foo.png.DELETED` to `foo.png.cached.dds.DELETED` to preserve the file-removal semantics.
 * If `public` has a `textures.xml` that controls the texture compression behaviour of textures in a subdirectory (compression algorithm, alpha channel usage, etc), that won't be taken into account when compressing the textures for `update.zip`. We need to use `CArchiveBuilder::AddBaseMod` (and add some command-line arguments for it) so that it loads `public` to provide the files like `textures.xml` that the `update` archive implicitly depends on.

Also, there should be automated tests for this, since the logic is getting quite complex.",task,new,Should Have,Backlog,Core engine,,,ricotz,