All files re9: tracking every Resident Evil Requiem asset

All files re9: a producer’s guide to tracking every Resident Evil Requiem asset

A production team that cannot answer “where is that file” in under a minute is paying interest on every other decision it makes. On a Resident Evil Requiem build, the volume of geometry, textures, cinematics, audio, localisation, and configuration data grows faster than any single discipline can track informally. The phrase “all files re9” has therefore become shorthand inside studios for a working inventory of every shipped and in-flight asset, organised so leads, engineers, and QA can locate, validate, and rebuild any subsystem on demand. This guide explains what that inventory looks like, who owns it, and how to keep it honest from pre-production through the final cert build.

What “all files re9” actually means in a production context

There is no single canonical file. “All files re9” is a working label that a producer attaches to a deliverable, a script, or a spreadsheet that enumerates every meaningful file associated with the build. The label can refer to a Perforce or Git LFS branch snapshot, a frozen nightly build manifest, an Excel inventory of art sources, or a generated text file emitted by a build script. The unifying idea is that, at any chosen moment, the team can point at the manifest and prove that a named subsystem (for example, “subway interior lighting”) consists of an exact list of source files, processed assets, configuration entries, and runtime checksums.

The discipline matters because Resident Evil Requiem, like other modern RE Engine titles, derives much of its runtime content from a layered pipeline. Source assets are imported, processed into engine-native formats, and then packed into archive files. If the inventory does not list both the source and the packed output, the team will eventually lose the ability to rebuild, repatch, or license a single prop without rerunning an entire content sweep. The inventory is the contract that makes localisation, DLC, and platform variants tractable.

Who owns the all files re9 inventory

Ownership is a producer responsibility by default, but the work is shared. A workable distribution on a Resident Evil Requiem-sized project looks like this:

Producer: holds the master manifest, reconciles drift between subsystems, and gates every freeze.
Lead technical artist: maintains the art branch, including meshes, materials, and VFX sources.
Audio lead: maintains the audio branch, including stems, VO takes, and middleware banks.
Tools programmer: maintains the build scripts and the manifest generation tooling.
QA lead: cross-references the manifest against test plans and certification evidence.
Release manager: holds the per-platform variants and cert builds.

Owning the manifest does not mean hand-editing it. The best implementations generate the manifest from a build script and require humans only to resolve exceptions. The producer’s role is to decide which exceptions are tolerable and to keep the manifest readable to leads outside their own discipline.

Folder and naming conventions the manifest enforces

A consistent folder map is the single most effective defence against drift. Resident Evil Requiem studios typically adopt a layout that mirrors the engine’s data layers rather than a studio-specific marketing structure. The map below is a working example, not an official Capcom layout, and should be adapted to each studio’s source control topology.

Top-level folder	Purpose	Typical owner	Manifest entry
/Source/Art/	Maya, Blender, ZBrush, Substance source files	Lead technical artist	One row per source scene with version and approval state
/Source/Audio/	Stems, VO, ambisonic beds, middleware projects	Audio lead	One row per stem and per VO line ID
/Source/Design/	Script sources, level layouts, quest graphs	Lead designer	One row per level with dependency list
/Engine/Configs/	Project settings, platform profiles, cert overrides	Tools programmer	One row per config file with last review date
/Engine/Content/	Cooked archives, packaged builds, packed textures	Tools programmer	One row per cooked archive with hash
/Engine/Localisation/	String tables, dub sheets, font fallbacks	Localisation producer	One row per locale with completeness percentage
/QA/Evidence/	Test plans, repro captures, cert artefacts	QA lead	One row per test case with evidence path

Naming rules belong alongside the folder map. A workable convention treats the asset name as a small address: project, subsystem, variant, version, and approval state. The full string is parseable by a build script, which is what allows the manifest to be generated rather than curated by hand. A short example for a Resident Evil Requiem prop might read REQ_SUB_INTERIOR_LAMP_A_v017_APV, where the leading token identifies the project and the trailing token records the approval state. The exact tokens are less important than the discipline that the same scheme is applied to every file the manifest tracks.

