Image types

The engine recognises 88 image types defined in resources/data/ImageTypes.xml. Every type doubles as a subfolder name and filename prefix. The catalog is fixed per game version: a pack cannot add types, and a type added by editing your own install is tagging-only (see “Adding a new type” at the bottom).

How to read the catalog

Each entry in ImageTypes.xml looks like:

<Type Name="bdsm">
    <Display>BDSM</Display>
    <Description>Any sort of BDSM sex act.</Description>
    <Fallback TiedUp="yes" Cost="25">anal</Fallback>
    <Fallback Cost="25">spanking</Fallback>
</Type>

• Name – lowercase string used for folder matching and filenames.
• Display – pretty name shown in the Gallery.
• Description – tooltip text in the tagger.
• Fallback – legacy metadata from the previous resolver. The current game does not walk these entries, so editing one changes nothing you will see in play. Substitution comes from ImageFallback.xml and from your own pack’s image-fallback.xml (see below). The entries are still in the file because tooling reads the catalog; they are on their way out.

Fallbacks

When the game asks for an image of type X and the girl has none, the scoring picker looks for the closest acceptable substitute. What counts as acceptable is defined in resources/data/ImageFallback.xml, not by the Fallback/Cost entries in ImageTypes.xml (those are read for compatibility but no longer drive selection).

• Each allowed substitution (an affinity such as spanking accepting bdsm art) adds a penalty; the image with the lowest total penalty wins.
• Pregnancy, tied-up state, participants, and style each add further penalties when they disagree with the scene.
• Only same-family consensual substitutions exist by default (anal, bdsm, oral accept sex art; spanking accepts bdsm then sex).
• Scene-identity types never substitute: rape, rapebeast, beast, torture, masturbate, and strip show a dedicated image or the character’s profile, never a different act.

The last-resort fallback is always profile. If nothing else is acceptable, the engine shows a profile image rather than art that misrepresents the scene.

Lesbian and group scenes never cross their scene shape: a substitute must itself be tagged with matching participants, and when none is, the scene goes straight to the portrait. See “Scene identity: lesbian and group art” below.

Overriding the map for your own pack

Drop an image-fallback.xml at your pack root to change these rules for your images. It is an overlay on the engine map, not a replacement: declare only what you want different, and everything else stays as shipped. Your rules never apply to another pack’s images, and another pack’s rules never apply to yours.

<ImageFallback>
    <Affinity from="rapebeast"><To>beast</To></Affinity>
</ImageFallback>

Three rules worth remembering. Omitting <Weights> keeps the engine’s weights; declaring it replaces the whole block, so an attribute you leave out takes the schema default rather than the engine’s current value. <Affinity from="X"> replaces the entire target list for X. An empty <Affinity from="X"/> turns fallback off for X entirely.

If the file cannot be read, the engine rejects the whole overlay and keeps its own map, and the validator and installer both refuse the pack. Half a broken policy file must not quietly widen what your pack will substitute.

Which pool the substitute comes from

Substitution decides what may stand in. It never decides whose art may be used. The game searches the character’s own images first, then her pack’s Characters/Default, then any installed Type="Defaults" pack, checking for an exact match everywhere before it accepts a substitute anywhere, and the profile portrait last.

So a closer pool always wins: an eligible image in the character’s own pack beats a better-matching image in a global default pack. And the game never looks inside another named character’s folder. See where-packs-go for how a pack declares which characters its default images serve.

The 4 axes

Images have up to four axes of metadata beyond the base type:

Axis	Values	Where
types	One or more names from the catalog	Filename prefix or subfolder
pregnant	yes / no / (unspecified)	preg prefix or Preg* folder
tied	yes / no / (unspecified)	Manifest only (no filename convention)
participants	solo, lesbian, hetero, gangbang, lesgroup, orgy, etc.	Folder / prefix (Lesbian/, Les/, Group/ and their Preg* variants) or manifest

The base categories (prefix / folder names) set types and pregnant. The classic Lesbian/, Les/ and Group/ folders (and matching filename prefixes) set participants too. For anything finer – tied-up variants, the other participant shapes – use an images.xml manifest.

How the Gallery shows axes

The in-game Gallery is organised by the types axis only – one row per catalog type the girl has images for. pregnant, participants, and tied are filters applied across all rows, controlled by cyclers at the top of the gallery.

This matters for lesbian and group images. They are tagged as type sex with participants lesbian or gangbang, so they appear in the Sex row, not as their own rows. To narrow the Sex row to just lesbian or group art, cycle the Participants filter from Any to Lesbian / Lesbian Group / Gangbang / Orgy.

Packs made for older versions, where lesbian and group art had its own gallery rows, still work for scene picking; only the gallery presentation changed.

Scene identity: lesbian and group art

