Character-customisation file chain

Maturity: Draft. Consolidated and cross-checked for vanilla 2.31 female and male resources, ArchiveXL 1.27.3 source, one decoded 2.31 save and the implemented resolver's run on the reference installation; consolidated category by category on 30 September 2026 in the file-chain map, which also lists the source contradictions and the resolver's ranked gaps. Not yet runtime-tested in the areas marked hypothesis; the creator checks run in session 4 are in in-game results. Evidence grades follow the knowledge rules: source engine/framework/tool source, resource extracted game or mod resources, wiki Modding Docs text or image, runtime running game, hypothesis not yet established.

This page answers four questions for XF Studio agents:

1. How does a character-creator (CC) choice become geometry and materials? (render any V in the Studio viewport)
2. What options exist, and how are they identified? (expose every CC option as a Studio control)
3. How does a save store the choices? (later write-back and shareable CC presets)
4. How do mods add options? (our own eye-makeup selector via ArchiveXL/CCXL)

Material and shader internals (.mt/.remt templates, skin, hair, eye and decal shaders) are covered in materials and shaders; this page stops at "which material instance and which inputs".

Evidence snapshot

1. The chain at a glance

flowchart TD
    XL[".archive.xl<br/>customizations: female / male"] -->|ArchiveXL merges| CCO
    CCO["Sex-specific .inkcharcustomization<br/>female_cco(_ep1) / male_cco(_ep1)<br/>head · body · arms: options + groups"]
    CCO --> SW["SwitcherInfo choice<br/>activates other named options"]
    SW --> AO
    SW --> MO
    CCO --> AO["AppearanceInfo choice<br/>.app resource + definition name"]
    CCO --> MO["MorphInfo choice<br/>region + target name"]
    AO --> APP[".app appearance<br/>(name = CC definition)"]
    MO --> MTM["MorphTargetManager<br/>applies (target, region) to every<br/>morph component that has it"]
    APP --> INL["inline components[]"]
    APP --> PV["partsValues: component .ent"]
    APP --> PO["partsOverrides:<br/>componentName → meshAppearance, chunkMask"]
    INL --> COMP["Component<br/>MorphTargetSkinnedMesh · SkinnedMesh · GarmentSkinnedMesh"]
    PV --> COMP
    PO --> COMP
    COMP -->|morphResource| MT[".morphtarget<br/>baseMesh + named deltas"]
    COMP -->|mesh| MESH[".mesh"]
    MT --> MESH
    MESH --> MA["meshAppearance → chunkMaterials<br/>chunkMask hides submeshes"]
    MA --> ME["materialEntries → local instance<br/>or external .mi"]
    ME --> MI[".mi chain → .mt / .remt<br/>+ .xbm, .hp, .mlsetup, .sp"]
    MTM -.-> COMP

Read the diagram top-down. The three option types branch differently: an appearance option names an .app and one of its definitions; a morph option names a morph target that is applied by (target, region) across components; a switcher only activates other options. An .app appearance can list components inline and/or pull them from component .ent files; both are overridden by name. Rendered and inspected: see diagram review.

Naming conventions resource

Resource names are systematic, which makes a resolver and a human reviewer much faster. These meanings are inferred from consistent use across the extracted resources, not from CDPR documentation.

2. The .inkcharcustomization resource

Root type gameuiCharacterCustomizationInfoResource resource source. There is one per body gender, and the game ships two pairs:

The EP1 twin is the one in use when Phantom Liberty is installed. The reference save's tpp_head_face_rig hash 14034739559546167190 equals FNV-1a64 of ep1\characters\head\player_base_heads\appearances\head\face_rig\h0_000__basehead_face_rig_ep1.app, a path only the _ep1 resources reference resource. ArchiveXL's bundled fixes target all four paths [source: bundle/source/resources/PlayerCustomization*Fix.xl]. A resolver must therefore pick the pair that matches the installation, not assume the base\ path. The diffs are small (skin-colour definition metadata with unchanged names, a few index and link fixes, male lash/pimple group membership, the EP1 face rig) and recorded in the inventory.

Root fields

Merge behaviour: source ArchiveXL Extension.cpp lines 254–332; see the merge boundary.

Option types resource source

All options share name, index, defaultIndex, localizedName (a localisation key such as UI-CharacterCreation-eyes), uiSlot, link, linkController, editTags, hidden, enabled, randomizeCategory, censorFlag, censorFlagAction, onDeactivateActions.

Identity, and why indices are not identity

• Option identity: name within the head/body/arms list. Names are stable across base/EP1 resource.
• Choice identity: (option, definition name) for appearances, (region, morphName) for morphs, localizedName for switcher choices. ArchiveXL merges choices on exactly these keys [source: Extension.cpp 465–557].
• Indices are regenerated. ArchiveXL rewrites every choice index after merging [source: RegenerateIndexes, lines 605–637], and vanilla itself contains duplicate option indices (makeupEyes_09 and _10 are both 460) resource. Never persist an index as identity. The Studio should match saves by (app hash, definition) and (region, target) as the resolver contract already requires.

Links: how one colour follows several options resource

link is a free-form key shared by a family of options. Options with linkController = 1 are the ones the UI drives; followers with linkController = 0 (usually hidden) receive the same choice index. Evidence: every member of a family has the same number of definitions, and the vanilla UI presets store equal values across the family.

The wiki's CC options page (manavortex and redacted-c01, 2025) states that link syncs a selection across options wiki; its example, that hair colour also sets the beard, does not hold for 2.31: hair colours use hairstyle color and beard colours beard color, so nothing links the two resource (map contradiction C3). The vanilla UI preset ui_preset_female_corpo.charcustpreset stores skin_color = 10 and the value 10 for body_color, nipples_01, genitals_04, every arm option and neck; nails_color_tpp = nails_color_fpp = 31 resource. This is the strongest offline evidence for the link semantics; the exact propagation code is native and unread [hypothesis for edge cases, e.g. followers with a different choice count].

EP1 anomaly resource: in female_cco_ep1, eye-makeup styles 21–36 carry the link key LocKey#43269 instead of makeupEyes color, so under the link rule a colour chosen on styles 1–20 would not carry over to 21–36 (test ask 8).

Consequence for the Studio: choosing a skin tone is one control, but the renderer must apply that index to every linked option that is active, including tattoos and face cyberware whose colour follows skin tone.

Switcher link members: hairstyle and hairstyle_cyberware are both link controllers of hairstyle, but list their styles in different orders (they differ at 20 positions on the reference installation) resource. The Studio's character context carries a switcher member's choice as the choice that activates the same options, not the same position, and leaves a member without such a choice at its own (CORE-61). In game, a face cyberware that swaps the row keeps the same hair, at the same position for style 5 runtime (session 4); a style at one of the 20 differing positions would separate the two rules.

