FAPI 0.86.1 sync #111
Merged
FAPI 0.86.1 sync #111
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 <[email protected]>
Co-authored-by: PepperCode1 <[email protected]>
Co-authored-by: Juuz <[email protected]>
* Add API for adding custom dynamic registries Closes FabricMC#1012, supersedes FabricMC#1031 and FabricMC#2719. * Add missing license headers * Clarify RegistryLoaderMixin namespace injection * Replace event with static registration, add skeleton for sorting registries * Fix typo * Refactor event phase sorting system for use with dynamic registries (QuiltMC#1) * Make minor changes to Technici4n's PR * Add test for nested dynamic objects * Revert "Add test for nested dynamic objects" This reverts commit 486e3e1. * Revert "Make minor changes to Technici4n's PR" This reverts commit 741bd52. * Revert "Refactor event phase sorting system for use with dynamic registries (QuiltMC#1)" This reverts commit bb7c8b8. * Remove sorting API * Add support for defaulted dynamic registries * Re-add test for nested dynamic objects * Add missing license headers * Fix typo * Remove defaulted dynamic registries; flatten registration methods * Remove last reference to registry sorting * Add option to skip syncing for empty dynregs * Update DynamicRegistrySyncOption docs Co-authored-by: Technici4n <[email protected]> * Address review feedback * Add registry namespace to tag paths for modded registries * Move dynamic registry tests into their own class for readibility * Finish DynamicRegistries doc * Only apply tag change to dynamic registries * Fix checkstyle * Update fabric-registry-sync-v0/src/main/java/net/fabricmc/fabric/api/event/registry/DynamicRegistries.java Co-authored-by: Technici4n <[email protected]> --------- Co-authored-by: Technici4n <[email protected]>
…only) (FabricMC#3183) * Make event phase ordering logic usable in other contexts (internally only) * Rename and move to toposort package
* Fix crash when beehive is broken by fake player When a beehive is broken, every nearby bee targets a random player. However, if there are no nearby players, the game crashes. This should not occur under normal (vanilla) conditions. However, if a beehive is broken by a fake player there are no players in range, and so we see a crash. * Checkstyle, my beloved * Remove public modifier * See see see
* Fix Indigo handling of sculk sensor AO. Fixes FabricMC#3153 * Split offset and mean formula lighting config options
* Some more TAWs Added some TAWs for various methods in `Blocks` used to create certain types of blocks that mods may want to also create. Using these methods will allow them to ensure they have all the right block settings they need to stay consistent with vanilla blocks that use the same methods. * Add some fields from BlockLootTableGenerator useful fields from BlockLootTableGenerator. also cleaned up the datagen api's accesswidener file
* Add files via upload * Add files via upload
* A few transfer API improvements and deprecations * Forward implementation of deprecated methods
…eam-compat # Conflicts: # deprecated/fabric-models-v0/src/client/resources/assets/quilted_fabric_models_v0/icon.png # deprecated/fabric-models-v0/src/client/resources/fabric.mod.json # deprecated/fabric-models-v0/src/client/resources/quilt.mod.json # deprecated/fabric-models-v0/src/client/resources/quilted_fabric_models_v0.mixins.json # fabric-api-base/src/main/java/net/fabricmc/fabric/impl/base/event/PhaseSorting.java # fabric-model-loading-api-v1/build.gradle # fabric-model-loading-api-v1/src/client/resources/assets/fabric-model-loading-api-v1/icon.png # fabric-models-v0/src/client/java/net/fabricmc/fabric/impl/client/model/ModelLoadingRegistryImpl.java # fabric-models-v0/src/client/java/net/fabricmc/fabric/mixin/client/model/ModelLoaderMixin.java # fabric-models-v0/src/testmodClient/java/net/fabricmc/fabric/test/model/BakedModelRenderer.java # fabric-models-v0/src/testmodClient/java/net/fabricmc/fabric/test/model/ModelTestModClient.java # fabric-registry-sync-v0/src/main/java/net/fabricmc/fabric/mixin/registry/sync/RegistryLoaderMixin.java # fabric-registry-sync-v0/src/main/resources/fabric-registry-sync-v0.accesswidener # fabric-registry-sync-v0/src/main/resources/quilted_fabric_registry_sync_v0.mixins.json # fabric-renderer-api-v1/src/testmodClient/java/net/fabricmc/fabric/test/renderer/simple/client/FrameModelResourceProvider.java # fabric-renderer-api-v1/src/testmodClient/java/net/fabricmc/fabric/test/renderer/simple/client/PillarModelVariantProvider.java # fabric-resource-loader-v0/src/main/resources/assets/quilted_fabric_resource_loader_v0/lang/uk_ua.json # gradle.properties
Redid process of setting up QMJ and mixins.json for model_loading_v1, fixed registry sync access wideners First area of focus is going to be the new fapi dyn. registries, as they will likely require the most substantial work.
…ng the old Model API (v0). Basically a drag-and-drop addition.
…required, and in fact would potentially cause a breakage with QSL behavior. - Also began work on smaller compat changes, such as the FakePlayerTests gametest entry for fake player hive breakage.
ix0rai
reviewed
Jul 25, 2023
...nc-v0/src/main/java/net/fabricmc/fabric/mixin/registry/sync/SerializableRegistriesMixin.java
Outdated
Show resolved
Hide resolved
...gistry-sync-v0/src/testmod/java/net/fabricmc/fabric/test/registry/sync/RegistrySyncTest.java
Outdated
Show resolved
Hide resolved
…tion?? I have no clue tbh)
|
Waiting on QuiltMC/quilt-standard-libraries#329 and QuiltMC/quilt-standard-libraries#330 to be merged and a new minor release of QSL to be released containing said fixes/additions to continue on this, as both features will heavily simply what QFAPI needs to come in sync with 0.86.0 and 0.86.1 On that subject, should QFAPI skip 0.86.0 and only provide support for 0.86.1? The latter is pretty much all bugfixes, so it seems like a reasonable thing to do, but I'm not sure. |
|
yes, we skip versions that release between updates so we'll go straight to |
|
While waiting for QSL prs 330 and 329 to be merged, going to look into fixing |
EnnuiL
suggested changes
Jul 31, 2023
fabric-model-loading-api-v1/src/client/resources/quilt.mod.json
Outdated
Show resolved
Hide resolved
...registry-sync-v0/src/main/java/net/fabricmc/fabric/api/event/registry/DynamicRegistries.java
Outdated
Show resolved
Hide resolved
...registry-sync-v0/src/main/java/net/fabricmc/fabric/api/event/registry/DynamicRegistries.java
Outdated
Show resolved
Hide resolved
...registry-sync-v0/src/main/java/net/fabricmc/fabric/api/event/registry/DynamicRegistries.java
Outdated
Show resolved
Hide resolved
...stry-sync-v0/src/main/java/net/fabricmc/fabric/impl/registry/sync/DynamicRegistriesImpl.java
Show resolved
Hide resolved
fabric-registry-sync-v0/src/main/resources/quilted_fabric_registry_sync_v0.mixins.json
Outdated
Show resolved
Hide resolved
fabric-registry-sync-v0/src/main/resources/quilted_fabric_registry_sync_v0.mixins.json
Show resolved
Hide resolved
Co-authored-by: Ennui Langeweile <[email protected]>
- Involved manually copy-pasting in the changes from the following FAPI upstream commits: -- FabricMC#3222 (one-to-one) -- FabricMC#3216 (required some modification in FabricDynamicRegistryProvider to quiltify) -- FabricMC#3212 (one-to-one other than converting FMJ additions to QMJ) -- FabricMC#3219 does not have to be added as it is not an issue with QSL's 0.86.1 impl of the same concept - Removed/rewrote parts of the QFAPI impl of FAPI's Dynamic Registry API that are better supported by using QSL's equivalents - Applied checkstyle and licensing checks. No licensing changes were made, though checkstyle changes were.
|
With the latest commit, QFAPI should be ready for testing and one final review pass! Going to set this as a ready PR now. |
Closed
This was
linked to
issues
Aug 1, 2023
Closed
EnnuiL
approved these changes
Aug 1, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Is seemingly mostly functional, but there's a chance I missed something somewhere, and this port also requires extensive testing against FAPI 0.86.0, current QSL, and vanilla for the recently added FAPI Dynamic Registries.
The other changes, including the new Fabric Model Loading API and small additions to the Fabric Transfer API, are seemingly drag-and-drop and did not require significant edits to make functional.