[ChronosWS]

Type of change

• Bug fix
• New feature
• Breaking change
• Refactor / code cleanup
• Performance improvement
• Chore / tooling
• Documentation

Overview

This PR adds a resource management system ported from Vanilla, which provides a consistent, centralized mechanism for registering resource providers and retrieving resources by logical ID. It is intended to support all Pomme's current resource usage, including resource packs, themes, version overlays and dynamic resource reloading. In addition it supports known resource sources such as directories, jars, zips and Bedrock formats. This PR does not fundamentally alter how specific asset types are processed - resources provide bytes, not an interpretation nor a general management of loaded and interpreted assets.

This PR is intended as a foundation for further resource-based features and fixups, and was specifically motivated by the desire to implement the particle system facilities expressible in Vanilla, which rely on asset definitions derived from resource packs.

Overall structure

resources/managers - The resource management API typically used by consumers, which applies priority and filtering
resources/packs - Logical packs of resources, including their metadata and suppliers
resources/pack_resources - The implementations which provide access to the physical resource streams from the resource packs

Usage

At a high level, we will use the following sequence of steps to register, load and access resources:

• At app start, we create the RepositorySources which provide the universe of Packs from which we can compose the set of packs we will use, which ultimately determines which resources are available.
• The RepositorySources are collected into a PackRepository, where packs can be enabled and disabled.
• PackRepository delivered the "opened" packages, which represents all of the enabled packs
• The ReloadableResourceManager, which implements ResourceManager is initialized with this opened set.
• Internally the MultiPackResourceManager handles the filtering and prioritization through the FallbackResourceManager, which is applied per-namespace.
• Resources can then be queried through the ResourceManager trait by their stable ResourceId, which delegates from Reloadable to MultiPack and eventually into Fallback to get the Resource from the source pack.
• From a Resource one can get the ResourceContent
• From a ResourceContent, a consumer can acquire the underlying byte stream, from which they load the associated asset (using existing mechanisms)

Future Work

Besides the migration, there will be additional work to better support asynchronous reloads and possibly performance improvements.

Follow up migration

There is a follow up PR #785 which will be the actual migration of consumers to use this system.

The remainder of this description is AI-generated reference and validation documentation - however the entire PR was hand-reviewed by me before being posted here.

Reference

Static comparison of all 21 changed files against 22 Java source files in the local Vanilla 26.3 decompilation (reference/26.3/decompiled):

• Lookup priority, resource stacks, filters, sidecars and reload boundaries: net.minecraft.server.packs.resources — MultiPackResourceManager, FallbackResourceManager, Resource, IoSupplier, ResourceFilterSection, ReloadableResourceManager, ResourceManagerReloadListener.
• Pack metadata, overlays, storage and supplier lifetimes: net.minecraft.server.packs — AbstractPackMetadataResources, PathPackResources, FilePackResources, OverlayedPackResources, OverlayMetadataSection, VanillaPackResources, VanillaPackResourcesBuilder, FixedPathPackResources.
• Format bounds and overlay compatibility: net.minecraft.server.packs.metadata.pack.PackFormat (including IntermediaryFormat), net.minecraft.server.packs.metadata.pack.PackMetadataSection; net.minecraft.util.InclusiveRange and net.minecraft.util.ExtraCodecs.
• Indexed asset layout, logical IDs and filter predicates: net.minecraft.client.resources.IndexedAssetSource, net.minecraft.resources.Identifier, net.minecraft.util.IdentifierPattern.

This is not a line-for-line port or a claim of full Vanilla equivalence. Intentional differences include raw uncached sidecars, synchronous caller-owned reload, case-preserving generic IDs, Rust regex rather than full Java Pattern compatibility, and provider-specific ownership/error behavior. Bedrock support here is a directory theme adapter with panorama aliases and raw byte access, not a general Bedrock manifest/format decoder.

Testing and validation

Current scope: The foundation uses PackResources backends, PackRepository and repository sources, and the fallback/multi-pack/reloadable manager hierarchy. Application initialization activates this resource view. Two demonstration consumers use it: menu splash text and the PNG shared by credits and the graphical loading logo. Other consumers and the resource-pack selection UI remain on the legacy asset stack; their migration is outside this PR's scope.

• PASS — local validation on 2026-11-01 at dbf6c101a8226d20e3bc3df5eb649fb50df9a24b: just client-pre-pr, run after sourcing /home/cliffh/dev/vulkan/1.4.363.0/setup-env.sh --set-dep-ld, completed with exit 0. Formatting and all five strict release Clippy checks across client, supporting crates and singleplayer passed.
• Tests: 1,602 passed, 0 failed, 1 skipped. The prescribed Nextest suites passed: supporting crates 170; client with --no-default-features 1,430, with 1 skipped; singleplayer with --run-ignored all 2, including world_settings_reach_the_steel_config and opens_two_worlds_in_one_process.
• All 211 resource API tests passed, covering basic black-box behavior through public traits and Vanilla-compatible pack/repository methods, including regression coverage for ZIP empty-directory listing.
• Limitations: A standalone release build, manual/app smoke verification, app launch and the in-game harness were not performed for this revision. The automated singleplayer world tests above did run.
• These are local results, not GitHub CI or cross-platform results. CI was not queried.

[Purdze]

thanks for this, the directions good and the lookup logicis good too but a few things need changing

• nothing uses it yet and there aren't any tests, so it's hard to know it works. could you split it into a stack? first layer: the manager + dir/index sources, some tests, and one real consumer moved over (lang or sounds.json). then build up from there
  ▎ - could you port vanilla's classes (PackResources, FallbackResourceManager, MultiPackResourceManager etc.) more directly instead of a new design? way easier to review
  ▎ - no need to read client.jar as a zip, we already extract it to versions//extracted/assets, so that can just be a dir source. drops most of the zip code + self_cell
  ▎ - the path canonicalizing on every lookup will be slow on windows, vanilla just resolves and opens

[ChronosWS]

Migrating the code to be much closer to the Vanilla structure and contracts.