How the Studio stores and applies links (character context, src/character-context.ts): only the choice a person set is stored, one per link family (the latest wins); every other member, controllers and followers, is derived when the V is prepared (CORE-50, CORE-51). Resetting a member resets the family to the V's own. A portable preset therefore holds one hair colour, not every hairstyle's colour.

Slots, switchers and visibility resource

• A switcher's uiSlots name the slots whose content it swaps. makeupLips_type (slot makeupLips_type) → makeupLips/_glossy/_matte switchers (slot makeupLips) → 38 appearance options each (slot makeupLips_color). This is a three-level tree: finish → style → colour.
• A switcher owns its targets. An option that any switcher choice names is active only while an active switcher's current choice names it. Its own enabled flag does not keep it active beside another choice. Most targets are enabled = 0, but each switcher's default target is enabled = 1 (skin_type_01, eyebrows_color1, hair_color1, cyberware_00, hairstyle under cyberware), and the vanilla UI presets store it inactive whenever another choice is chosen. Targets of an inactive switcher are inactive too. An option that no switcher names is active when enabled. Evidence: all six vanilla UI presets, 1,736 target checks with no exception, and the reference save; the native code is unread (evidence). This matches the wiki's rule that a uiSlot holds one active option at a time wiki.
• "Off" is what the creator labels Off. The creator shows a choice's localizedName and nothing else (see Labels below), so a choice is Off exactly when its label is the game's Off text (Common-Off, "OFF" in English) [source + resource]. In 2.31 that label sits on 17 feminine rows' choices (eye, lip, cheek and blemish makeup, scars, tattoos, piercings, pubic hair, body scars, and the legacy XF Eye Artistry layers on the reference installation). Adding nothing is not Off: the first nipples choice activates nipples_01, an option with no .app because those nipples are in the skin's albedo, and reads 01; every face morph's None is the base shape (01); a breast size's None is Default; the bald hairstyle is 51 resource. The other way round, the choice labelled Off on nipples (nipples_04), genitals and face cyberware adds an appearance resource. What is true of adding nothing: those choices are a None definition (on an option with no .app, such as piercings_00, makeupEyes_00, hair_color_none, or as definition 0 of one with an .app, such as scars), a switcher choice whose options add nothing, or a morph's None; they name no appearance, and the save stores no entry for them.
• hidden = 1 options never get their own UI row (proxies, FPP twins, colour followers).
• switchVisibility and actions exist on switchers and choices; vanilla actions are rare. switchVisibility does not decide target deactivation: skin_type and cyberware have it at 0 and still deactivate their defaults resource. Its meaning is unknown. source ArchiveXL does not copy switchVisibility, hidden, enabled or linkController onto an existing option during a merge, only onto a wholly new option.
• editTags = NewGame, HairDresser, Ripperdoc: which editing context may change the option (new game, mirror/hairdresser, ripperdoc) resource. Body skin colour is NewGame/Ripperdoc; makeup and hair add HairDresser. Which context applies is the menu's, not the caller's wish: a creator opened from the pause menu's scenario switch reports NewGame and makes every NewGame row editable even when asked for HairDresser runtime (below).

Groups: who consumes a choice resource

Groups do not define the UI; they tell each consumer which active options belong to it. The same option can sit in several groups (e.g. eyes_color is in TPP, TPP_photomode and character_customization).

Body groups: FPP_Body/TPP_Body (perspective pair), character_creation, genitals and breast (consumed by gameuiCharacterCustomizationGenitalsController {bottomBodyGroupName: genitals, upperBodyGroupName: breast}), lifted_feet/flat_feet (…FeetController). Arms groups are holster/cyberware states (holstered_default, holstered_strong, holstered_nanowire, holstered_launcher, holstered_mantis, their unholstered_*, personal_link_*) consumed via perspectiveInfo, plus nails (…NailsController) and …ArmCyberwareController. Female arms groups are split _tpp/_fpp; male groups are not resource.

Presentation: order, rows, sections, labels and swatches

How the creator presents the options, and where the Studio's catalogue (src/cc-catalogue.ts) takes each part from. Sources: the installed 2.31 game scripts (r6\cache\final.redscripts, SHA-256 2119046f…ee86, no redscript backup beside it, decompiled with redscript-cli 0.5.31 decompile -f into a private scratch folder; files cyberpunk/UI/fullscreen/pregame/characterCreationBodyMorphMenu.script, characterCreationBodyMorphListItem.script, characterCreationPunkRandomizerMenu.script and orphans.script), the compiled TweakDB (r6\cache\tweakdb_ep1.bin, SHA-256 89c7ee67…14c5; tweakdb.bin 918f0acf…13f9 holds the same category list) and the English text resources.

The TweakDB blob is read with WolvenKit's layout (flats by type, (TweakDBID, index) keys). A record's field ID is the CRC-32 of the record name continued over .<field>, so fields of records known only by ID (the category list's entries) are addressable without their names (src/tweakdb-flats.ts). Every count in the blob is bounded by the bytes that could hold it before anything is allocated (PIPE-49).

In the Studio. The host builds each body gender's catalogue once per installation and sends the Character panel a compact projection (src/cc-panel.ts, xfs/cc-panel-5, about 319 KB for the reference installation's 943 options and 131,856 choices): sections, rows, options (label, type, choice count, Off and default keys, link, the switchers that turn it on), with mods and coverage notes in tables by index and each mod's maker group (the base game; XF Studio's own mods, known by the xfs_ prefix of their creator resource; the author Vortex records as author or uploader; else the mod's own name, since MO2's meta.ini records no author [observed: 1,000 meta.ini files on the reference instance]), so a row can group its choices by who made them; an option's choices come in pages of 240 when its row opens, and a search over every choice runs on the host. A switcher choice is identified by the options it activates as well as its name (the creator picks by position, so two same-named choices stay apart; CORE-70). An option's Off is the choice the creator labels Off (labelledOff: the game's Off text, or "Off" written out), never a choice inferred from adding nothing (off, kept only as structure: a save stores no entry for it).

Swatches in the Studio (src/cc-swatch.ts, src/cc-swatch-host.ts): every colour row's choices get a swatch derived from the resource that wins for them, the way the preview draws it: a hair or eyelash profile's baked root-to-tip row (hair shading §3) as five colours, the iris ring's base colour, the skin's toned albedo, a decal's colour times its texture's coverage-weighted colour (brows through their gradient map). Choices that follow one link share a swatch per choice key, answered by one member's chain (a hair colour across 522 hairstyles); a colour-only controller (the skin tone) is answered by a drawn follower at the same position, as the link applies it. On the reference installation 2,231 swatches cover 127,648 of the 129,064 choices in colour rows; the rest are multilayered eyes (which have icons) and a few chains that resolve nothing. Hair-tone packs that replace vanilla profiles at their paths make every vanilla hair, brow and lash swatch a mod's colour: a colour whose profile, gradient, colour texture or colour-setting material instance comes from a mod other than the choice's own supplier is marked replaced (24,888 choices), and the panel shows its derived colour instead of the icon, which would show the replaced colour. Icons come from the compiled TweakDB overlaid with the installed TweakXL YAML (src/tweakxl-overlay.ts, src/cc-icon-host.ts). What the preview draws of each option is the preview side's projection (catalogueCoverage, src/cc-render-coverage.ts), never stored in the catalogue (CORE-60); a conditional option settles from the parts the shown V's record draws. A head option whose resource names no category (the enum's default, Body) is filed with the rows around its position instead (UI-60). A base creator resource that a mod archive replaces names that mod as the source of its options and choices (PIPE-46).

