Result of DynmapBlockScan leaves custom water blocks unrendered

[kotoroshinoto]

template is bold
sample data is italicized

Issue Description: Dynmap sample issue description. This description would include as much and as little detail necessary for us to understand the issue in its entirety.

• Dynmap Version: dynmap-version
• Dynmap-3.6-forge-1.12.2.jar
• also paired with DynmapBlockScan-3.6-forge-1.12.2.jar
• Server Version: forge 1.16 build x, or paper 1.15.2 build x
• 1.12.2
• Pastebin of Configuration.txt: https://pastebin.com/5SETL3z2
• https://pastebin.com/a38DMDb0
• Server Host (if applicable): McProHosting, Shockbyte, Selfhosted, etc.
• Self hosted
• Pastebin of crashlogs or other relevant logs: https://pastebin.com/crashcausedbydynmap
• not crashing
• Other Relevant Data/Screenshots: I'm using this texture pack and these plugins and my map is from alpha .8

zoomed very far out, several oceans should be blue and are black

Coastal region.

• Steps to Replicate: Please be clear in this section so we can replicate your issue
• I am using the terrafirmagreg modpack. I selected an appropriate version of dynmap and dynmapblockscan for the 1.12.2 server.
  It fixed most of the missing blocks, but hasn't provided valid information for the custom water blocks.

I don't mind manually fixing the information if needed. The files appear to have recognized the presence of fresh_water hot_water and salt_water. it just doesn't render them.

[ ] I have looked at all other issues and this is not a duplicate
[ ] I have been able to replicate this

also reported at webbukkit/dynmap#4057 as I'm not entirely sure whether blockscan was wrong with respect to the block/texture information or if dynmap itself just isn't successfully rendering these blocks.

[kotoroshinoto]

relevant lines in the texture file:

block:id=%fluid/salt_water,transparency=SEMITRANSPARENT,stdrot=true
block:id=%fluid/hot_water,transparency=SEMITRANSPARENT,stdrot=true
block:id=%fluid/fresh_water,transparency=SEMITRANSPARENT,stdrot=true

relevant lines in the model file:

modellist:id=%fluid/fresh_water
modellist:id=%fluid/salt_water
modellist:id=%fluid/hot_water

[kotoroshinoto]

Comparing what I previously found for the tfc water with something that DOES get drawn

modname:puddles

modellist:id=%puddle,box=0.000000/0.000000/0.000000:16.000000/0.100000/16.000000:n/0/0.000000/14.000000/16.000000/16.000000:w/0/0.000000/14.000000/16.000000/16.000000:s/0/0.000000/14.000000/16.000000/16.000000:e/0/0.000000/14.000000/16.000000/16.000000:d/0/0.000000/0.000000/16.000000/16.000000:u/0/0.000000/0.000000/16.000000/16.000000

modname:puddles

texture:id=water_still,filename=assets/minecraft/textures/blocks/water_still.png,xcount=1,ycount=1
block:id=%puddle,patch0=0:water_still,transparency=TRANSPARENT,stdrot=true

Here I notice there is a texture pointed to. That is probably why it isn't working in the tfc case.

they have a handful of grayscale fluid pngs that get colored by the logic to use for each fluid block. There isn't a pre-produced independent specific png and mcmeta file for each block.

in the TFC jar file: assets\tfc\textures\blocks\ is the location where you will find these:

fluid_flow.png
fluid_flow.png.mcmeta
fluid_still.png
fluid_still.png.mcmeta
lava_flow.png
lava_flow.png.mcmeta
lava_still.png
lava_still.png.mcmeta

looking at the Fluid defs in TFC, there are calls to the forge Fluid class's constructor like these (leaving out the calls to drinkable property and temperature):

new Fluid("fresh_water", STILL, FLOW, 0xFF296ACD)
new Fluid("hot_water", STILL, FLOW, 0xFF345FDA)
new Fluid("salt_water", STILL, FLOW, 0xFF1F5099)

forge's class has a constructor file@(https://github.com/MinecraftForge/MinecraftForge/blob/1.12.x/src/main/java/net/minecraftforge/fluids/Fluid.java):
public Fluid(String fluidName, ResourceLocation still, ResourceLocation flowing, @Nullable ResourceLocation overlay)

somehow this information ties the created fresh/hot/salt water fluid representation to the blocks as well as contained fluids and associates them with the overlay and assigns the color.

the blockfluidTFC and blockhotwater use these calls (so they are being handed the Fluid object containing the association with the texture overlays via the Fluid object:

public BlockFluidTFC(Fluid fluid, Material material)
    {
        super(fluid, material);
    }
public BlockFluidTFC(Fluid fluid, Material material, boolean canCreateSources)
    {
        this(fluid, material);
        this.canCreateSources = canCreateSources;
        setHardness(100.0F);
    }
public BlockFluidHotWater() // this is an extension of blockfluidTFC, so the false is input for canCreateSources
    {
        super(FluidsTFC.HOT_WATER.get(), Material.WATER, false);

        setLightOpacity(3);
        disableStats();
    }

I'm not entirely sure how to convey this information to dynmap in the texture entry.