What the manifest must contain for each entry

A row in the all files re9 manifest is only useful if it answers the questions every lead will eventually ask. The schema below is a working minimum; larger projects add columns rather than redefine rows.

Field	Meaning	Why it is required
Asset ID	Stable identifier for the asset	Survives renames and folder moves
Display name	Human-readable name	For lead review and bug reports
Source path	Path to the editable source	Lets artists reopen and edit
Cooked path	Path to the packed runtime output	Lets engineers reason about the build
Hash	SHA-256 of the cooked output	Detects silent corruption or repacks
Owner	Discipline lead responsible	Routes review requests
Approval state	WIP, IP review, code review, approved, locked	Defines what freezes block
Platform variants	PC, PS5, Xbox Series, Switch 2 as applicable	Prevents forgetting a per-platform override
Dependencies	Other asset IDs this entry reads	Makes impact analysis possible
Last touched	Timestamp of last write	Detects stale assets
Notes	Free-form context	Carries rationale across handoffs

The combination of hash, approval state, and dependency list is what makes the manifest a control surface rather than a list. A producer can grep the manifest for any keyword and immediately see which subsystem is responsible, which other assets are at risk, and which platform variants exist.

Generating the manifest from build scripts

Hand-maintained manifests drift within a week on any active project. The reliable approach is to make the build script emit the manifest as a build artefact. For a Resident Evil Requiem build on RE Engine, that typically means a Python or Lua script that walks the project root, identifies source files by extension, and pairs each source with its cooked output through the engine’s known mapping. The script writes a JSON or CSV file and checks it into a manifest branch.

A reasonable shape for the generation step looks like this:

Walk the project root and record every source file in /Source with its path, size, and mtime.
Walk /Engine/Content and record every packed archive with its archive name, size, and SHA-256.
For each packed archive, query the engine’s table of contents to recover the list of asset IDs it contains.
Join source and cooked rows on the asset ID and emit a row per asset.
Cross-reference the engine’s local config and inject one row per config file with last review date.
Append QA evidence rows by reading the test plan repository.
Diff the new manifest against the previous one and fail the build if any locked asset changed without an approval transition.

Step seven is the discipline that turns the manifest from a record into a gate. If a level designer mutates a locked asset, the build fails and the producer receives a clear report. If a build script accidentally re-cooks an archive, the hash check catches the change and the diff flags it for review.

Freezes, variants, and the cert build

Resident Evil Requiem ships on multiple platforms, each of which goes through a separate certification process. The manifest must therefore support variants. A clean implementation records one row per (asset, platform) pair, with a shared asset ID and a platform-specific hash. This lets the producer reason about the project as a single graph while still distinguishing, for example, the Switch 2 variant of a texture with reduced mip count.

The freeze schedule typically proceeds in three layers. The first freeze is a feature freeze that locks gameplay and design sources. The second is a content freeze that locks art, audio, and localisation sources. The third is a code freeze that locks engine configs and cert overrides. At each freeze the manifest is re-emitted, diffed against the previous freeze, and signed by the discipline leads. The signed manifest becomes the contract for the next phase.

For cert, the manifest is paired with a separate cert manifest that records, per platform, the exact hashes of the build submitted to the platform holder. If a cert submission is rejected, the cert manifest is the starting point for the resubmission, and the regular manifest is the starting point for the fix. Keeping the two separated avoids a common failure mode in which cert rebuilds accidentally pull in a newer source that the platform holder has not seen.

Drift, stale assets, and how the manifest catches them

Drift happens when an asset in the manifest no longer reflects the source. A texture may be re-exported with a different compression, a level may be re-imported with a different pivot, or a VO take may be re-recorded without updating the dub sheet. The manifest catches drift in two complementary ways: hash comparison and dependency validation.

