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.~~ Use -mod=modfolder to specify base mods (also do that for public if you depend on it)

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