Config

Understanding Fluidlogged API's config is vital for any player looking to add/remove fluidloggable block functionality. This mod's config file will be auto generated as fluidlogged_api.cfg on your first launch, and be placed in Minecraft's config folder (will also be auto generated if it doesn't yet exist). It's important that you don't rename the config file or change its location, otherwise the file will be ignored, and a one will be auto generated entirely. The config can be reloaded while in game through the /reloadFluidloggedAPI command.

fluidloggedFluidSpread

When there's two or more water sources with a one block gap between them, a new water source will be formed in the gap (an infinite 2x2 water source for example). The fluidloggedFluidSpread parameter allows this feature to be customized for cases that involve the water forming in a fluidloggable block.

• when set to 0: Water sources cannot form in fluidloggable blocks.
• when set to 1: Water sources can form in fluidloggable blocks, but only if the other water source blocks are also waterlogged (legacy v1.6.2 behavior).
• when set to 2 (default value): Water sources can form in fluidloggable blocks (vanilla 1.13+ behavior).

applyDefaults

By default, this mod allows a certain selection of vanilla & certain correctly programed modded blocks to be fluidlogged. Setting this to false allows for a blank slate to add fluidloggable blocks only through the whitelist, more info about that below.

(The default blocks include: anvils, banners, barriers, beacons, brewing stands, buttons, comparators, chests, daylight detectors, doors, dragon egg, enchantment tables, end portal frames, end rods, ender chests, fences, fence gates, glass panes, half slabs, hoppers, iron bars, leaves, levers, mob heads, mob spawners, pressure plates, pistons (while extended), rails, repeaters, redstone torches, redstone wires, trapdoors, tripwire hooks, tripwire string, signs, and walls)

whitelist

The whitelist allows players to add blocks that they want fluidloggable. Players can specify different optional arguments within each whitelist entry, where the only mandatory argument is the blockId. An example of a basic entry that adds bedrock to the whitelist is as follows:

whitelist:[{blockId:"minecraft:bedrock"}]

• The metadata argument will only allow the block to be fluidloggable if its metadata value matches any of the user-provided ones. Remember, not having this argument will cause the entry to ignore metadata values. Here's an example of an entry that allows oak, spruce, and birch planks to be fluidloggable, while not allowing any of the others:

whitelist:[{blockId:"minecraft:planks", metadata:[0, 1, 2]}]

• The fluids argument will only allow the block to be fluidloggable if the fluid matches any of the user-provided ones. Here's an example of an entry that allows glass to be fluidloggable, but only in water or lava:

whitelist:[{blockId:"minecraft:glass", fluids:["minecraft:water", "minecraft:lava"]}]

• The fluidTags argument functions the same as the fluids argument, however this one takes in user-defined FluidTags instead of fluid block ids. One advantage to using this over the fluids argument is when you find yourself copying long fluid arguments between entries. Here's the above entry recreated with fluidTags:

fluidTags:[{id:"vanilla", fluids:["minecraft:water", "minecraft:lava"]}],
whitelist:[{blockId:"minecraft:glass", fluidTags:["vanilla"]}]

• The last optional argument for whitelist entries is canFluidFlow. This argument was implemented primarily as a way for players to get around mods with incorrectly coded block sides. Adding this will tell Fluidlogged API that the fluidlogged fluid can flow from any (or none) of the block's sides, and that neighboring fluids can connect to it for rendering and block mixing purposes. Here's the first example of adding bedrock to the whitelist, but with fluids able to flow from any of its sides:

whitelist:[{blockId:"minecraft:bedrock", canFluidFlow:true}]

blacklist

This functions identically to the whitelist, so read on that to get an idea of the format this uses. Where this differs from the whitelist is that rather than adding blocks that can be fluidlogged, this removes them.