Hash comparison treats the cooked output as ground truth. If a source is updated but the cooked output is not rebuilt, the build script notices the mtime change and fails the build. If the cooked output is rebuilt but the manifest is not regenerated, the hash diff in the next build surfaces the silent change. Either way, drift becomes visible rather than accumulating.

Dependency validation is the second line of defence. When an asset’s source path is renamed, the manifest’s dependency list is the only authoritative record of where the asset is referenced. A producer can grep for the old name and find every dependent level, config, and audio cue, then route the rename through the build script. Without the dependency list, the rename would have to be chased by hand through every discipline.

Localised assets and the dub sheet as a manifest view

Localisation is a common source of manifest failure because the volume of files scales with the number of supported languages. Resident Evil Requiem ships in dozens of locales, and each locale adds string tables, font fallbacks, VO takes, and dubbed audio beds. A workable approach is to treat the dub sheet as a manifest view rather than a separate document. The sheet records, per line, the source language, the target language, the studio that produced the take, the audio file path, and the manifest row it corresponds to.

When a localisation producer reports a missing line, the manifest is the first place to look. If the line is present in the source string table but missing from the dub sheet, the gap is in localisation. If the line is present in the dub sheet but missing from the cooked archive, the gap is in the build pipeline. The manifest is what allows the producer to direct the right team to the right gap without escalating.

Audio, VFX, and the special case of generative content

Audio and VFX often use procedural sources that do not map cleanly to a single file. A particle system may reference a base texture, a turbulence map, a sub-UV sheet, and a runtime configuration. A reverb bed may combine a base impulse response with a runtime convolution. In both cases, the manifest must list the runtime configuration as a first-class entry, not as a hidden parameter on the texture.

A useful pattern is to require every procedural source to declare a manifest row for its configuration object. The configuration is a small JSON or YAML file checked into /Source/Design/Procedural/ and versioned like any other asset. The build script pairs each procedural source with its configuration and emits two manifest rows. When the configuration changes, both rows are diffed and the dependent VFX is rebuilt.

How QA uses the manifest for regression and cert

Resident Evil Requiem is a survival horror title from Capcom, built on the company’s internal RE Engine. A complete overview of the project, its place in the franchise, and the development approach is available on the Resident Evil Requiem Wikipedia article, which the rest of this article will treat as the authoritative reference for naming, scope, and franchise context. The focus here is narrower: how a studio turns the public knowledge of the title into a disciplined internal asset ledger that survives contact with patch cycles, platform variants, and certification.

QA’s value of the manifest is regression coverage. A test case that references a missing asset ID is a test that cannot run; a test case that references a stale asset ID is a test that gives the wrong result. The QA lead maintains a test plan repository that records, per test case, the asset IDs it touches. The manifest cross-reference becomes the regression matrix.

For certification, the manifest is the source of truth for what was tested. If a platform holder asks for evidence that a specific subsystem was reviewed, the cert manifest points to the test case, the test case points to the assets, and the assets point to the source files. The chain is short enough that the producer can answer a cert question in minutes rather than days.

A short worked example: tracking a Resident Evil Requiem prop

Imagine a single prop, a wall-mounted fluorescent fixture, that appears in several Resident Evil Requiem levels. The art source lives in /Source/Art/Props/LampWall/, the cooked mesh and texture live in /Engine/Content/Props/, and the level references the asset through a placed actor. The manifest rows for this prop look like this:

Field	Source row	Cooked row
Asset ID	REQ_PROP_LAMPWALL_A	REQ_PROP_LAMPWALL_A
Source path	/Source/Art/Props/LampWall/LampWall_A.ma	(n/a)
Cooked path	(n/a)	/Engine/Content/Props/REQ_PROP_LAMPWALL_A.meshex
Hash	(mtime based)	SHA-256 emitted by the cooker
Dependencies	REQ_TEX_LAMPWALL_DIFF, REQ_TEX_LAMPWALL_NRM, REQ_LIGHT_PROFILE_FLORA	Same
Platform variants	PC, PS5, Xbox Series, Switch 2	PC, PS5, Xbox Series, Switch 2 (with reduced LODs)
Approval state	Approved	Locked

