* Update to loom 1.3
* Fix more 1.3 deprecations
* Opps
* Move to mod publish plugin
* Revert some changes
* Fix some more Gradle deprecations
* Fix names
* Remove extra stuff
* Cleanup
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>
# Breaking changes
- `VillagerPlantableRegistry` replaced with `ItemTags.VILLAGER_PLANTABLE_SEEDS`
- `FabricItemGroup.builder()` no longer takes an `Identifier`
- `FabricItemGroup.build()` no longer registers the ItemGroup, this now needs to go in the vanilla registry.
- `ItemGroupEvents.modifyEntriesEvent` now takes a `RegistryKey<ItemGroup>` in place of an `Identifier`
- `FabricLanguageProvider` now takes a `RegistryKey<ItemGroup>` in place of an `ItemGroup`
- `IdentifiableItemGroup` removed, replaced with vanilla registries.
- `FabricMaterialBuilder` removed, no replacement.
- `HudRenderCallback.onHudRender` now passed a `DrawableHelper` in place of `MatrixStack`
- `ScreenEvents.beforeRender` now passed a `DrawableHelper` in place of `MatrixStack`
- `ScreenEvents.afterRender` now passed a `DrawableHelper` in place of `MatrixStack`
- `Screens.getItemRenderer()` removed. Replace with `MinecraftClient.getItemRenderer()`
`DrawableHelper` is likely to be renamed soon, see: https://github.com/FabricMC/yarn/pull/3548/
* BlockSetTypeRegistry and WoodTypeRegistry
Adds `BlockSetTypeRegistry` for creating `BlockSetType`s using Identifiers.
Also adds `WoodTypeRegistry` to replace `SignTypeRegistry`, matching the new more accurate Yarn name. The old `SignTypeRegistry` remains as deprecated for compatibility.
Also updates Yarn build.
* Delete SignTypeRegistry.java
Broke in the update anyway, no use keeping it
* Suggestions
* Whoops
* Suggestions
* Fabric custom ingredient API
* More Ingredient API work
* Optimize shapeless matching logic
* Fix all the things
* Move custom ingredient network serialization to account for ingredient extension API
* Apply suggestions from code review
Co-authored-by: apple502j <33279053+apple502j@users.noreply.github.com>
* Address 🍎 review
* Get rid of the @Overwrite
* Implement graceful fallback for clients not supporting some custom ingredients
* Move custom ingredient code to new Recipe API module
* Fix client package change
* Address review comments
- And/Or -> All/Any
- Move builtin ingredient registration to entrypoint
- Initial protocol version is 1
- Misc other changes
* Add testing instructions
* Use a List for `getMatchingStacks`
* Overengineer ingredient query a bit
Co-authored-by: apple502j <33279053+apple502j@users.noreply.github.com>
Co-authored-by: modmuss50 <modmuss50@gmail.com>
* Add block appearance API
* Add class javadoc for FabricBlock and FabricBlockState
* Address reviews
* Remove OverrideOnly from getAppearance
* Fix javadoc issues
* Allow sound instances to play custom audio streams
Adds a new interface FabricSoundInstance, which is injected into
vanilla's SoundInstance interface.
When loading an audio stream, the SoundSystem now calls
FabricSoundInstance.getAudioStream, allowing mods to provide their
own audio streams.
* Some post-review cleanup
- Manually add the client sources as an interface injection source set,
allowing us to put everything in the src/client dir (<3 modmuss50).
- Apply some formatting changes from apple502j.
* Document the empty sound and its usage in sounds.json
* Fix one remaining @literal -> @code
* Fix checkstyle issues
* Initial skeleton
* Fabric Chat API v1 (experimental)
* Run checkstyle
* Fix checkstyle (testmod)
* Support 1.19-pre1
* Fix spotless
* Fixes
* Remove caching of messages
This is hard to maintain and has several edge cases. Mods should cache themselves when needed.
* Make constructor private
* Add ServerChatEvents
* Update mappings
* Prepare for the rename
* Include chat decorator in exception
* Add support for blocking messages
* Rename to fabric-message-api-v1
* Update to 1.19-pre2
* Use fabric namespace
* Rename ChatDecoratorEvent
* Rename events and add more javadoc
* Rename ServerChatEvents
* Rename ChatDecorator
* Only block bad respawn point death in testmod
* Fix wrong word in javadoc
* Improve javadoc
Co-authored-by: modmuss50 <modmuss50@gmail.com>
- Deprecates all classes and methods that use outdated Yarn names.
- Adds FabricLootTable and FabricLootTableBuilder to replace
the LootSupplier naming variants.
- Deprecates LootEntryTypeRegistry and LootJsonParser
as their functionality is exposed in vanilla now.
- Adds methods to FabricLootPoolBuilder for working
with collections as builder parameters.
- FabricLootPool and FabricLootTable/Supplier now return immutable lists
instead of modifiable fixed-size ones.
Co-authored-by: i509VCB <i509vcb@gmail.com>
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.
