* Fluid rendering fixes
- Fix default overlay block check using TransparentBlock instead of TranslucentBlock
- Fix setBlockTransparency/isBlockTransparent not being thread-safe
- Reuse the same render handler objects for water and lava
* Fix implementation issues
- Fix custom geometry being buffered twice if FluidRenderHandler#renderFluid is invoked directly
- Fix calling FluidRenderHandler.super.renderFluid not using passed arguments to calculate color
- Fix calling FluidRenderHandler.super.renderFluid more than once producing incorrect geometry
- Fix fluids with no handler never receiving water overlay instead of using default behavior
* Add way to render fluid with non-vanilla default
- Fix testmod
(cherry picked from commit e761c6698e)
* Expose a function for querying the non-default fluid renderer
* Do not register default handlers as overrides
* Add @Nullable to getOverride
* Add @Nullable to get
---------
Co-authored-by: modmuss50 <modmuss50@gmail.com>
(cherry picked from commit d74054c1e7)
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`
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.
* Implement custom fluid rendering
* Move custom renderers in FluidRenderer mixin and add overlay sprite support to FluidRenderHandlers
* Add vanilla-like fluid renderer. Maybe very unnecessary, might remove.
* Optimize imports
* Allow custom fluid renderers to call the default renderer. Re-add DEFAULT.
* Add interface to implement by blocks that enforces overlay texture on fluids
* Some comments
* Simplify API and remove DefaultLikeFluidRenderer
* Make simple renderer overlay texture nullable
Co-authored-by: Technici4n <13494793+Technici4n@users.noreply.github.com>
* Expand test mod
* Checkstyle and licenses
* Easy shortcut for custom colored vanilla water fluids
* Easy way to register a renderer for two (still+flowing) fluids
* Update fabric-rendering-fluids-v1/src/main/java/net/fabricmc/fabric/api/client/render/fluid/v1/FluidRenderHandlerRegistry.java
Co-authored-by: Juuxel <6596629+Juuxel@users.noreply.github.com>
* Update fabric-rendering-fluids-v1/src/main/java/net/fabricmc/fabric/mixin/client/rendering/fluid/MixinFluidRenderer.java
Co-authored-by: Juuxel <6596629+Juuxel@users.noreply.github.com>
Co-authored-by: Technici4n <13494793+Technici4n@users.noreply.github.com>
Co-authored-by: modmuss50 <modmuss50@gmail.com>
Co-authored-by: Juuxel <6596629+Juuxel@users.noreply.github.com>
This is a workaround for transfer-api having unsatisfiable dependencies
in the dedicated server environemnt. Fabric Loader 0.11 doesn't check
this dependency correctly, but it breaks on 0.12 - as it should. A proper
solution is too incompatible for now.
* Add custom value denoting module lifecycles.
* Make the module validation work.
My hand has been forced - we must use buildSrc since JsonSlurper is not available in main buildscript.
* Apply task to each project and dont cross projects
* A horrible hack
* Wait what
* It works now.
* Not needed
* Drop unneeded maven repo, cache map lookup
(cherry picked from commit daa38b3d82)
* Boost to Loom 0.5
Add null related annotations
* Rearrange nullable to be overline
* Fix anno sorting for picky
* Add imports
* Address feedback
* Fix import
* 19w39a fixes (#387)
* Bump versions
* Breaks: BlockEntityRendererRegistry and EntityRendererRegistry
* Remove broken parts of rendering, bump major version
* Add renderer-registries, replaces broken parts of rendering api
* Slap a band-aid on renderer/Indigo - won't render properly, but runs
* Bump distribution versions, add renderer-registries to main build
* Clean up blockrenderlayer implementation package name
