The block lookup API's registerForBlockEntities method currently just
registers the passed provider for each valid block for that block
entity.
However, in some situations (such as update suppression or a misbehaving
mod), the wrong block entity will be present for one of these blocks.
This means that the (incorrect) block entity will be passed off to the
provider. Providers (especially those registered with
registerForBlockEntity) will often blind-cast the supplied BE, leading
to crashes.
While the wrong BE being present is a bug, we should follow vanilla's
lead and handle this more gracefully. In this case, we just check
whether the correct BE type is present before forwarding it to the
main provider.
* 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
# 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/
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.
- **(Slightly source-breaking change)** Change the return type of `Storage#iterator` and `Storage#iterable` from `Iterator<StorageView<T>>` to `Iterator<? extends StorageView<T>>` to allow returning a list directly. Most modders shouldn't be affected by this (this only broke one call site in the whole module).
- Precise that using the iterator or a view after the transaction is closed is "undefined behavior". Also specify that calling remove on the iterator is not allowed.
- Add `StorageView#getUnderlyingView` to be able to tell if some views are equal. This is useful to **compute the contents of multiple storage views without duplicates** (see testmod).
- Expose the lifecycle of the transaction manager cleanly with an enum.
- Definalize some methods in `SingleStackStorage` to allow custom implementations of some of them if needed.
- Add a note to `BlockApiLookup` to fix#1998.
- Play the composter empty sound when it is emptied through the transfer API, as a comment in the source code suggests.
Co-authored-by: Juuxel <6596629+Juuxel@users.noreply.github.com>
* Add id getter to ApiLookups and expose the BE in BlockApiCache
* identifier() -> getIdentifier(), and add some query methods to BlockApiCache
* getId
* Entity API Lookup
* Update fabric-api-lookup-api-v1/src/main/java/net/fabricmc/fabric/api/lookup/v1/entity/EntityApiLookup.java
Co-authored-by: Juuxel <6596629+Juuxel@users.noreply.github.com>
* Update according to review
* Check for valid entity
* Use synchronized block on REGISTERED_SELVES accesses
Co-authored-by: Juuxel <6596629+Juuxel@users.noreply.github.com>
* Initial version of Item API API
* Use an ItemStack parameter instead of an Item parameter for API queries
* Add ItemStack modification note
* Kindly ask providers not to modify the stack
* Expose the API and context types
* Bump version to 1.2.0
# Fabric API Lookup API v1
## Introduction
This module allows Api instances to be associated with game objects without specifying how the association is implemented. This is useful when the same Api could be implemented more than once or implemented in different ways.
Many thanks to @Grondag for providing the original concept (#1072).
Thanks also go to @i509VCB, @Pyrofab, @sfPlayer1 and the others who were involved with the design of this module.
This is the foundation upon which can be built for example a fluid transfer api (#1166). Closes#1199.
## Flexible Api Querying
## Block Api Usage example
## Building blocks
This PR was changed a lot, please have a look at the README, the package info, and the javadoc for `BlockApiLookup` and `ApiLookupMap` for up-to-date documentation.
## More usage examples
FastTransferLib (https://github.com/Technici4n/FastTransferLib) is an experiment to build an item, fluid and energy transfer api on top of this module. (Which was until recently called `fabric-provider-api-v1`.)
## Missing things?
~~I could add an overload of `BlockApiLookup#find` with nullable `BlockState` and `BlockEntity` parameters, so that the caller can directly provide them if they are available for some reason.~~ Added in later commits.
There is no module to retrieve apis from items or entities yet because there were unsolved issues with those. The community can use the provided building blocks to experiment with their own implementations of `ItemStackApiLookup` and `EntityApiLookup` until the way forward becomes clear, but let's please not delay the `BlockApiLookup` because of that.
Co-authored-by: i509VCB <git@i509.me>
Co-authored-by: PepperBell <44146161+PepperCode1@users.noreply.github.com>
(cherry picked from commit dc716ea167)