3. From .app to pixels

.app definitions resource wiki

Every vanilla CC .app holds both body genders' appearances, distinguished by name (…pwa…/…pma…, female__…/male__…, w__/m__) and visualTags (Female/Male). The CC definition name equals the appearance name. Typical definition:

• partsValues[]: one or more component .ent files, e.g. …\appearances\entity\face_decals\hx_000_pwa__basehead_makeup_eyes_01.ent.
• partsOverrides[].componentsOverrides[]: {componentName, meshAppearance, chunkMask} applied to that .ent's components. The chunk mask only hides: it is ANDed with the component's own, so an override can't show a chunk the component hides [source: ArchiveXL ComponentState::AddHidingChunkMaskOverride] [wiki: the .app page, "You can't un-hide something via partsOverrides"]. A mod's copy of an .app can therefore mask a creator part out entirely (body animation §4).
• components[]: inline components. In vanilla CC .apps they mirror the partsValues components with the overrides applied, but inline components can also be the only source of geometry (PRC and the legacy generator rely on this; see section 6). The wiki chain map covers partsValues/partsOverrides screenshots and ArchiveXL's empty-partResource handling.

Three variant mechanisms appear, often combined:

Makeup and decal .app overrides also name the head skin component MorphTargetSkinnedMesh7243, which the decal .ent does not own; its purpose is unknown [hypothesis: harmless carry-over from a shared authoring template].

Components resource

entMorphTargetManagerComponent on the player entity resource is the likely applier of the region/target pairs to all morph components hypothesis.

Morph targets resource wiki

• .morphtarget = baseMesh reference plus an embedded geometry blob and targets[], each {name, regionName}, e.g. {h091, eyes} resource. WolvenKit's GLB export names the shape keys <name>_<region> (h091_eyes), which is what the Studio's assets use; the head/plate master carries 105 female targets (5 regions × 21).
• Female morph options offer None plus 21 targets per region (h011…h211 for eyes, h0N2 nose, h0N3 mouth, h0N4 jaw, h0N5 ear); male offers 20 (…h201) resource. The last digit encodes the region.
• Every component that follows the face carries matching targets, but only for the regions it needs: head and brows carry all 105; eyes and lashes the 21 eyes targets; a vanilla earring placeholder the 21 ear targets; a nose ring the 21 nose targets; a PRC linked-mesh ring all 105 resource. The pair (target, region) is the key, and the save stores both. A component without a region's targets simply does not follow that slider [hypothesis; consistent with every inspected resource].
• The eyes follow the eye shape through their own morph resource. The installed eye entity he_000_pwa__basehead.ent binds he_000_pwa__morphs.morphtarget (21 eyes targets, baseMesh = he_000_pwa_c__basehead.mesh), separate from the head's h0_000_pwa__morphs.morphtarget; both carry the pair {h091, eyes} and the other 20, and the 34 joint matrices the two h091 targets share are identical resource (experiment 015 trace). A shape moves the eyeball, lash and wetness chunks by up to about 4 mm. XF Studio's derived preview applies each eye-shape choice to every mesh carrying that (target, region) pair (src/face-morphs.ts); with the eyes left static, 18 of the 21 shapes left the eyeball showing through 35–354 of the 680 lid/socket rim vertices; with the eye targets, 14 shapes are within one vertex of the neutral assembly's 12, the worst is 41 (h121), and h181/h191 rise from 3/7 to 16/19 (offline, derived 2.31 assets, nearest-vertex signed-gap proxy) [resource; game rendering not compared].
• Resource order is not option order. The eyes option's morphNames (None, h011 … h211) follow the morph resources' target order, but the vanilla female nose option lists h112 after h162 resource. Choice identity is the (region, target) pair; a selector must take its order and labels from the merged CCO, never from a mesh. The creator's choice labels are two-digit positions (localizedName 01 = None, 10 = h091) resource.
• The morphtarget guide (no page author evidenced) says the engine activates targets by name and region, face regions blend together while chest size is exclusive, and mods cannot add new activation names, only reuse existing ones wiki. The creator side can grow: ArchiveXL appends a morph choice whose localizedName is new (Extension.cpp 504–528) source; whether the engine then applies a target name that only a mod's morph resources carry is untested hypothesis, and no installed mod adds morph choices.
• Facial rigs. Each head .app uses a face-rig component; the game ships 22 female and 21 male per-shape skeleton rigs, and the NPV rig guide (saltypigloaf, 2025) reports that vanilla V always uses rig 000 whatever the sliders, a known cause of eye clipping that community rig-fix mods address wiki. The Studio's saved-head morph binds should account for this (brow idle gap, experiments 012/015).
• Exporting a morph target with its rig. WolvenKit resolves a .morphtarget's baseMesh itself: CLI uncook of the morph target from the game archives (or export … -gp <game> of an extracted copy) writes a bone-bound GLB with the base mesh's skin (254 joints, two four-influence sets for the female head) and every target as a shape key. No custom exporter is needed. CLI 8.17.4 reproduces experiment 012's bound head byte for byte; 9.0.1 gives identical positions, UVs, influences and morph deltas but gives joint nodes rest rotations with matching inverse binds, so rest deformation is identical resource (experiment 013). The export keeps native vertex and triangle order, so the eye plate recipe's native face IDs select the same rows in the GLB resource.
• Body morphs: breast (female: t0_000_wa_base__full_breast_small / none / _big), nails_l/nails_r (long nails), penis_base/penis_circumcised size. There is no vanilla body-shape slider beyond these.

