fabric/fabric-model-loading-api-v1/build.gradle

version = getSubprojectVersion(project)

moduleDependencies(project, ['fabric-api-base'])

testDependencies(project, [
	':fabric-renderer-api-v1',
	':fabric-renderer-indigo',
	':fabric-rendering-v1',
	':fabric-resource-loader-v0'
])
Update Loom and Loader. Cleanup/improve buildscript. 2021-11-12 07:48:58 -05:00			`version = getSubprojectVersion(project)`
final module name refactor prior to release, hopefully 2019-05-11 17:48:33 -04:00
Setup unit tests & format gradle files. (#3073) 2023-05-30 08:07:11 -04:00			`moduleDependencies(project, ['fabric-api-base'])`
Allow getting BakedModels using Identifiers (#1390) 2021-04-18 09:06:02 -04:00
Split client only code into its own sourceset. (#2179) A common source of crashes on modded Minecraft servers comes from modders accidently calling client only code from the client, this PR is another large step towards elimitating that. This PR has been months in the making and years in the planning, requiring major changes to Loom & Loader. In recent Minecraft versions Mojang has made it easier than ever to cleanly split the jar, going against the status-quo of merging the client and server into one jar. From the start we have designed Fabric to have a very clear split between client and common (client & server) code. Fabric has always encoraged keeping client only code seprate from the server, this can be seen at a fundamental level with the entrypoints in Loader. Fabric API's have all been designed with this mind. This PR provides a compile safety net around Fabric API using client only code on the server. Even though there are almost 400 changed files, minimal changes beyond moving the files were required to achieve this in Fabric API, thanks to the effort of all contributors in the past. These changes should not affect modders or players in anyway, a single "universal" jar is still produced. Im happy to awnswer any questions. 2022-05-21 11:26:46 -04:00			`testDependencies(project, [`
Model Loading API v1 (#3145) This PR deprecates and supersedes the old `fabric-models-v0` module. ## Refactors compared to v0 ### Model loading hooks Mods now register a single `ModelLoadingPlugin` for any change they want to make to the model loading process. (Or multiple plugins if they want to). This replaces the old `ModelLoadingRegistry`. Here is an example: ```java ModelLoadingPlugin.register(pluginContext -> { // ResourceManager access is provided like in the v0 API, but in a central place, and can be used for shared processing in the plugin. ResourceManager manager = pluginContext.resourceManager(); // Model resource providers still exist, but they are called model resolvers now pluginContext.resolveModel().register(context -> { // ... }); }); ``` #### `ModelVariantProvider` -> `BlockStateResolver` `ModelVariantProvider` was heavily reworked, and is now replaced by the `BlockStateResolver`, with a much better defined contract. #### `ModelResourceProvider` -> `ModelResolver` The resource provider is mostly unchanged. The biggest difference is that it is now registered as an event listener. This allows mods to use event phases for ordering between conflicting ~~providers~~ resolvers. #### Removed custom exception Additionally, `ModelProviderException` could be thrown by a variant or resource provider in the v0 API. This was not explained in the documentation, and would according to the code stop further processing of the providers and log an error. In the new API, any `Exception` is caught and logged. If that happens, the other resolvers are still processed. There is no custom `Exception` subclass anymore. ### Helper method to get a `BakedModel` by `Identifier` from the manager The v0 had such a method in a helper class: `BakedModelManagerHelper#getBakedModel`. It is now interface-injected instead. See `FabricBakedModelManager`. ## New model wrapping hooks New hooks are added for the various needs of mods that want to override or wrap specific models. Thanks to @embeddedt for contributing an initial version of them! Here is an example of wrapping the gold model to remove the bottom quads, for example: ```java ModelLoadingPlugin.register(pluginContext -> { // remove bottom face of gold blocks pluginContext.modifyModelAfterBake().register(ModelModifier.WRAP_PHASE, (model, context) -> { if (context.identifier().getPath().equals("block/gold_block")) { return new DownQuadRemovingModel(model); } else { return model; } }); }); ``` There are 3 events, for the following use cases: - Wrapping `UnbakedModel`s right when they are loaded. This allows replacing them entirely in dependent models too. - Wrapping `UnbakedModel`s right before they are baked. This allows replacing them without affecting dependent models (which might not be expecting a model class change). - Wrapping `BakedModel`s right when they are baked. Multiple mods have implemented their own version of them. Providing them in Fabric API will make it easier on these mods, and will additionally allow optimization mods that perform on-demand model loading to simply fire the hooks themselves instead of working around injections performed by other mods. Co-authored-by: embeddedt <42941056+embeddedt@users.noreply.github.com> Co-authored-by: PepperCode1 <44146161+PepperCode1@users.noreply.github.com> Co-authored-by: Juuz <6596629+Juuxel@users.noreply.github.com> 2023-07-18 07:53:13 -04:00			`':fabric-renderer-api-v1',`
Port Model Loading API v1 to 1.21 (#3824) * Port Model Loading API v1 * Fix checkstyle and address review comments 2024-06-08 09:02:54 -04:00			`':fabric-renderer-indigo',`
Setup unit tests & format gradle files. (#3073) 2023-05-30 08:07:11 -04:00			`':fabric-rendering-v1',`
			`':fabric-resource-loader-v0'`
Split client only code into its own sourceset. (#2179) A common source of crashes on modded Minecraft servers comes from modders accidently calling client only code from the client, this PR is another large step towards elimitating that. This PR has been months in the making and years in the planning, requiring major changes to Loom & Loader. In recent Minecraft versions Mojang has made it easier than ever to cleanly split the jar, going against the status-quo of merging the client and server into one jar. From the start we have designed Fabric to have a very clear split between client and common (client & server) code. Fabric has always encoraged keeping client only code seprate from the server, this can be seen at a fundamental level with the entrypoints in Loader. Fabric API's have all been designed with this mind. This PR provides a compile safety net around Fabric API using client only code on the server. Even though there are almost 400 changed files, minimal changes beyond moving the files were required to achieve this in Fabric API, thanks to the effort of all contributors in the past. These changes should not affect modders or players in anyway, a single "universal" jar is still produced. Im happy to awnswer any questions. 2022-05-21 11:26:46 -04:00			`])`