If a level designer reports a lighting bug, the QA lead pulls up the manifest, finds the asset ID, sees the dependency on REQ_LIGHT_PROFILE_FLORA, and routes the report to the lighting team. The lighting team opens the light profile, fixes the parameter, rebuilds, and the manifest’s hash diff surfaces the change. The producer approves the change at the next freeze. The cycle takes hours rather than days because the manifest removed the search step.

Common failure modes and how the manifest prevents them

Even with a sound folder map and a disciplined build script, the all files re9 inventory can still fail. The most common failure modes are predictable, and the manifest is the right place to defend against each.

Stale caches: a build script may reuse a cooked output from a previous run. The hash check in the manifest catches this on the next regeneration.
Orphaned sources: a source file may be deleted but its cooked output retained. The dependency walk in the manifest surfaces the orphan and the producer decides whether to remove the cooked output.
Missing dependencies: a level may reference an asset that has been renamed. The manifest’s cross-reference list is the only authoritative way to find every dependent level without grepping the engine source.
Platform drift: a Switch 2 variant may lag behind the PC variant. The manifest’s per-platform hash column exposes the gap at any freeze.
Localisation drift: a locale may fall behind a content freeze. The manifest’s locale completeness column flags the lag and the localisation producer routes resources accordingly.
Cert overbuilds: a cert rebuild may pull in a newer source. The cert manifest’s signed hash prevents the pull by construction.

Tooling choices and the cost of custom scripts

Most studios start with a spreadsheet and graduate to a build script. The intermediate step is a small Python or Lua script that reads the engine’s table of contents and emits a CSV. The final step is a CI job that runs the script on every merge to the main branch and uploads the diff to a shared location. None of this requires custom engine code; it requires discipline.

For a Resident Evil Requiem build, the most useful investments are usually a manifest diff viewer, a dependency graph visualiser, and a freeze sign-off page. The viewer is a small web app that lets leads see what changed between freezes and approve the diff. The visualiser turns the manifest’s dependency list into a graph that makes impact analysis legible. The sign-off page replaces email threads with a clear record of who approved what. Together they convert the manifest from a static document into a working control surface.

Working with the RE Engine’s own content tools

RE Engine exposes a content pipeline that pairs editable sources with packed archives. The all files re9 inventory is not a replacement for that pipeline; it is a layer above it. The pipeline decides how an asset becomes a packed archive, and the inventory records the relationship between the source and the archive. When the two are kept in sync, the team gains the ability to reason about content at any level of abstraction.

Useful points to keep in mind when working with RE Engine’s tooling:

The engine’s table of contents is the canonical map from archive to asset ID. The build script should query it directly rather than parsing file names.
Cooked archives carry their own hash. The manifest should record the engine’s hash, not a recomputed one, to keep the values comparable across machines.
Source control branches per platform are common on Resident Evil Requiem projects. The manifest should be emitted per branch and diffed across branches to keep platform drift visible.
Localised builds add a layer of archives. The manifest should record one row per (asset, locale, platform) tuple to keep the freeze schedule manageable.

What to look for in a tool or service that promises “all files” coverage

External tools and services that promise all files coverage for a project like Resident Evil Requiem should be evaluated on a small set of concrete criteria. A useful checklist for a producer reviewing a proposal is below.