Meshes and materials

meshAppearance → chunkMaterials names → materialEntries (local buffer or external .mi) → .mi chain → template. Resolved examples: skin → skin.mt with a four-level .mi chain (saved skin chain); teeth → teeth_base.mi → skin.mt with its own skin profile; hair → hair.mt + .hp profile (hair profile); brows → mesh_decal_double_diffuse-family instance with a gradient (brow audit); eye makeup → makeup_NN_<colour>.mi → makeup_color__NN_<colour>.mi → mesh_decal.mt on one shared mesh for all 36 styles; lipstick → mesh_decal_double_diffuse or mesh_decal depending on the style; cheeks, pimples, scars, facial tattoos, face cyberware and male stubble → mesh_decal; piercings → multilayered.mt; the eye mesh's third chunk (wetness) → eye_shadow.mt resource. The per-option templates, key parameters and chunk roles are tabulated in head CC rendering §1. Shader behaviour: materials and shaders.

4. Every CC detail, and what drives it

The file-chain map carries the same categories with their save groups, ArchiveXL support, installed CCXL extensions and the Studio's status. Female and male names differ only where stated. "Opt" is the option type (A = appearance, S = switcher, M = morph). All counts are vanilla 2.31 resource; per-option detail is in the inventory. The wiki's CCXL overview has a matching table of vanilla uiSlot names and option types wiki. Its character-creator cheat sheet (last updated January 2025) lists fewer choices than the 2.31 resources (e.g. eye makeup 1–20 against 36 styles, lip styles 1–20 against 38, face cyberware 1–8 against 16); the resource counts are current, but which choices the UI actually shows is test ask 9.

5. How ArchiveXL/CCXL extends the lists

Details and line references: CCXL merge boundary and catalogue probe. Summary source ArchiveXL 1.27.3:

1. Registration. An .xl lists customizations: {female: [...], male: [...]}. ArchiveXL prefetches each resource and merges it into the loaded base male or female resource (MergeCustomEntries). There is no male/female sharing: a mod that supports both body genders registers two resources (e.g. *_pwa and *_pma).
2. Fixes first. FixCustomizationOptions applies resource.fix.paths to base options before any mod merge: e.g. vanilla he_000__basehead.app → archive_xl\…\he_000_pwa__basehead.app, heb_000__basehead_NN.app and hel_000__basehead.app likewise. Each remap registers an app override so saved descriptors using the old path still resolve.
3. Groups. Group entries are appended only to existing groups with the same name; a new group name is ignored.
4. Named options merge into the same-named, same-typed option (definitions by name, morphs and switcher choices by localizedName), otherwise the whole option is appended. A new option may carry any metadata; a merge into an existing option does not change its top-level metadata. A merged choice whose key already exists replaces the existing choice (targetChoice = sourceChoice, lines 473, 517, 544), so an addition is additive only when its keys are new. Vanilla switcher choices are often labelled by position (01, 02, …): a mod choice labelled 15 in the piercings row would overwrite masculine V's vanilla style 15 (jewellery §5).
5. Anonymous overlays (no name) target existing options by uiSlot and/or link, with * suffix wildcards, in a second pass. Source note: the link-wildcard flag is computed from the slot string (Extension.cpp:379 reads sourceSlotStr), so a link-only wildcard does not appear to take effect [source reading; not runtime-tested].
6. App overrides. When a merged definition's option names a different .app than the target option, ArchiveXL records (target app, definition) → (mod app, definition) and rewrites appearance descriptors at OnGetAppearances/OnChangeAppearance(s). This is why a saved choice can carry the vanilla-option-associated app hash yet render from a mod app (see the Unique Eyes example in the catalogue probe).
7. Dynamic customization appearances. FixCustomizationAppearance clones a template appearance inside the player_customization.app scope for a missing requested name; the suffix after __ becomes the mesh appearance. Combined with mesh names/context fixes (@eyes, @lashes, @beard, @cap, @dread), one template can serve many colours. The scopes and extensions guide (manavortex) illustrates the makeup variant: an @context material naming MakeupBaseMaterial, an @makeup material pointing at *…\{material}.mi, and one small colour .mi per colour; it warns that several styles in one mesh block later colour extension wiki.
8. Indices are regenerated; hair-colour tags go to the TweakDB flat.
9. Older saves. A new option that is enabled, not hidden and absent from the loaded state is added to it (appearance and morph options) or activated (switchers) at its default (OnInitAppOption, OnInitSwitcherOption, lines 97–143), so a save made before a CCXL mod was installed shows the new row at its default choice.
10. Removal. ArchiveXL can remove every custom entry it registered (RemoveCustomEntries) source; whether the game calls this on reload is runtime behaviour hypothesis. What the game draws for a saved choice whose mod is gone is unread; icxrus's eyelash guide tells players to select the vanilla lashes before uninstalling a lash mod, because the lashes otherwise disappear [wiki; community runtime, not ours].

Which categories ArchiveXL itself supports [source: bundle/source/resources/]. Only five categories have a bundled fix, scope and colour patch: eyes (@eyes), lashes (@lashes), brows (@brows), hair (@long, @short, @cap, …) and the masculine beard (@beard). They alone are in the player_customization.app scope, so only their mod options get the dynamic appearance cloning of rule 7. A CCXL option for makeup, piercings, tattoos, scars, cyberware, teeth, nails or the body must define every appearance its definitions name; the mesh side's @context / *{material} expansion still works for any mesh (mod loading §5). The body-tattoo guide's CCXL route is an unnamed switcher with only link: body_tattoo, which the overlay pass adds to both the third- and first-person tattoo switchers, since they share that link [wiki: ccxl_tattoo_mesh_file.png] source.

Entity patches: always-on parts outside the creator [source: ArchiveXL ResourcePatch/Extension.cpp 252–345, 740–857]. A resource.patch whose source is an .ent merges into the target entity template its appearances (replacing same-named ones), resolved dependencies and visual tags, and, when the entity or a part .ent is built, adds the patch entity's components. The wiki's facial-cyberware guide (mana vortex) uses this to put a custom decal on every player entity (third person, photo mode, cutscene, reflection, EP1): always drawn, never a creator choice and absent from the save wiki. On the reference installation three mods patch .ent files, among them a face-rig fix that patches every feminine and masculine player entity resource. The Studio does not apply .ent patches yet (R6b).

XF Studio's single eye-makeup selector (one switcher with Off and complete-look choices in the face group) follows this model; see experiment 005 and the ArchiveXL strategy.

Hair-colour additions

Every CCXL hair-colour pack on the reference installation (six, 150 colours) follows the wiki's hair-profiles template (study):