(Applies from 1.18.1.)

When the game plays a lesbian or group scene, the participants tag is a hard rule, not a preference:

• Only art explicitly tagged with a matching participants value can show. An untagged image from a plain Sex/ folder counts as “shape unspecified” and will never be used for a lesbian or group scene.
• If the exact act has no matching art, closely related acts (dildo, finger, lick, sixtynine, oral, anal) may stand in, but only when they are tagged with matching participants.
• If the character has no matching art at all, the scene shows her portrait. Older versions showed a generic (usually hetero) sex image here; that was reported as a bug and is fixed.
• Pregnant lesbian/group scenes fall back to the non-pregnant lesbian/group art first, never to generic sex.

What this means for your pack is simple: if you want lesbian or group scenes to have art, tag it. Drop the images into a Lesbian/ (or Les/) or Group/ folder, use the matching filename prefixes, or set participants in an images.xml manifest. Untagged art keeps working exactly as before for every ordinary scene; hetero and solo scenes are not affected by any of this.

Plain hetero art needs no tagging: “shape unspecified” is treated as acceptable there, because that is what nearly all existing art is.

Multi-token filename inference

Filenames are split on _, -, ., whitespace, and (1.15.7+) letter-to-digit boundaries, then each token is matched against the catalog. All matches apply. So preg_foot_cumshot.jpg infers foot and cumshot types and pregnant=yes without needing a manifest entry. Authors who want to override or extend this can still write entries in images.xml per the rules below.

This means well-named multi-tag files just work. You only need the manifest when the filename alone cannot express what you need (tied-up variants, participant shapes, or filenames you can’t rename).

Counter styles — all of these work

Packs in the wild number their images half a dozen ways. These all resolve to the same oral tag:

Filename	Why it works
Oral (1).jpg	the WM7 convention; the space isolates (1), which matches nothing and is ignored
Oral_1.jpg	underscore is a separator
oral-3.png	dash is a separator
Oral 1.jpg	whitespace is a separator
Oral.2.jpg	inner dots are separators (only the last dot is the extension)
Oral1.jpg	1.15.7+ – digits attached to a word split off automatically; on older builds this form is NOT recognised

Case never matters. Leftover tokens that aren’t catalog names ((1), final, v2) are harmless – they match nothing and change nothing.

Names that do nothing

A token only counts if it is one of the 88 catalog names. A file whose name contains no catalog token gets no type at all, and an untyped image can never be selected for any in-game scene – it is effectively invisible outside the manifest path.

The one to watch for: service. Some packs circulating on the forums ship Service (N).jpg images. That name is not an image type here, in crazys, or in original WM7 – those files are never shown by any of the three engines. If you have service-flavoured art, name it for what it depicts (maid, wait, massage, hand…) or attach types via images.xml.

Quick self-check for any name: search resources/data/ImageTypes.xml for it. Not there = not a type. Easier still: run the pack validator (1.15.7+) – it warns about every image the engine cannot type, with a rename suggestion for the known dead names.

The images.xml manifest

Drop an images.xml file inside a girl’s Characters/<Name>/ folder to attach explicit per-image metadata that filename or folder inference can’t express.

<Images>
    <Image File="Profile/portrait01.jpg" Type="profile" Pregnant="no" />
    <Image File="BDSM/tied01.jpg" Type="bdsm" TiedUp="yes" />
    <Image File="group01.jpg" Type="sex" Participants="gangbang" />
    <Image File="ai_portrait.png" Type="profile" Style="genai" />
</Images>

Besides Type, Participants, and the yes/maybe/no axes (Pregnant, Futa, TiedUp), an entry can declare the art’s Style: drawing, rendering (3D), photo, or genai (AI-generated, 1.17.2+). Unknown style values are ignored with a warning, so a manifest using genai still loads on older engines — the style just reads as unspecified there.

The manifest is additive, not an allowlist. The engine walks the disk regardless of whether images.xml is present. Files on disk that match a manifest entry get the manifest’s tags overlaid on top of folder/filename inference (manifest wins on conflict; types are unioned). Files on disk not listed in the manifest still load. They pick up tags from the standard folder/filename inference. Manifest entries that point at files not on disk are flagged as pack-level warnings.

This means you only need to list the handful of files whose tags can’t be expressed by their filename or parent folder. Everything else picks itself up.

Use the manifest when:

• You want tied-up variants (no filename convention for this).
• Your filenames don’t follow the prefix convention.
• You want multi-axis tags that can’t be expressed in a prefix.

For most packs, filename prefixes and subfolders are enough.

What the engine actually requests

