Changes between Initial Version and Version 3 of Ticket #1110


Ignore:
Timestamp:
Jun 23, 2014, 11:45:08 AM (10 years ago)
Author:
fabio
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #1110

    • Property Milestone Alpha 9 → Backlog

  • Ticket #1110 – Description

    initial v3  
    11Currently 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:
    2  * The `*.DELETED` meta-files are not archived, so `update.zip` won't have the desired file-removal behaviour.
     2 * ~~The `*.DELETED` meta-files are not archived, so `update.zip` won't have the desired file-removal behaviour.~~
    33 * 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.
    44 * 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.