Resource Loader v1

[Technici4n]

A much needed update to resource loader.

Resource Reload Events

• ClientResourceReloadEvents and ServerResourceReloadEvents are added to hold new events.
• START_RELOAD fires right before resource reloaders start running, and can for example be used to invalidate a cache before the resource reloader recomputes it.
• END_RELOAD fires right when the reload completes (successfully or with a failure).
• The exact place where the start event should be invoked is up for debate. Currently it is invoked after the resource reloaders are collected on the server side. Note that it's technically possible for END_RELOAD to fire without START_RELOAD having fired, if case something fails before START_RELOAD.
• REGISTER_RELOADERS: see below.

Resource Reloaders

• Resource reloader registration now happens in the REGISTER_RELOADERS events.
• They still have an ID, however the ID is passed alongside the resource reloader at registration time. (Previously getFabricId had to be overridden).
• Resource reloaders are instantiated once per reload on the server and stored inside DataPackContents; on the client they are instantiated once and then stored inside MinecraftClient.
• Resource reloaders can be accessed from the data pack contents, the client and the server thanks to interface injection of ResourceReloaderHolder.
• The event allows DataPackContents and MinecraftClient to be captured for cross-reloader talk during the apply phase.
• Arbitrary ordering of reloaders was implemented (will use the same backend as event phases). Previously it was not possible to order modded reloaders before vanilla's. This was added in a fully backwards-compatible way.
• Note 1: the client-side REGISTER_RELOADERS event only fires exactly once at the start of the game, but I figured it would still be nicer for consistency to have an event.
• Note 2: the v0 API is bridged via LegacyReloaderHolder because the new client event is client-only, whereas the old API was side agnostic (since it did not provide any context whatsoever).

Here is an example of using this new API for a client reloader. I am not fully convinced by this usage pattern yet:

ClientResourceReloadEvents.REGISTER_RELOADERS.register(context -> {
	context.addReloader(SpecificModelReloadListener.ID, new SpecificModelReloadListener());
	context.addReloaderOrdering(ResourceReloaderKeys.BAKED_MODELS, SpecificModelReloadListener.ID);
	context.addReloaderOrdering(SpecificModelReloadListener.ID, ResourceReloaderKeys.ENTITY_RENDER_DISPATCHER);
});

// Later on:
SpecificModelReloadListener myListener = (SpecificModelReloadListener) MinecraftClient.getInstance().getResourceReloader(SpecificModelReloadListener.ID);

For server reloaders however, this matches what vanilla does, and is much nicer than what the v0 API provides today.

Resource Packs

• Builtin packs: functionality is kept unchanged, however providing a display name is now required.
• Currently they are registered by calling ResourcePackHelper, perhaps a better name should be found?
• Add new events to directly register ResourcePack instances. See ResourcePackRegistrationEvents#afterMods(ResourceType) and afterAll(ResourceType).
• These events are side-agnostic. Should we provide more (side-dependent) context to them? I am not convinced that this would be necessary.
• These events provide a ResourceManager that allows inspecting the previous packs. This can be useful for virtual resource packs, among other things, however note that this API does not provide the virtual resource pack implementation itself.
• Add ResourcePackHelper#createModResourcePack to directly instantiate mod nio resource packs. This can be useful to access resources in a mod JAR outside of the normal resource loading lifecycle.

Further possibilities

• We could add an API to register custom ResourcePackProviders or ResourcePackProfiles. This can be left for a future PR imo. This would either be an event (maybe in ResourcePackRegistrationEvents), or a static registration in ResourcePackHelper.

TODO items

• Does v1 need to implement ModResourcePack on its builtin packs too?
• Possibly find a better name for ResourcePackHelper.
• Possibly eliminate the action type from ModNioResourcePack entirely. Or can also be left for a future PR.
• Add tests for ResourcePackRegistrationEvents
• Consider adding isFirst to the context of ResourcePackRegistrationEvents. I think it can be left for later, it's a bit annoying.
• Should we add ResourceReloaderKeys for all the vanilla reloaders? Many are missing on the client side.
• The old resource reloader API broke ties by registration order, whereas the new APIs break ties by identifier. This is a potential breaking changes for mods. However they were not correctly specifying dependencies as required by the API, so this might be acceptable. A workaround might be to break ties by registration order when using the legacy bridge, and by identifier when using the new API.
• Add javadoc note saying that END_RELOAD can technically fire even if START_RELOAD did not fire.

[apple502j]

All classes should have a javadoc, IMO.

[apple502j]

I think this gets cut at i.e. when in summary.

[apple502j]

I don't think "has been performed" is appropriate here, you can just use "occurs"

[apple502j]

Needs javadoc.

[apple502j]

Needs javadoc.

[apple502j]

Classes should have javadocs.

[apple502j]

Registers.

[apple502j]

Requests.

[apple502j]

Param javadoc should be lowercase, no period

[apple502j]

Extraneous line?

[dima-dencep]

@Technici4n any progress?

[Technici4n]

No, I don't think I will be finishing this.