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?