Does the tool read the engine’s table of contents directly, or does it parse file names? The first is correct, the second is fragile.
Does the tool record hashes for the cooked output, or only the source? The first is required for drift detection.
Does the tool record dependencies, or only leaf files? Without dependencies, impact analysis is impossible.
Does the tool support per-platform variants, or only a single project view? Multi-platform delivery requires per-platform rows.
Does the tool support a diff between freezes, or only a current state? The diff is the control surface, not the current state.
Does the tool support a cert manifest separate from the regular manifest? Cert rebuilds must not silently pull in newer sources.
Does the tool support sign-off and audit, or only a shared document? Sign-off is what makes the manifest enforceable.

A tool that meets all seven criteria is a credible platform for the all files re9 inventory. A tool that meets fewer than five is at best a viewer and at worst a source of drift in its own right.

How the manifest supports live operations after launch

Resident Evil Requiem, like other modern survival horror releases, is likely to receive post-launch patches, balance adjustments, and possibly DLC. The manifest continues to be useful after launch because each patch is, in effect, a small freeze. The patch manifest records exactly which sources were touched, which cooked archives were rebuilt, and which platform variants were resubmitted. If a patch introduces a regression, the manifest is the starting point for the rollback analysis.

For DLC, the manifest is the starting point for the new content. A DLC subsystem is added as a new top-level folder, the manifest is regenerated, and the new rows are diffed against the base game rows to confirm that no base assets were modified. The discipline is the same as for the main project; only the scope is smaller.

Working with external partners and outsourcers

Resident Evil Requiem projects typically involve external partners for art, audio, and localisation. The manifest is the contract that defines what a partner owes and when. A partner receives a deliverable specification that lists the required asset IDs, the source path conventions, the approval states, and the file formats. The partner returns a manifest fragment that lists the assets they produced, their hashes, and their dependencies. The producer’s build script merges the fragment into the master manifest and the partner’s work becomes a first-class part of the build.

The benefit is that the producer can reason about a partner’s contribution without needing to inspect the partner’s source. The manifest fragment is the interface. If the partner’s fragment is incomplete, the merge step fails and the producer receives a clear report. If the partner’s fragment is complete but the assets are low quality, the approval state column carries the warning forward to the review stage.

How the manifest interacts with engine hot-reload and iteration

Developers iterating on Resident Evil Requiem content want fast feedback. A common temptation is to bypass the manifest during iteration and rely on the engine’s hot-reload. The discipline to preserve is that the iteration cycle ends at the manifest, not at the engine. After a meaningful change, the build script regenerates the manifest and the diff is reviewed. Without that step, the iteration cycle quietly produces drift that the next freeze will surface as a surprise.

A workable compromise is to run a lightweight manifest pass on every iteration and a full manifest pass at every freeze. The lightweight pass records the changed sources and their hashes; the full pass records the full project. The lightweight pass is fast enough to run inside the iteration loop; the full pass is the contract.

A pragmatic implementation plan for a new Resident Evil Requiem build

A team adopting the all files re9 discipline for the first time on a Resident Evil Requiem build can follow a short, practical sequence. The plan is deliberately small at the start; it grows with the project rather than being imposed at scale.

Adopt a folder map and a naming convention in the first week of pre-production.
Write a build script that emits a CSV manifest for a single subsystem, for example the art branch.
Add hash recording to the script in week two.
Add dependency recording in week three.
Add per-platform rows in week four, once the platform list is firm.
Add a diff viewer that compares the current manifest with the previous freeze.
Add a sign-off page that records who approved each freeze.
Add a cert manifest separate from the regular manifest once certification is in sight.
Add a partner fragment merge step when the first external partner delivers content.

The plan takes a few weeks of producer time and pays for itself the first time the team has to answer a cert question or roll back a patch. After that, the manifest becomes the spine of the project and the team’s confidence in its own content grows in proportion to the manifest’s accuracy.

What changes when the project grows

As Resident Evil Requiem grows, the manifest grows with it. The schema stays the same; the volume of rows increases, the dependency graph becomes denser, and the freeze schedule becomes stricter. The discipline that does not change is that the manifest is generated, signed, and diffed rather than curated by hand. Curated manifests decay under load; generated manifests stay accurate because their source of truth is the project itself.