The 88-entry catalog is the authoring surface: folder names, filename tokens, gallery rows. (Substitution is not part of it — that lives in ImageFallback.xml and in your own pack’s image-fallback.xml.) It is not the same as the request surface — the set of tag names that a shipped job, event, or screen actually asks for at runtime. If you only care about the gallery looking complete, the catalog is enough. If you care about which images display during gameplay, read on.

Two layers sit between a catalog tag and a real on-screen request:

1. <DefaultImage> in a job’s job.xml. Every data-driven job declares a default tag for its shift event. Only the values listed below appear in shipped jobs.
2. The engine bridge that maps the declared string to an internal image slot. Names the bridge does not know silently fall back to profile.

Tags routed all the way through (display correctly today)

These trigger a distinct image lookup during gameplay. If you author images for these tags, they will show up in shift events, dungeon panels, brothel summaries, etc.

• profile — the universal default; shift events, status views, fallbacks all end here
• sex — whore / barwhore default, plus generic sex shifts; participant filters narrow it to lesbian / group variants
• anal, oral, bdsm, beast — requested when whore-class jobs route to specific acts
• titty, hand, foot — per-act buckets for breast / hand / foot scenes (1.15.5+; reachable via per-<Text> Image= override). Concretely: a titty image is shown when a shift message that declares Image="titty" fires — in the shipped content that’s the Masseuse’s horny happy-ending variants (oral / titty / hand / foot each have one), plus the Whore/BarWhore horny oral/foot lines. Pack-authored message bags can request them the same way. With no titty image in her pack, the fallback map stands in (titty accepts sex art, then profile), so the line still gets art — just not the specific act.
• pregnant — auto-applied when the girl is pregnant, with per-act preg variants for the five above
• death — death events (brothel danger reports, dungeon)
• torture, jail — dungeon screen image panel
• combat — Arena fight jobs (Fight Beasts, Fight Girls, Combat Training)
• strip — Brothel Stripper
• Job-shift buckets (1.15.5+): wait, piano, ecchi, escort, massage, advertise, maid, cook, study, herd, bed, craft, rest, security, formal, dom, puppygirl, masturbate. Each non-whore data-driven job now declares one of these as its <DefaultImage> so the Waitress shows wait, the Cook shows cook, the Masseuse shows massage, and so on. Pack art for any of these tags lights up during the matching job’s shift events.
• Character interactions (1.19+): the Interact menu on Girl Details and in the Dungeon requests a scene tag for each act. sex (Make Love), oral, anal, bdsm, beast (Watch with a Beast), masturbate (Watch Her Masturbate), strip (Have Her Tease You), spanking (Spank), rape (Force Sex and the Dungeon force act), and torture (Dungeon torture). Watching her with another girl and the orgy option request sex art tagged participants=lesbian / group participants. Art you tag with these shows in the scene panel right after the interaction.

Lesbian and group are not separate request tags any more; they are sex tagged with participants=lesbian / participants=gangbang. Author them as such.

Dedicated-only tags: rape, rapebeast, beast, torture, masturbate, and strip never borrow art from another tag. If a scene requests one of these and your pack has no matching image, the game shows the character’s profile portrait instead of a look-alike from a different act. This is deliberate: a substitute would change what the scene shows. Consensual same-family requests still degrade gracefully (anal, bdsm, oral, and spanking can fall back to sex art).

Per-job image lookup

Useful for batch-generation workflows (ComfyUI, Stable Diffusion) that want a “given job, what filename prefix” lookup without grepping each job.xml. Every shipped data-driven job and its current <DefaultImage>:

Job	Prefix	Job	Prefix
advertising	advertise	hall	wait
arenacleaner	maid	headgirl	formal
barcook	cook	houserecruiter	formal
barmaid	wait	houserest	rest
barsinger	piano	houseso	study
barstripper	strip	jeweler	craft
barwhore	sex	masseuse	massage
basictraining	study	matron	formal
beastcapture	combat	mistress	dom
beastcare	herd	peepshow	strip
bedwarmer	bed	performer	glory
blacksmith	craft	pet	puppygirl
brothelstripper	strip	piano	piano
cityguard	security	security	security
clean	maid	sleazybarmaid	ecchi
cobbler	craft	sleazywaitress	ecchi
cook	cook	torturer	dom
doctore	combat	training	study
escort	escort	waitress	wait
explorecatacombs	combat	whore	sex
fakeorgasm	ecchi
fightbeasts	combat
fightgirls	combat
fighttrain	combat
freetime	rest

Several jobs share a prefix (every fight job uses combat, every craft job uses craft), so a single piece of art covers multiple jobs. The pet job currently shares puppygirl art; if you want pet-specific art, generate it tagged puppygirl and it will light up on pet shifts (and any other shift that requests puppygirl).

Per-outcome image override on shift messages (1.15.5+)

