* Delete `FabricDimensions`
This broke during the 1.21 cycle and can be easily replaced with `Entity#teleportTo`.
* Rename testmod data directories
* [Breaking] use singular path in GameTest
* Fix attribute modifier in testmod
* Small mixin refactors related to teleportTo
* Fix behavior change in ModNioResourcePack for invalid paths
* Fix javadocs referencing Identifier ctor
* Add new FabricCodecDataProvider ctor
* Move empty structure
* Fix transfer api testmod
* pro tip: don't write datagen output by hand
* Refactor networking API to remove redundant code
* Stop calling CustomDamageHandler in creative mode
* Deprecate FabricBlockSettings
* Deprecate FabricItemSettings
* Start on 24w03a
* Main menu :)
* Update mappings
* PayloadTypeRegistry
* Networking part 2 of many
* Networking part 3 of many
* Networking part 4 of many
* Recipe api
* Port Item API to 1.20.5
* Is this even right?
* Port FabricParticleTypes to 1.20.5
* Remove redundant fuel caching logic
* Remove fabric-containers-v0, deprecated since 2020
* Regsync work
* Adapt screen handler to new networking
* Update yarn + more work
* More mapping updates
* Compile fixes
* Checkstyle + small fixes
* Single and multiplayer fixes
* Handle play packets on main thread.
* Update mappings
* Even more networking
* Networking tests
* Fix todo's
* Update javadocs
* Networking API improvements
* Some small regsync refactors
* Fix handling of null NBT in NbtIngredient
* Update fabric-object-builder-api-v1/src/main/java/net/fabricmc/fabric/api/object/builder/v1/block/FabricBlockSettings.java
Co-authored-by: ErrorCraft <51973682+ErrorCraft@users.noreply.github.com>
* Update fabric-object-builder-api-v1/src/main/java/net/fabricmc/fabric/api/object/builder/v1/block/FabricBlockSettings.java
Co-authored-by: ErrorCraft <51973682+ErrorCraft@users.noreply.github.com>
* Add context objects
* ChannelInfoHolder.getPendingChannelsNames -> fabric_getPendingChannelsNames
* Fix crash
* send `c:register` packet for play phase instead of config (#3544)
* Bump version
---------
Co-authored-by: ErrorCraft <51973682+ErrorCraft@users.noreply.github.com>
Co-authored-by: apple502j <33279053+apple502j@users.noreply.github.com>
Co-authored-by: Drex <nicknamedrex@gmail.com>
Co-authored-by: deirn <deirn@bai.lol>
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.
(cherry picked from commit 82b1bb3ec3)
Breaking changes:
- `FabricBrewingRecipeRegistry.registerPotionRecipe` takes `RegistryEntry<Potion>` instead of `Potion`
- `SculkSensorFrequencyRegistry.regster` takes `RegistryKey<GameEvent>` instead of `GameEvent`
- `FabricLanguageProvider.add` takes `RegistryEntry<EntityAttribute>` instead of `EntityAttribute`
- `FabricTagProvider.GameEventTagProvider` was removed replace with `FabricTagProvider<GameEvent>`
- `FabricItem.getAttributeModifiers` returns a Multimap with a key of `RegistryEntry<EntityAttribute>` instead of `EntityAttribute`
- `ModifyItemAttributeModifiersCallback.modifyAttributeModifiers` takes Multimap with a key of `RegistryEntry<EntityAttribute>` instead of `EntityAttribute`
* 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
