1. Pack metadata
Pack ID and display label are auto-filled from the dropped
archive's filename — tweak if needed. Area is
auto-detected per texture from the bundled .psc
(or filename keywords when none); a multi-area pack splits
into one catalog JSON per area in the output ZIP.
2. Drop your mod archive
Expected layout: textures/…/*.dds at the root
(the same shape as any Nexus download).
Data/textures/… also works, and textures
sealed inside a bundled .bsa are read automatically.
Output is always .zip.
3. Conversion report
The output ZIP carries just the catalog JSON at the right
path. Drop it into MO2 / Vortex's "Install from archive" —
end users must also install the original texture mod separately
(MTF reads textures by their Data/textures/…
path, so both mods need to be active).
How it works & gotchas
What gets written. The output ZIP contains a
single JSON file at
SKSE/Plugins/StorageUtilData/MagicTattoosFramework/visuals/<packid>.json.
For every .dds the tool finds under textures/,
it adds one entry with id = label = the filename
stem (no extension), a single layer pointing at the texture,
and the area you picked.
Why no textures in the output? Content packs are
pointer-only by convention — the catalog references textures
at their Data/textures/… paths, and the end user
is expected to have the source texture mod already installed. This
matches every shipping pack in the framework's
content-packs/
directory, and sidesteps redistribution / permission concerns.
No previews. Browsers can't render .dds natively;
the tool doesn't try. If you want to verify visuals you'll need
your usual texture viewer (or just test in-game).
Multi-layer packs. If your pack has a base + glow pair
(e.g. actors/.../foo/001.dds + actors/.../foo-glow/001.dds)
you'll get two separate entries. Open the generated JSON in a
text editor and merge the layers manually — the format is
one "layers": […] array per entry, just add the second
texture object next to the first. Schema reference.
Renaming entries. Filenames make for ugly MCM
dropdowns. Open the JSON and edit the label fields to
whatever reads well ("Mark 001" beats "001"). id values
must stay unique within the pack but are otherwise free-form.
.psc as the source of truth. If a Papyrus script
is bundled with the archive, the tool uses it to (1) supply
human-readable entry labels and (2) DECIDE WHICH textures to
catalog — any .dds not registered in the .psc
is skipped. Authors often leave unused / draft textures alongside
the script; respecting the .psc avoids surfacing those. If you
want every .dds regardless, pre-extract the archive
and remove the .psc before re-zipping.
BSA-packed mods. A lot of overlay mods ship their
textures inside a Bethesda Archive (.bsa) instead of as
loose files (Community Overlays 1–3, for example). The tool reads
the .bsa's internal name table directly — only the
few-KB index at the front of the file, never the texture data —
so dropping the original Nexus archive just works. Entry labels fall
back to filename stems for these (the registration script is usually a
compiled .pex, not a readable .psc), so you
may want to prettify label fields afterward.
Privacy. Everything happens in your browser. Your archive never touches a server. View page source or open dev tools to verify.