Where packs go

Two folders under resources/ hold pack content. Both are loaded at game start; you can use either, or mix them.

Folder	Purpose	Format
resources/packages/	Structured packs (recommended)	One subfolder per pack, each with a package.xml
resources/characters/	Loose girl files (legacy, still supported)	.girlsx / .rgirlsx files plus per-girl image folders, all at the top level

Folder casing: engine versions from 1.17.1 use all-lowercase game folders (resources/packages/). Older versions spelled them Resources/Packages/. On Windows and macOS either spelling works; on Linux the case must match your engine version, so if your game folder still has a capitalized Resources/, that’s where packs go. The folders inside your pack (Characters/, image-type folders) are unchanged.

New format (recommended)

Drop your pack as a subfolder of resources/packages/:

resources/packages/MyPack/
    package.xml             required: pack identity + dependencies
    Girls.girlsx            optional: unique girls
    RandomGirls.rgirlsx     optional: random-girl templates
    Traits.traitsx          optional: custom traits
    Items.itemsx            optional: custom items
    Characters/
        Jane/               girl-name folder, per-girl content inside
            images.xml      optional: per-girl tag overrides
            triggers.xml    optional: per-girl event/trigger hooks
            MeetGirl.lua    optional: meet-girl script for this girl
            Profile/        image category folders
            Sex/
            ...
    Lua/                    optional: pack-wide scripts
        my_script.lua
    Jobs/                   optional: data-driven jobs
        myjob/
            job.xml
            ...

The package.xml is what marks this as a pack. Without it, the folder is ignored. See the seven Sample_* folders that ship under resources/packages/ for working examples of every pattern.

A few rules about where files have to live:

• Girls.girlsx and RandomGirls.rgirlsx must sit at the pack root. The loader doesn’t recurse looking for them, so per-girl .girlsx files in subfolders are silently ignored. One file per pack, every unique girl as a <Girl> block inside.
• Per-girl content (images.xml, triggers.xml, MeetGirl.lua, image folders) lives inside Characters/<GirlName>/, and the folder name has to match the girl’s Name attribute exactly.
• Traits.traitsx, Items.itemsx, and pack-wide Lua/ scripts also live at the pack root. Jobs/ is the one folder that does recurse: each subfolder under it is one data-driven job.

Use the new format if you want any of:

• Traits, items, jobs, Lua, or building definitions in the same drop
• Dependencies on another pack, or addons that extend one
• Pack-validator coverage
• Per-pack enable / disable through future tooling

Legacy format

Drop loose files directly into resources/characters/:

resources/characters/
    Jane.girlsx                       unique girl XML
    Generic.rgirlsx                   random-girl templates
    Jane/                             girl-name folder, same layout as new format
        Profile/
        Sex/
        ...

The engine collects everything at this top level and treats it as a single virtual pack named _Legacy. No package.xml is needed. Image folders use the same layout as the new format; nothing about per-girl content changes.

Use the legacy format when:

• You’re loading existing legacy WM content that already matches this layout
• You inherited a resources/characters/ tree and don’t want to repackage it

For anything new, use the format above. The package wrapper is one file.

Default-image overlay packs (1.15.5+)

A pack can ship art for the engine’s default image pool, the fallback set the game uses when a girl’s own folder has nothing for the requested image type. This is the right shape for distributing a bulk art pack that fleshes out the new job-shift buckets (wait, cook, massage, dom, escort, etc.) without touching any individual girl’s Characters/<Name>/ folder.

Drop the images into Characters/Default/ at the pack root:

resources/packages/MyDefaultsPack/
    package.xml
    Characters/
        Default/
            Profile/        default profile portraits
            Wait/           default waitress images
            Cook/           default cook images
            Massage/        default masseuse images
            Dom/            default dominatrix images
            ...
            images.xml      optional: per-file tag overrides

The loader walks every installed pack at <pack>/Characters/Default/ and appends each overlay’s images into the engine’s shared default-image list. Per-pack sidecar tags (images.xml) are honoured the same way they are for per-girl folders.

Multiple packs can overlay defaults at the same time; everyone’s images go into the same shared pool. The fallback graph in resources/data/ImageTypes.xml still applies, so if your pack has escort art but the game asks for formal, the standard formal -> dinner fallback chain picks up your escort images automatically.

Legacy filename aliases

For art sourced from older WMR or WM7 trees, the loader recognises a few historical filename prefixes and maps them to the modern bucket names automatically:

Filename prefix	Modern bucket
Dominatrix (N).jpg	dom
Advertisement (N).jpg	advertise
Mast (N).jpg	masturbate

You can drop the original files in without renaming: they’ll be tagged for the right bucket at load.

Subfolder vs. filename prefix

Either layout works for any tag in the image catalog. Characters/Default/Wait/portrait01.jpg and Characters/Default/wait_portrait01.jpg resolve to the same bucket. Pick whichever is easier for your art workflow. The multi-token filename inference rules from reference/image-types.md apply unchanged, so preg_wait_03.jpg correctly tags both wait and pregnant.

Loader resolution

At startup the engine reads config.xml for two keys:

<resources>
    <packs>resources/packages</packs>
    <legacy>resources/characters</legacy>
</resources>

Both default to the values shown. The structured-packs loader walks (in this order):

1. Whatever packs is set to in your config.xml
2. The canonical default resources/packages (so a stale config still picks up the new location)
3. The historical resources/characters/Packages fallback

The legacy loader walks resources/characters/ once, picking up every loose .girlsx / .rgirlsx and matching girl-name folder.

Pointing the engine somewhere else

If you keep your packs outside the install (a shared library across versions, a Dropbox folder, a dev tree), set packs in config.xml to that absolute path:

<packs>D:/WM-Packs</packs>

The Content Manager (the Rust authoring tool) reads the same key, so both tools agree on where your packs live.

Which one should I use?

Use the new format. Always, for anything you’re authoring today, even a one-girl drop. The cost is one extra file (package.xml), and in return you get the validator, the Content Manager, the dependency system, future per-pack enable / disable, and any feature that lands later. Picking legacy for a new pack means opting out of all of that to save thirty seconds.

The legacy format is for existing content. If you have a pile of loose .girlsx files from older WM or WMR versions and you just want them to load, drop them into resources/characters/ and they will. Don’t start a new pack there.

Legacy content is not deprecated and won’t be removed. It just isn’t the path to pick when you have a choice.