A single message bag can paint different portraits for different outcomes. The Masseuse bag’s happy-ending variant overrides her massage default with oral or sex; a Waitress refusal arm can paint refuse while the work line keeps wait. Add Image="..." directly on the <Text> element:

<Text id="masseuse.work.horny.oral.1" weight="1" Image="oral">
    ...
</Text>

Same vocabulary as <DefaultImage>. Unknown tags degrade to profile just like <DefaultImage> does. See jobs-reference – per-outcome image override – for the full schema.

Tags that exist only in the catalog

Everything else in ImageTypes.xml is still catalog-only. That means:

• They appear as gallery rows so authored images are browsable.
• They participate in the fallback map, so a richer pack with dance images can still satisfy a future dance request, and a spanking request can fall back to your bdsm art if you have it.
• They do not match any shipped <DefaultImage> today, so no shift event currently asks for them by name.

These are not dead — they are the future-facing surface. As more jobs become data-driven and the legacy bridge is extended, more of them will start being requested directly. If you are pacing your authoring effort, prioritise the “routed” tags above; treat the catalog-only tags as embellishment until a release notes them as wired.

How to check what your install asks for

To see which tags the shipped jobs in your install actually declare, list the <DefaultImage> lines under resources/jobs/:

grep -h "<DefaultImage>" resources/jobs/*/job.xml | sort -u

The catalog itself lives at resources/data/ImageTypes.xml. The “routed” list above will be republished in the release notes whenever the bridge gains a new tag.

Adding a new type (single install only — not pack-portable)

Important: as of the current release, image types cannot be shipped from a pack. The only way to add a new type is to edit the engine-shipped resources/data/ImageTypes.xml in your own install. This is fine for single-player tinkering, but not portable pack content. Every player who installs your pack would also need to apply the same ImageTypes.xml edit by hand, and the next game update would overwrite it.

If you accept those limits and want to add a type to your own install:

1. Add a <Type> block to resources/data/ImageTypes.xml.
2. Give it a Name, Display, Description, and at least one Fallback so it degrades gracefully.
3. Restart the game. The engine auto-picks up the new type as both folder and prefix.

A type added this way is tagging only: the engine recognises the folder/prefix, tags the images, and the gallery can show them. It can never be requested during gameplay — not even by pointing an existing job’s <DefaultImage> or a message’s Image= at it. Those attributes resolve against the engine’s built-in request list, not against ImageTypes.xml, so an unknown name quietly falls back to the profile portrait. (Yes, that means a <DefaultImage>sleazy</DefaultImage> on your reskinned Waitress shows profiles, however correctly you tagged the art.) Surfacing a brand-new type in play still requires engine support.

The full 88-entry catalog is the source of truth. Read it when in doubt.

Shipping art as a standalone overlay pack

If you want to author default art for the new job-shift buckets (or replace the shipped defaults wholesale) without touching individual girl folders, drop the images into a pack at Characters/Default/. See where-packs-go – “Default-image overlay packs” – for the directory layout, supported subfolder names, and the filename-prefix aliases for older WMR / WM7 art (Dominatrix (N).jpg for dom, Advertisement (N).jpg for advertise, Mast (N).jpg for masturbate).

Checking your videos before you ship

The pack validator checks your XML, but it does not open your media files. To confirm the game can actually play every video in your pack, run the game from a command line with the video probe:

WhoreMasterRenewal --video-probe resources/packages/your_pack

It scans the folder (including subfolders) for .webm, .mp4, .avi, .mkv and .mov files, tries to play each one the same way the game does, and prints one OK or FAIL line per file, with a summary at the end. A FAIL means the game cannot play that file: re-encode it (WebM with the VP9 codec is the safest choice) and probe again.

You can also point it at a single file, or at resources/packages to sweep every installed pack at once. If the game starts up normally instead of printing a report, your build is older than this tool; it ships in builds released after 1.20.0.

Checking your videos before you ship

The pack validator checks your XML, but it does not open your media files. To confirm the game can actually play every video in your pack, run the game from a command line with the video probe:

WhoreMasterRenewal --video-probe resources/packages/your_pack

It scans the folder (including subfolders) for .webm, .mp4, .avi, .mkv and .mov files, tries to play each one the same way the game does, and prints one OK or FAIL line per file, with a summary at the end. A FAIL means the game cannot play that file: re-encode it (WebM with the VP9 codec is the safest choice) and probe again.

You can also point it at a single file, or at resources/packages to sweep every installed pack at once. If the game starts up normally instead of printing a report, your build is older than this tool; it ships in builds released after 1.20.0.

See also

• resources/data/ImageTypes.xml – the full catalog
• filename-cheatsheet – the common categories at a glance
• where-packs-go – default-image overlay packs
• jobs-reference – per-<Text> Image= override