213
edits
Changes
User:ChampionAsh5357/Sandbox/Fluids API (view source)
Revision as of 01:43, 15 June 2022
, 01:43, 15 June 2022Quick primer
* <code>ForgeFlowingFluid$Properties(Fluid, Fluid, FluidAttributes)</code> -> <code>ForgeFlowingFluid$Properties(FluidType, Fluid, Fluid)</code>
* <code>ForgeFlowingFluid$Properties(Fluid, Fluid, FluidAttributes)</code> -> <code>ForgeFlowingFluid$Properties(FluidType, Fluid, Fluid)</code>
* <code>ForgeFlowingFluid#canMultiply</code> -> <code>FluidType#canConvertToSource(FluidState, LevelReader, BlockPos)</code>
* <code>ForgeFlowingFluid#canMultiply</code> -> <code>FluidType#canConvertToSource(FluidState, LevelReader, BlockPos)</code>
== Vanilla Breaking Change: No Physics in Tags ==
One of the largest changes within the Fluid API is that Fluid Tags no longer control the physics of fluids. To account for this, a different unifying object which can represent any group of fluids must be chosen. After much consideration, this became <code>FluidType</code>, which replaced <code>FluidAttributes</code>.
=== Removal of FluidAttributes ===
<code>FluidAttributes</code> has been completely removed with most of its logic being delegated to either <code>FluidType</code> or <code>IFluidTypeRenderProperties</code> for rendering. The object itself wasn't unique and tended to be reconstructed whenever referenced. As such, it was removed in favor of a more singleton approach.
== FluidType ==
<code>FluidType</code> replaces <code>FluidAttributes</code>. All fluids must override <code>IForgeFluid#getFluidType</code> similar to the previous <code>#getAttributes</code>. Additionally, the <code>FluidType</code> can be accessed from the fluid or fluid state for convenience.
<code>FluidType</code> is a forge registry, and as such needs to be registered. If using <code>DeferredRegister</code>, you must use the one that takes in the registry name and modid since the registry does not exist during mod construction.
=== isVaporizedOnPlacement ===
<code>FluidType#isVaporizedOnPlacement</code> has now been expanded to allow for vaporization to occur outside of only ultra warm dimensions. To do so, simply override the method.
== IFluidTypeRenderProperties ==
<code>IFluidTypeRenderProperties</code> contains all rendering related logic to fluids. This includes the color tint, still texture, flowing texture, and overlay texture. Note that the still texture and flowing texture must be specified by overriding <code>#getStillTexture</code> and <code>#getFlowingTexture</code> respectively.
== Modified Accessors ==
All properties in <code>FluidType</code> and <code>IFluidTypeRenderProperties</code> have either an entity, level, or stack based accessor attached to it. These provide context in question if the behavior of the fluid should change in relation to the entity its acting upon, the location of the fluid in the level, or the containing fluid stack respectively.
There are some accessors with no parameters. These are typically because the use case may not be fully defined in every context that are available to the modder. They should not be used whenever possible as they may be removed in future releases once the context has been fully specified.
== Chained Methods ==
A good portion of the accessors in <code>FluidType</code> are chained in some capacity. This means that modders who are using fluids from other mods can specify unique behavior without having to modify the fluid itself. Let's take two examples: <code>#canHydrate(Level Accessor)</code> and <code>#supportsBoating</code>.
<code>#canHydrate</code> can be modified by the <code>FluidType</code>, <code>Fluid</code>, or <code>Block</code>. This means that the <code>FluidType</code> can define general behavior to use while the <code>Block</code> may define specific behavior for if it can be hydrated.
<code>#supportsBoating</code> works similarly with <code>FluidType</code> and <code>Boat</code>. The <code>FluidType</code> can define in general if boats should work on it while a specific <code>Boat</code> can determine whether it actually can float on the fluid.
== Entity Pathing ==
Entity pathing can now be specified for a given block or the underlying fluid using <code>IForgeBlock#getBlockPathType</code>, <code>IForgeBlock#getAdjacentBlockPathType</code>, <code>FluidType#getBlockPathType</code>, and <code>FluidType#getAdjacentBlockPathType</code>. For clarity, the regular block path type gets the raw type to be used if the adjacents are not specified. The adjacent path type specifically determines which one the entity will move to and will either default to <code>OPEN</code>, <code>WALKABLE</code> or <code>BLOCKED</code> internally. Typically, the entity will pathfind to the smallest positive malus of the type, where negative numbers are considered intraversable. Additional types can be created using <code>BlockPathTypes#create</code>.
== IForgeEntity ==
<code>IForgeEntity</code> now contains many additional commands to handle fluid physics logic. These include the height, which fluid the entity's eyes are in, and if an entity is in a fluid type. All of these methods are properly documented in the extension. Note that these replace their vanilla counterparts and should be used instead.
== IForgeLivingEntity ==
<code>IForgeLivingEntity</code> contains two unique fluid logic handlers: how an entity "jumps" in a fluid, and how they "sink". These methods can currently only be overridden on an entity and not by the <code>FluidType</code>.
== SoundAction ==
<code>SoundAction</code> is the abstracted sound manager for defining which sound to play in a given context. It works exactly like <code>ToolAction</code> where it simply defines a unique name that performs a given action. A new action can be created using <code>SoundAction#get</code>. Vanilla actions are defined within <code>SoundActions</code> (filling/empty bucket, vaporizing).
== Fluid Interactions ==
Fluid interactions are handled by the <code>FluidInteractionRegistry</code>. Interactions define the behavior a block should handle in all directions besides down. The down direction must be defined by the fluid in <code>FlowingFluid#spreadTo</code>, and will not be considered in this registry. An interaction can be registered using <code>#addInteraction</code> in <code>FMLCommonSetupEvent</code> by specifying the source of the interaction (which is typically the fluid being replaced), and the interaction information which defines the conditions of when the interaction should occur and what the interaction should do.
== Gaseous Fluids ==
A <code>Fluid</code> is considered gaseous at room temperature if it is in the <code>forge:gaseous</code> tag. This is typically correlated with a negative density.