Large projects also benefit from a manifest owner who is not a producer. A dedicated manifest engineer, usually a tools programmer, can keep the script healthy while the producers focus on content. The role is small at the start and grows with the project. The cost of the role is recovered many times over the first time the team has to trace a regression to a single source file in a single subsystem.

Closing note for producers and leads

The all files re9 inventory is a control surface, not a document. Its value is not in the rows it contains but in the questions it answers in seconds rather than days. Producers who adopt the discipline early find that the late stages of a Resident Evil Requiem build, the freezes, the cert, the live operations, are calmer and more predictable because the manifest removed the search step from every decision. Teams that adopt the discipline late find that the manifest surfaces a backlog of drift that has to be paid down before the next freeze. Either way, the discipline is the same: generate, sign, diff, and keep the source of truth in the build script rather than in a spreadsheet.

Frequently asked questions

What does “all files re9” actually refer to?

It is a working label for a complete inventory of every asset, source, config, and packed archive associated with a Resident Evil Requiem build. The label is internal to the studio and may refer to a spreadsheet, a build script output, or a versioned JSON manifest. The unifying idea is that the inventory is generated, signed, and diffed rather than curated by hand.

Who owns the all files re9 manifest on a Resident Evil Requiem project?

The producer owns the master manifest by default, but the work is shared. Lead technical artists, audio leads, tools programmers, QA leads, and release managers each maintain the rows that fall under their discipline. The producer reconciles drift and gates every freeze.

How is the manifest generated?

A build script walks the project root, identifies source files by extension and packed archives by the engine’s table of contents, joins the two on the asset ID, and emits a row per asset with a hash, dependencies, and approval state. The script runs on every merge and at every freeze, and the diff is reviewed before the build proceeds.

Why is hash recording important for Resident Evil Requiem assets?

Hash recording detects silent changes. If a build script accidentally re-cooks an archive, or a source is updated without a rebuild, the hash diff in the next manifest surfaces the change. Without hashes, drift accumulates until the next freeze and is paid down as a backlog.

How does the manifest support multi-platform delivery?

The manifest records one row per (asset, platform) pair with a shared asset ID and a per-platform hash. This lets the producer reason about the project as a single graph while still distinguishing, for example, the Switch 2 variant of a texture with a reduced mip count. Per-platform hashes are also what makes the cert manifest trustworthy.

What is the difference between the regular manifest and the cert manifest?

The regular manifest is the project’s working inventory. The cert manifest is a separate, signed record of the exact hashes of the build submitted to a platform holder. Keeping the two separated prevents a cert rebuild from silently pulling in a newer source that the platform holder has not seen.

How does the manifest help with post-launch patches?

Each patch is, in effect, a small freeze. The patch manifest records exactly which sources were touched, which cooked archives were rebuilt, and which platform variants were resubmitted. If a patch introduces a regression, the manifest is the starting point for rollback analysis.

Can external partners contribute to the manifest?

Yes. A partner receives a deliverable specification and returns a manifest fragment that lists the assets they produced, their hashes, and their dependencies. The producer’s build script merges the fragment into the master manifest, and the partner’s work becomes a first-class part of the build. The manifest fragment is the contract between the studio and the partner.

What is the smallest viable all files re9 setup?

A folder map, a naming convention, and a build script that emits a CSV manifest for a single subsystem. Hash recording and dependency recording are added in the following weeks, and a diff viewer and sign-off page are added once the first freeze approaches. The discipline grows with the project rather than being imposed at scale.

How does the manifest interact with engine hot-reload?

Iteration can rely on the engine’s hot-reload, but every meaningful change must end at the manifest. A lightweight pass records changed sources and their hashes during iteration; a full pass records the full project at every freeze. The discipline preserves the manifest’s accuracy without slowing the iteration loop.