• Anonymous slot overlays [source + resource]. The pack's creator resources hold only unnamed appearance options with uiSlot hair_color, eyebrows_color, eyelash_color (and beard_color in the masculine resource), each listing the colours. ArchiveXL merges every mod's named options before any overlay (MergeCustomEntries), so the colours reach all 73 feminine and 78 masculine hairstyle colour options, cyberware twins and CCXL hairstyles included, whatever the load order. Each overlay appends the same list to every matching option, which keeps the hairstyle color link index aligned for styles that start from the 35 vanilla colours. Exact-slot overlays also reach hair_color_none (the bald choice) and feminine eyebrows_color0 (brows Off); what those rows then show is untested.
• Definition name → mesh appearance source. FixCustomizationAppearance strips a leading NN_ (two digits and an underscore), takes what follows the last __, or else uses the name whole (38_ash_brown → ash_brown; sigh4_mch_blondeice unchanged). A pack's patch.mesh, patched into the player hair, hat-hair, brow, lash and beard scopes, adds that empty appearance with ten @family templates whose paths expand {material} to the pack's .hp and cap gradient (mod loading §5). ArchiveXL's own fix gives 295 vanilla meshes the matching template families.
• Tags [source + wiki]. For hair_color targets the choice's tags go to TweakDB ItemFactory.HairColors.hairColors; garment dynamic appearances substitute the chosen colour's tag as {hair_color}, so hair under hats needs the tag to equal the mesh appearance name. One installed pack leaves all 21 tags at the template placeholder.
• Brows, lashes and beard get the same names in their own rows, with no engine link to the hair row. Brows draw the cap gradient's last texel; lashes draw the profile's tip (eyebrows §3, hair reference §9).
• Rendering never consults the creator list: a saved (app, definition) is cloned from the requested name alone, so a colour whose definition is gone but whose patch appearance and files remain should still render [hypothesis; the study's checklist item 9].

Multi-part hairstyles (Multicolored Hair)

The Multicolored Hair framework (Nexus 21613, 1.1) makes multicoloured hair from geometry: a hairstyle is cut into up to three meshes, each an ordinary CCXL dynamic hair with its own colour row (study).

• Its own switcher [source + resource]. The vanilla hairstyle switcher's uiSlots are fixed at hair_color and hair_color_fpp, and a merge never changes an existing option's top-level fields (§5 rule 4), so extra colour rows need a new switcher. The framework's mch_hair_switcher (link mch_hairstyle feminine, mch_hairstyle_pma masculine) owns slots mch_hair_part_01…03 and mch_hair_fpp. Its Off choice names four resource-less placeholder options.
• Hairstyles join by link [source + resource]. An MCH hairstyle ships an anonymous switcher with only link: mch_hairstyle. The overlay pass (§5 rule 5) appends its choice to the framework's switcher. The choice names one named appearance option per part, each a link controller of hairstyle_color_N, plus an FPP shadow option. Switcher choices merge by localizedName, so two MCH hairstyles with the same name replace each other.
• Parts render like any CCXL hair resource. Each part has its own .app with one template appearance, in the player_wa_hair.app scope, and its own mesh with @context/@long/@cap entries, in the player_wa_hair.mesh scope. Vanilla and pack colours therefore reach every part mesh through the existing patch meshes. A colour appears in a part's creator row only when its pack also overlays mch_hair_part_01…03. A pack that doesn't needs a creator-only patch listing its definitions on those slots, which is what the framework's compatibility patch for redacted-c01's pack is.
• Consumer resource. Part options sit in hairs and character_customization, so the hairstyle controller draws them beside, and independently of, the vanilla hairstyle. The framework's instructions set the vanilla hairstyle to 51 while MCH is on. The Studio draws every active option in hairs as hair by this consumer rule (no framework slot names), so each part draws with its own colour.

6. Case study: why PRC piercings work in game

eagul's PRC Fully Modular Jewellery Framework predates CCXL and uses no .xl, .inkcharcustomization, TweakXL record, script or ArchiveXL feature [resource: archive listing in the PRC inventory]. It works purely by replacing files that vanilla already reads. Once the Studio interprets archives the way the game does, PRC support is a side effect, not an adapter.

flowchart TD
    CCO["Vanilla CCO option<br/>female piercings_12 · male piercings_14<br/>resource = i0_000__earring_14.app, 16 colours"] --> APP
    APP["i0_000__earring_14.app<br/>same depot path, replaced by the PRC framework archive<br/>(mod archive beats base archive)"]
    APP --> PART["Kept vanilla part:<br/>i1_000_pwa_earring__basehead_04.ent<br/>+ override, chunk mask …610"]
    APP --> BANK["128 inline components fpm1…fpm128 (mpm for male)<br/>all with the definition's one meshAppearance"]
    BANK -->|unfilled slot| PH["fpmN.morphtarget placeholder<br/>zero render chunks → draws nothing"]
    BANK -->|filled slot| ITEM["fpmN.morphtarget from an item archive<br/>same depot path, sorts before PRC_z_999 → wins"]
    ITEM --> LM["baseMesh: vanilla earring mesh or linked .mesh<br/>has appearances silver, gold, … wood"]
    LM --> MAT["chunkMaterials → .mi → multilayered.mt / .mlsetup"]

Limits that follow from the design: one colour for every item; slot numbers collide between packs (three septum packs all use fpm17); a pack's slot is only visible if its archive wins; vanilla style 12 cannot be used on its own while PRC is installed.

What the Studio needs from this: nothing PRC-specific. The generic rules in section 8 — archive precedence, inline plus partsValues components, zero-chunk geometry, mesh-appearance lookup on each component's own base mesh, and resolving baseMesh through the same mount set — produce the PRC result, and the implemented resolver does so on the reference installation (validation).

7. How a save stores CC choices

Full format and reader: save import. Summary:

• Node CharacetrCustomization_Appearances (engine spelling): dataExists, an unknown u32, preset version (12), isMale (body gender), isBrainGenderMale (voice), then head, arms and body group lists, perspectiveInfo and tags [source: WolvenKit CharacterCustomizationAppearancesParser.cs].
• Each group is {name, appearances[{resourceHash u64, definition, name (option name), censorFlag, censorFlagAction}], morphs[{region, target, censorFlag, censorFlagAction}]}.
• resourceHash = FNV-1a64 of the lower-case .app depot path. Verified for teeth, lip, cheek, neck and EP1 face-rig entries of the reference save resource.
• The save stores resolved output, not UI state. It lists, per consumer group, the active appearance options with their chosen definition, and the non-None morphs. It does not store switcher choices, link indices or colour-only controllers (skin_color never appears; its choice is visible only as the definition of skin_type_05, body_color, arms and so on). The same choice is repeated in every group that contains the option: in the reference save, eye colour appears in TPP, TPP_photomode and character_customization.
• The node mirrors the creator resource [resource: two 2.31 saves against the installed feminine resources]: its head, arms and body group lists are the resource's headGroups, armsGroups and bodyGroups in the same order, empty groups included; its perspective list is the resource's perspectiveInfo; its preset version is the resource's version (12); vanilla options appear within each group in the resource's option order. Censor fields copy the option's own (Censor_Nudity = 1; Activate = 0, Deactivate = 1), so body entries carry non-zero values and both the censored and uncensored body variants are stored. The two tags are the chosen hair colour's and hairstyle's tags (colour name and length). Re-encoding a decoded node reproduces it byte for byte.
• By contrast, the vanilla UI preset .charcustpreset (gameuiCharacterCustomizationUiPreset) stores the index state: {optionName, isActive, value} for every option, value = 0xFFFFFFFF when unset, plus isMaleVO resource source. WolvenKit also registers .ccstate as a gameuiCharacterCustomizationPreset resource, the same type as the save node [source: FileTypeHelper.cs].

Writing back: what is known

The safe order is: generate the complete group set from an option state using the effective CCO, write to a copy, re-read with both the Studio reader and WolvenKit, then verify in game. The container side is now measured: the node is root-level, childless and sits in the last compressed chunk of both saves, and sav.dat has no checksum; the save write-back design sets out a minimal-diff writer, its integrity gates and an alternative that applies the look in game through the bridge. CC presets for sharing should store the UI state (option names + choice identities, like .charcustpreset but by name rather than index) and derive the save representation, not the reverse.

8. Generic resolver specification

Principle: the Studio interprets game files the way the game and its core frameworks do. Vanilla piercings, PRC, CCXL packs, hair-colour packs and future mods must all resolve from data through the same rules; there are no mod-specific adapters. Where a rule is not yet proven, the resolver reports the uncertainty instead of guessing.

Status: phase 1 implemented in projects/xf-studio/authoring/src (character-resolver.ts and the pure modules it uses; host adapter resolver-host.ts; CLI tools/resolve-character.ts). It reproduces the hand-traced eyes, hair, brows, lashes, skin and PRC chains of the reference installation from data alone; see the resolver validation. Archive precedence and ArchiveXL semantics are consolidated in mod loading. The Studio preview consumes it for the skin, face details, brows, lashes, hair, eyes and piercings (the shown V's resolved components, planned by character-detail-plan.ts and exported into the character render record; head CC rendering P0); Build uses its archive layer for the eye plate's head.

Inputs

1. Installation view: base game archive/pc/content, archive/pc/ep1 (if present), archive/pc/mod, the ArchiveXL bundle directory, plus the mod manager's virtual view (MO2 profile with overwrite, or manual files). Vortex needs no adapter for the files, since it hard-links them into the game folder (Vortex §5); REDmod is a later adapter. Source discovery enumerates the files; resolver-host.ts reads RDAR indexes and reads resources natively first (archive formats), falling back to WolvenKit CLI per resource with an ignored JSON cache (mod loading §6).
2. Framework declarations: every visible .xl in ArchiveXL's load order (customizations, resource.scope/fix/patch/copy/link). TweakXL records are presentation only (R11) and not read yet.
3. Character input: a decoded save node (inputFromSave) or a UI option state (descriptorsFromUiState: option → definition, morph or switcher choice). The character context (src/character-context.ts) holds such a state, built from the default V, a save (recovering switcher and link-controller choices the save doesn't store) or an xfs/cc-preset-1 preset.

Rules, in application order

Output: a renderable description

ResolvedCharacter (character-resolver.ts, schema xfs/resolved-character-1) lists one entry per unique saved or derived (option, definition) with the groups that use it, the requested and effective .app (with any override), who provided the choice (base CCO or which custom resource), the appearance status (defined, dynamic with its template, or missing) and its components. Each component carries its origin (inline or part), final mesh appearance and chunk mask, geometry provenance (.morphtarget, .mesh, render-chunk count, visible chunks, drawsNothing, patch sources), morph regions and the saved morphs that reach it, and per visible chunk the material route, instance chain, template and effective parameters. Every resource reference is a Provenance: depot path and hash, winning archive and provider, losing alternatives, the rule and its grade, copy/link hops and the extracted-byte SHA-256. Character-level ambiguities and gaps list everything unproven or unresolved. Reports stay local because they name installed mods.

Everything is data: a vanilla piercing, a PRC slot and a CCXL earring produce the same shape, differing only in provenance.

Retiring the PRC-specific code

Done 26 September 2026. With PRC installed, resolving vanilla piercing option 12 yields the framework's .app, its 128-slot bank (placeholders drawing nothing, filled slots from their item archives by alphabetical order), the kept vanilla part with the framework's chunk mask, and the stud's default__02 → base\eagul\mat_1.mi material (validation). The preview now draws exactly that: piercings are a slot of the character record, selected by the creator slot piercings_color, each resolved drawing component with its own chunk mask, through the layered adapter (head CC rendering). What the old code did and what replaced it:

With PRC installed, the "Piercing 12" choice is the PRC bank, as in game; there is no separate PRC style. Trying a style in the viewport asks the host to resolve the V with that creator choice in place of its own.

9. Male and female, NPCs and later full-body work

• Body gender = entity. The player is player_wa_* or player_ma_* (TPP, FPP, photo mode, cutscene, reflection variants, plus EP1 copies; list in ArchiveXL PlayerBaseScope.xl) source. The save's isMale corresponds to the CCO and entity choice; isBrainGenderMale (the presets' isMaleVO) is independent: the voice, set by the creator's voice-over switcher row and by the body-gender screen (§4, Voice tone) source.
• Separate option catalogues. Male has beards (a 13-choice beard switcher over 13 per-style part switchers and 57 colour options), 20 instead of 21 face targets per region, no breast morph, a two-choice nipple switcher, no split _tpp/_fpp arms groups, and different body .app choices (t0_000_pma_base__full.mesh, male body is not morph-skinned) resource. Genital choices are available to both.
• Shared .app files. Most CC .app files contain both genders' appearances; a resolver keys on the definition name, never on the file alone.
• NPC reuse. Vanilla NPC and photo-mode entities reuse the same head bases (PhotoModeScope.xl lists NPC photo-mode puppets such as Judy and Panam alongside player_wa_photomode) source. h0_000_tattoo.app carries named NPC tattoos (tygerclaw, valentino) and lip styles carry NPC names, showing the same resources dress NPCs resource. Converting a V into an NPC ("NPV") bakes the chosen options into a standalone .app: the NPV guide (manavortex, crediting NoraLee for the process) reads the CC numbers in game, keeps only the used head parts, applies the matching shape keys to every head part in Blender and re-imports them; its app structure screenshot is an illustrated map from CC categories to components (h0_head, he_eyes, ht_teeth, heb_eyebrows, hx_makeup_eyes with black_07, hx_makeup_lips_01 with peach_04_03, i1_earring, tattoo, cyberware, hair, body) [wiki, editor illustration]. The Studio's renderer is effectively a live NPV: the same parts, but morphs applied at runtime instead of baked.
• Full-body customisation later. The preview draws the vanilla body since 26 September (body rendering). Body coverage in the creator is limited to skin tone, breast size, nipples, genitals, body tattoos/scars, nails and feet. There is no vanilla body-shape morph. Body mods (e.g. replacer bodies) change t0_/a0_/l0_ meshes and rely on garment refitters; they are out of scope for the head-focused Studio but the same chain applies. The wiki's garment-support page gives the component-prefix layering scores (s0 0, l0 10, a0 20, t0 30, h0 40, … hh 90) that decide which garment deforms over which body part wiki.

10. Studio rendering readiness

Source: audit of projects/xf-studio/authoring/src on 2026-09-25, rows updated as later steps landed. Since 26 September the Character panel (src/cc-panel.ts) lists every creator option, so any detail the preview draws can be changed there as well as read from a save. The per-option templates each gap needs and the ranked render plan are in head CC rendering. "Selectable" means a Studio control exists; "Save" means it renders only when an imported save matches.

Common prerequisites: wiring the implemented generic resolver into the preview (done: the skin, face details, brows, lashes, hair, eyes and piercings go through it and the generic exporter into the character render record); one morph-target mesh path for all hx_ decals (makeup, pimples, tattoos, scars and face cyberware share morph-skinned decal meshes over the head, so one geometry path plus the decal material family covers them; done in rank 2); and the skin shader adapter (done in P1). The derived head.glb reads the base game's content archives only; a resolver-driven head would load the winning h0_000_pwa__morphs.morphtarget, which matters because installed mods (for example a facial-rig fix) can replace it (saved skin chain).

Lessons from the legacy generator

From the legacy xf-omega eye-makeup generator (female only, reference only) and its design notes:

• It registered one switcher per layer in character_customization and face, with an Off option and colour lists linked through a link string; its variant options were enabled = 0 behind the switcher, mirroring vanilla. Vanilla uses "<option> color" link keys with a space; the legacy code used colour, which still works because the key is only a shared string.
• It placed a morph-skinned component directly in each .app appearance, instead of vanilla's partsValues .ent plus partsOverrides. The game accepted this (so does PRC, section 6); the vanilla structure is still preferable for ArchiveXL's customization fallback, which operates on partsOverrides.
• Its option indices collided across layers. ArchiveXL regenerates choice indices but not option indices; keep option indices unique and never rely on them for identity.
• A 4 layers × 20 designs × 49 colours × 4 finishes matrix (15,680 appearances) made the mod slow to open in WolvenKit (measured structure). XF Studio compiles only authored complete looks.
• UI icon atlases imported as TEXG_Generic_Color looked washed out in game; they must be TEXG_Generic_UI.

Diagram review

Open questions

1. How exactly does link propagation handle a follower whose choice count differs from the controller (e.g. tpp_head_proxy has 16 definitions against 12 tones; the corpo preset stores 0 for it)?
2. Which consumer applies the TPP, TPP_photomode, FPP, proxy and character_customization groups? The CC controller components cover hairs, face, beards, nails, genitals/breast and feet; the head item is unconfirmed. For photo mode, character_customization alone is not enough for a face-decal option (runtime, 25 September, finish board results); whether face alone is enough is being tested.
3. On load, does the game rebuild option state from the save's appearance lists (needed for the mirror to show the right selection), and what happens to entries whose hash or definition is missing? The only evidence so far is community advice that a removed lash mod's lashes disappear (§5, rule 10); it matters for every rebuilt XF Eye Artistry collection.
4. Does entMorphTargetManagerComponent silently skip components without a target, or does it fail? (Affects CCXL accessories lacking a region.)
5. Is the link-wildcard branch in ArchiveXL's anonymous overlay intentionally tied to the slot suffix?
6. Why do decal .app overrides name the head component MorphTargetSkinnedMesh7243?
7. How does the runtime use censorFlag/censorFlagAction? The save copies each option's values (non-zero on the body's nudity-dependent entries, §7), and stores both censored and uncensored variants.
8. Does ArchiveXL remove and re-merge custom entries on every load, so that uninstalled options disappear cleanly?
9. What is the native engine rule for a depot path present in both a base-game and a mod archive, and for bundle order? Tool sources (WolvenKit, ArchiveXL) put mods first; PRC depends on it, but the native lookup has not been read or measured.
10. Are eye-makeup styles 21–36 in the EP1 CCO deliberately on a separate link key, and are all resource-listed choices visible in the UI?
11. How does the engine treat several components with the same name in one appearance (the reference installation's teeth .app from a morph-additions mod has 16)? The preview draws the first drawable one hypothesis; in that mod's case the other 15 carry LOD mask 0 on their only chunk, so the question does not change what is drawn there resource.
12. The EP1 CCO and the reference save use i0_000_pwa_base__vagina__01_ca_pale_00_warm_ivory, which no installed i0_000_base__genitals.app defines. What does the engine fall back to?
13. Does the engine load resources that WolvenKit 8.17.4 and 9.0.1 reject as an older layout (a replacement feet .app with castShadows stored as Bool)?
14. Does the native GetUnitedOptions sort by option index alone, and what makes an option isEditable? The Studio leaves out hidden options and link followers; holstered_data (feminine arms, no label) is neither and still gets a row.
15. Which TweakDB blob does the game load with Phantom Liberty (tweakdb_ep1.bin is assumed), and does the text lookup pick maleVariant for a masculine V?

In-game results (session 4)

From the creator on 28 September 2026 (game 2.31, the test profile, feminine V; experiment 029) runtime:

• Visible choice counts match the resources, not the wiki. With Off counted: eye makeup 37, lip styles 38 per finish, cheeks 25, face cyberware 17, facial tattoos 16, piercings 15, teeth 5. That is the resources' 36/38/24/16/15 plus Off. The wiki cheat sheet's 20/20/14/8/11 is outdated. With the installed packs: eyebrows 70, hairstyles 283 (285 cyberware variants), eye colours 254. Cheek choice 1 is a freckle pattern, not a blush.
• Link propagation. With skin_color 3, switching skin_type 1 → 5 keeps tone 3, and the body keeps its colour within 3 % (upper chest; the creator's swatch is identical). The creator's framing doesn't show the hands, so they are unchecked.
• Lip finish tree. makeupLips_type is 0 Off, 1 Default, 2 Glossy, 3 Matte. The style position carries across finishes: style 8 stayed at 8 through Default → Glossy → Matte → Off → Glossy, each finish's own style row taking the position. Colour carry-over is untested: the colour row can't be set from the lips page (the bridge answered that makeupLips_08 "can't be changed on this screen").
• Linked hairstyle. Hairstyle 5 (label 06); face cyberware 1 switches the row to hairstyle_cyberware at the same index 5 (label 06), and the hair looks the same. Cyberware 2–4 don't switch the row. So the Studio's rule holds for this style. Whether position 5 is one of the 20 where the two lists differ wasn't checked, so the test doesn't yet tell "same options" from "same position" (§2, switcher link members).
• Hairstyle switcher order. The row's index follows the option list's order, installed packs included: 90 Grace Bob V4, 96 Kala Messy Pixie, 100 Viessa Bun, 217 Valby Curtain Bob, 220 Viv Loose Waves; the reference V's 142 is "LONG PAK - #011" (lm097_hair).
• Piercing colour order (the same for each style): 0 silver, 1 gold, 2 pearl, 3 copper, 4 red, 5 pink, 6 black, 7 blue, 8 mixed, 9 mixed 2, 10 neon teal, 11 pink metallic, 12 rainbow, 13 rose gold, 14 steel, 15 wood.
• Teeth choices 0–4: base, silver, gold, copper (labelled "cooper") and pink.

In-game results (sessions 5 and 6)

From the creator opened by the XF bridge on 29 September 2026 (game 2.31, the test profile, feminine V; experiment 032) runtime:

• The creator opens anywhere through the pause menu, and the game decides the edit context. Opened from the street or a megabuilding corridor, away from any mirror, by switching the pause menu's scenario to the mirror's (Character Customization Anywhere's route, with CCA itself disabled), the creator was fully drawn and editable. Asked for the mirror's HairDresser tag or for NewGame, the menu reported NewGame both times and listed the same 860 editable options of 1,209, skin tone, skin type and face shape included, which HairDresser doesn't allow. So editTags filtering (§2) follows the menu's own mode, and this route always gets the new-game set (runtime access §5).
• The lip colour row is per finish and style. With the glossy finish and style 8 chosen, the colour row in use is makeupLips_glossy_08 (14 colours), in the slot makeupLips_color; makeupLips_08 isn't in use and can't be set. Setting the slot changed the colour (red → violet). Session 4's refusal came from naming a row not in use (experiment 029 guessed makeupLips_09); the colour carry-over across finishes (ask 2) can now run through the slot.
• Hairstyle labels resolve to the same indices as session 4: 217 VALBY CURTAIN BOB, 142 LONG PAK - #011.

In-game test asks

Each is a small check for one prepared session; record game, ArchiveXL, TweakXL and Codeware versions and whether Phantom Liberty is installed. Asks 1, 2, 9 and 11 ran in session 4 (above); what remains of them is noted in each.

1. Link propagation (hands still open). In the creator, pick skin tone 3, then switch skin type 1 → 5 and toggle face tattoo 6. Do skin type, tattoo, neck and hands all keep tone 3? Session 4 confirmed the body; the hands need a framing that shows them.
2. Lip finish tree (colour still open). Choose lipstick style 8 colour 6, then switch finish regular → glossy → matte → none → glossy. Session 4 showed that the style position carries; set the colour through the slot makeupLips_color (the row in use is the finish's own, e.g. makeupLips_glossy_08; sessions 5 and 6, above) to test whether it carries too.
3. Save representation. Save once with a vanilla-only look (no CCXL), change only eye makeup colour at a mirror, save again. Hand both saves over for diffing: we expect exactly the face and character_customization entries to change.
4. Mirror reconstruction. Load a save, open the mirror and confirm every slider shows the saved choice (not index 0). This tests whether option state is rebuilt from the save.
5. Missing-mod behaviour. With a throwaway save using one CCXL eye colour, disable that mod, load, note what the eyes show, open the mirror, then re-enable and load the original save. (Do not overwrite the original.)
6. Photo mode. In photo mode, check that makeup, piercings and brows match TPP. This tests the TPP_photomode versus face group split.
7. PRC as vanilla option 12. With the PRC framework and its two enabled item packs, choose Piercings 12 silver, then gold. Expected: the vanilla style-12 piece plus the nose stud and both nose rings appear together and all change colour together (the stud's small second part stays silver). Then move the nose slider: the rings should follow. This confirms archive precedence, the zero-chunk placeholders and the shared meshAppearance in one look.
8. EP1 eye-makeup colour carry-over. Choose eye makeup style 5 with colour teal, then switch to style 25. Does teal carry over? The EP1 CCO gives styles 21–36 a different link key, so we expect it may not.
9. Visible choice counts. Answered in session 4: the creator shows the resources' counts plus Off (above).
10. Creator rows. On the body page of a new game, list every row in order (feminine and masculine), and note whether any unlabelled row appears. The Studio's catalogue expects the options' index order and no rows for link followers.
11. Linked hairstyle switchers (one style checked). In the creator, pick hairstyle 5 without face cyberware, then choose a face cyberware that swaps the hairstyle row to the cyberware variant. Is it still the same hair (the Studio expects the style that turns on the same hair option), or the style at the same position? Screenshot both. Session 4 checked style 5 (same hair, same position); repeat with a style at a position where the two lists differ.
12. Makeup Off on a legacy build. On the reference character (wearing an older XF Eye Artistry build), set each of its layer rows and the vanilla lipstick and blush rows to Off at a mirror. Does nothing of them remain drawn? The Studio's Hide my V's own makeup does exactly this.
13. Multi-part hair. With the Multicolored Hair Core and an MCH hairstyle, set the vanilla hairstyle to 51 and give two parts different colours. Are both drawn with their own colour, and does the MultiColor Hair Off row show a colour grid? Then put on a beanie and note what hair shows under it (hair colour study checklist items 6, 14 and 15).

Related pages

Head CC rendering · Mod loading · Resolver validation · Materials and shaders · Wiki file-chain map · CCXL merge boundary · Catalogue probe · Source resolution · Save import · CC controls and presets backlog · Body rendering · Worn clothing · Piercings and jewellery · Archive and resource formats · Vortex