# Fluid Refactor proposal notes #

- We remove FluidType. Gone. Thanos snapped out of existence.
- Mods SHOULD instead register two fluids: still (or source) and flowing
- Or maybe only one if it's not valid for in-world use, or just doesn't
flow

- Mods SHOULD separate the logic for still/source and flowing fluids so
that fluids have more/less data (e.g. flow direction and level) based
on their needs
- Ideally this should also simplify their update logic, since the state
machine is then broken up into three more digestible components:
1. Sources turning adjacent displaceable blocks into flowing fluids;
2. Flowing blocks turning nearby displaceable blocks into flowing
fluids, up to a limit; and
3. Flowing blocks merging into a source block, if appropriate, or
otherwise updating their flow direction and level

- Fluid specific behaviors should be implemented on the fluid:
- e.g. fluids that flow upwards (e.g. like `#forge:is_gaseous`) would do
their alternate flow logic here

- NeoForge MAY provide helpers for one or more of the above points
- e.g. gaseous fluid abstractions for flowing upwards
- e.g. fluid abstractions for igniting blocks

- We instead start to use tags to identify multiple fluids that are "related":
- Multiple equivalent fluids (e.g. source and flowing fluids) SHOULD be
tagged under something like `#mymod:fluid_name`
- Mods SHOULD treat any two fluids tagged under this tag convention as
completely interchangeable
- NeoForge SHOULD provide a helper for performing this loose "equivalency"
check without having to hard-code this convention manually
- Modders MUST NOT assume that other mods will pick one entry in this tag
over another when converting fluids

- Recipes SHOULD be written using these tags instead of separate recipes
for each member fluid, if there is more than one
- If not, recipes MAY use the direct name of the fluid

- **Q:** Is there a scenario where other mods would want to register fluids
to this tag? If they have differing textures, it may be undesirable to
see fluids change from one form to another

- For commonly registered fluids, we MAY encourage a convention tag, e.g.
`#c:metal/iron` for iron, `#c:steam` for steam, or `#c:experience` for
experience
- This would be intended for recipes using fluids to be more compatible
with each other, just like how item tags work for ores and ingots

- We would also likely include set-intersection tags to describe properties
of the fluid, e.g. `#c:is_gaseous`, `#c:is_liquid` or `#c:is_potable`
- Properties like density would likely be provided via data maps, or
inferred from the above tags
- **Q:** Would we want to duplicate them across flowing/source? This
seems like it would be awkward for the common case where both match

- **Q:** Would mods expect `#c:steam` to be water steam, or should we
subfolder this as `#c:steam/water` (e.g. to allow `#c:steam/heavy_water`)

- For any reusable behaviors, especially on entities, modders SHOULD create
tags to trigger these behaviors, or halt them:
- e.g. swimming could be triggered by `#neoforge:is_swimmable`
- e.g. drowning could be stopped by `#neoforge:is_breathable`
- e.g. burning could be triggered by `#neoforge:is_flammable`

## Entity Changes Necessary ##

- The current logic in Entity erroneously sums fluid pushing vectors when in
multiple fluid types
- We'll change `updateFluidHeightAndDoFluidPushing` to take the average of
all fluids the entity is in instead of just per fluid type/group
- **Q:** Should it be a weighted average?
- Entities need to be changed to NOT use TagKey<Fluid> everywhere.
- We'll just directly use the Fluid where appropriate
- Vanilla APIs using TagKey will just return the first matching fluid
- Since a bunch of vanilla code uses maps, it will be arbitrarily random
- Logic uses methods like `isInLava` or `isInWater` to do behavioral changes
- We should make these into appropriate behavior tags or methods if
necessary
- Fog rendering gets weird with multiple fluids with different fog properties
- We should take the weighted average of these properties to give a
reasonable output
- **Q:** Fog color can't just be interpolated in RGB space, or else it
will turn an ugly brown/grey - what should we do here?