Custom Fluid Help

broede · December 13, 2013

Now we're getting somewhere, unfortunately things are not working as I had hoped they would.

Originally, my two fluids, sludge and waste, rendered properly. However, after reading the tutorial linked by TGG, I converted everything over to using the iconStill/iconFlowing as suggested. I made animations, etc. etc. Now, I'm finding something interesting. Both of my fluids are displaying the same files.

Here's where I load the two fluids and their blocks:

public void BuildFluids() {
	// Sludge.  The result of mixing Waste with Water.  Non-toxic.
	fluidSludge = new DCFluid("Sludge")
	 .setViscosity(2000)
	 .setDensity(
	 .setUnlocalizedName("fluidSludge")
	 .setBlockID(blockRegistry.newID());
	FluidRegistry.registerFluid(fluidSludge);
	blockSludge = (DCBlockFluid) new DCBlockFluid(fluidSludge.getBlockID(), fluidSludge, SLUDGE)
	 .setHardness(100.0F)
	 .setLightOpacity(3)
	 .setUnlocalizedName("blockSludge");
	LanguageRegistry.addName(blockSludge, "Sludge");
	GameRegistry.registerBlock(blockSludge, "blockSludge");

	// Waste.  Toxic to the living.  Only found in the Bayou dimension.
	fluidWaste = new DCFluid("Waste")
	 .setViscosity(7500)
	 .setDensity(3)
	 .setLuminosity(15)
	 .setUnlocalizedName("fluidWaste")
	 .setBlockID(blockRegistry.newID());
	FluidRegistry.registerFluid(fluidWaste);
	blockWaste = (DCBlockFluid) new DCBlockFluid(fluidWaste.getBlockID(), fluidWaste, WASTE)
	 .setHardness(100.0F)
	 .setLightValue(1.0F)
	 .setUnlocalizedName("blockWaste");
	LanguageRegistry.addName(blockWaste, "Waste");
	GameRegistry.registerBlock(blockWaste, "blockWaste");

}

And this is the DCBlockFluid class where it registers the icons:

@SideOnly(Side.CLIENT)
public void registerIcons(IconRegister iconRegister) {
	this.iconStill = iconRegister.registerIcon(DCMod.modid + ":" + (this.getUnlocalizedName().substring(5)) + "Still");
	this.iconFlowing = iconRegister.registerIcon(DCMod.modid + ":" + (this.getUnlocalizedName().substring(5)) + "Flow");
	this.getFluid().setIcons(this.iconStill, this.iconFlowing);
}

Problem is, they're both displaying the "waste" icons now, instead of their own individual icons, whereas they did so before. For some reason, the newer of the two is overlaying their icons over the other. I switch the order of which the fluids were created and this backed up my theory. What can I possibly be doing wrong here?

TheGreyGhost · December 14, 2013

Hi

At a guess, this.getFluid() in your registerIcons retrieves the same Fluid for both sludge blocks and waste blocks. A breakpoint or logging code might show why.

-TGG

broede · December 14, 2013

Hi

At a guess, this.getFluid() in your registerIcons retrieves the same Fluid for both sludge blocks and waste blocks. A breakpoint or logging code might show why.

-TGG

I opened a logger and went into that method you suggested and logged every detail. This fluid's icons are being set properly. However, check out this log output I called in postInit()...

2013-12-14 06:01:17 [iNFO] [DOOMEDCraft-Client] Running postInit()
2013-12-14 06:01:17 [iNFO] [DOOMEDCraft-Client] Logging fluid details:
2013-12-14 06:01:17 [iNFO] [DOOMEDCraft-Client] fluidSludge >>
2013-12-14 06:01:17 [iNFO] [DOOMEDCraft-Client] Name - sludge
2013-12-14 06:01:17 [iNFO] [DOOMEDCraft-Client] UnlocalizedName - fluid.fluidSludge
2013-12-14 06:01:17 [iNFO] [DOOMEDCraft-Client] Still Icon - dcmod:blockSludgeStill
2013-12-14 06:01:17 [iNFO] [DOOMEDCraft-Client] Flowing Icon - dcmod:blockSludgeFlow
2013-12-14 06:01:17 [iNFO] [DOOMEDCraft-Client] blockSludge >> 
2013-12-14 06:01:17 [iNFO] [DOOMEDCraft-Client] UnlocalizedName - tile.blockSludge
2013-12-14 06:01:17 [iNFO] [DOOMEDCraft-Client] Still Icon - dcmod:blockSludgeStill
2013-12-14 06:01:17 [iNFO] [DOOMEDCraft-Client] Flowing Icon - dcmod:blockSludgeFlow
2013-12-14 06:01:17 [iNFO] [DOOMEDCraft-Client] fluidWaste >>
2013-12-14 06:01:17 [iNFO] [DOOMEDCraft-Client] Name - waste
2013-12-14 06:01:17 [iNFO] [DOOMEDCraft-Client] UnlocalizedName - fluid.fluidWaste
2013-12-14 06:01:17 [iNFO] [DOOMEDCraft-Client] Still Icon - dcmod:blockWasteStill
2013-12-14 06:01:17 [iNFO] [DOOMEDCraft-Client] Flowing Icon - dcmod:blockWasteFlow
2013-12-14 06:01:17 [iNFO] [DOOMEDCraft-Client] blockWaste >> 
2013-12-14 06:01:17 [iNFO] [DOOMEDCraft-Client] UnlocalizedName - tile.blockWaste
2013-12-14 06:01:17 [iNFO] [DOOMEDCraft-Client] Still Icon - dcmod:blockSludgeStill
2013-12-14 06:01:17 [iNFO] [DOOMEDCraft-Client] Flowing Icon - dcmod:blockSludgeFlow
2013-12-14 06:01:17 [iNFO] [DOOMEDCraft-Client] Leaving postInit()

For some reason, the Waste BLOCK, not the fluid, is getting the incorrect icons set. Wait... WHAT?!? I don't even get how! If the fluid icons are being set based on the block icons (due to the call stack -- the blocks are being built, and THEN the fluid icons are being set based on those), then why aren't the fluid's icons incorrect, too? This is making me dizzy. lol

broede · December 14, 2013

It occurred to me... this fluid icons are working. So now, my getIcon() method simply ignores the Block icons and calls them directly from the fluid itself. This may be a weird work-around, but it works! Thanks again for all the help!

Last thing to do is look at TGG's suggestion for flow length, and I'll be set.

TheGreyGhost · December 14, 2013

Hi

Keen, sounds like you're nearly there.

Overriding getIcon() to take the icons from the fluid sounds like a perfectly good way to solve the problem. My only other thought was that perhaps you declared your DCBlockFluid.iconStill and iconFlowing as static?

That tutorial you promised might be very helpful to modders who come after:-P

Glad I could be of some help, it was pretty interesting to hunt through the vanilla code and figure out how this works. IMHO I don't think it was coded very well (or at least - not very extensibly) by the Mojang folks. Fragments of responsibility scattered all over the place.

-TGG

broede · December 14, 2013

Hi

Keen, sounds like you're nearly there.

Overriding getIcon() to take the icons from the fluid sounds like a perfectly good way to solve the problem. My only other thought was that perhaps you declared your DCBlockFluid.iconStill and iconFlowing as static?

That tutorial you promised might be very helpful to modders who come after:-P

Glad I could be of some help, it was pretty interesting to hunt through the vanilla code and figure out how this works. IMHO I don't think it was coded very well (or at least - not very extensibly) by the Mojang folks. Fragments of responsibility scattered all over the place.

-TGG

Come to find out, BlockFluidBase controls flow length with something called "quantaPerBlock". All you have to do is use your new BlockFluidClassic class to call setQuantaPerBlock(number). With the way it is coded, it'll accept any number from 1 (meaning no flow-over) to 16 (flowing outward 15 blocks). This defaults to 8. Here's how I set mine up:

public DCBlockFluid(int par1, Fluid par2Fluid, Material par3Material, int quant) {
	super(par1, par2Fluid, par3Material);
	this.disableStats();
        float f = 0.0F;
        float f1 = 0.0F;
        this.setBlockBounds(0.0F + f1, 0.0F + f, 0.0F + f1, 1.0F + f1, 1.0F + f, 1.0F + f1);
        this.setTickRandomly(true);
        this.setQuantaPerBlock(quant);
}

I added the quantity into the constructor, then simply passed it on to setQuantaPerBlock from there. Works like a charm (my Waste block is set to 3, and flows no more than 2 blocks).

I'm curious, do you know what "luminosity" does? I set it to 15 and there's very little light. But when I set it to 0 and simply changed the block's LightValue to 1.0F, it lights up like lava (which is what I wanted for my Waste fluid). I'm not sure what the use of luminosity is.

Anyway, yes, I've come a long way in just under a week in no small part thanks to you and the others that have given me the right places to look. But I still have a couple more things to deal with before I feel comfortable writing up a tutorial. For instance, when you're underwater, I noticed that there's a deep murkiness to it. Not only is it dark without underwater vision, but there are particles of some kind rendered underneath there. These black dots and some light-colored lines. Do you have any insight on what those might be?

EDIT: Good call on the static declarations of my icons, by the way. Can't believe I didn't catch that sooner myself.

TheGreyGhost · December 14, 2013

Hi

Good call on the quantaPerBlock, didn't think of that myself.

Luminosity is supposed to control how much your fluid glows, and by looking at the code in BlockFluidClassic.getLightValue, it looks like the block light value (i.e. how much it glows) is multiplied by the amount of fluid. So a full block gives full light, a half block gives only half light. For lava (using the LightValue), it always glows at full strength regardless of whether it's a full block or just a thin sliver. From what I saw looking at the code, I would have expected luminosity = 15 to be the same as LightValue 1.0 like you did. Not sure why it didn't work for you.

Don't rightly know about the other render effects. There is bubble and splash rendering in BlockFluid.randomDisplayTick for water blocks. The murkiness might be related to the opacity, I'm not certain - see here for a bit more info on lighting

http://greyminecraftcoder.blogspot.com.au/2013/08/lighting.html

Some random other observations: BlockFluid.colorMultiplier seems to control the colour of the top and side faces somehow depending on the Biome. The underside of the surface of the water looks darker than the top because it is rendered at half the brightness -

in RenderBlocks.renderBlockFluids

f3 = 0.5F;
// ... etc ...
f11 = 1.0F;
                tessellator.setColorOpaque_F(f3 * f11, f3 * f11, f3 * f11);
                this.renderFaceYNeg(par1Block, (double)par2, (double)par3 + d6, (double)par4, this.getBlockIconFromSide(par1Block, 0));

-TGG

broede · December 16, 2013

I've been debugging a number of things before I move on to dealing with new things, and one bug I cannot seem to figure out... mobs automatically bob to the surface of water and even lava, but for some reason I cannot seem to get them to bob to the surface of my custom liquids. It's so frustrating. Mobs at the bottom of a pool just sit there. Now, I got them to be able to path across my liquids if they're searching for a player, and they can bob out of the fluid if they are on the surface, but if they sink more than a single block, they never come out.

UPDATE: I noticed that jumping when underwater is handled mainly in EntityAISwimming.java, for those of you wanting to know the solution to this. Simply add new fluid checks into the method shouldExecute(). You'll also want to update EntityLiving, EntityLivingBase and Entity with any checks for your fluids, as well.

broede · December 17, 2013

Okay, this is currently what's on my plate. Darkening the inside of the fluid. Here's your previous post...

*snippet*

The underside of the surface of the water looks darker than the top because it is rendered at half the brightness -

in RenderBlocks.renderBlockFluids
f3 = 0.5F;
// ... etc ...
f11 = 1.0F;
                tessellator.setColorOpaque_F(f3 * f11, f3 * f11, f3 * f11);
                this.renderFaceYNeg(par1Block, (double)par2, (double)par3 + d6, (double)par4, this.getBlockIconFromSide(par1Block, 0));
-TGG

Okay, it seems to be that you are right, however, from everything *I* can personally see, there is no differentiation here between fluid types, so shouldn't this automatically render fluids made in Forge with half the brightness? Why is it failing to do so? And I've been looking really deep on this.

Well, there's two checks against water that I found in EntityRenderer that are intriguing. One creates a dark fog over the surface of the fluid (which is probably 90% of what I was looking for). This is found in setupFog():

            else if (j > 0 && Block.blocksList[j].blockMaterial == Material.water)
            {
                GL11.glFogi(GL11.GL_FOG_MODE, GL11.GL_EXP);

                if (entitylivingbase.isPotionActive(Potion.waterBreathing))
                {
                    GL11.glFogf(GL11.GL_FOG_DENSITY, 0.05F);
                }
                else
                {
                    GL11.glFogf(GL11.GL_FOG_DENSITY, 0.1F - (float)EnchantmentHelper.getRespiration(entitylivingbase) * 0.03F);
                }
            }

Then there's this... and I'm not entirely sure I see what it does. I added my own fluid to this if-check with Material.water and I couldn't tell a visual difference, but...

    /**
     * Changes the field of view of the player depending on if they are underwater or not
     */
    private float getFOVModifier(float par1, boolean par2)
    {
        if (this.debugViewDirection > 0)
        {
            return 90.0F;
        }
        else
        {
            EntityLivingBase entityplayer = (EntityLivingBase)this.mc.renderViewEntity;
            float f1 = 70.0F;

            if (par2)
            {
                f1 += this.mc.gameSettings.fovSetting * 40.0F;
                f1 *= this.fovModifierHandPrev + (this.fovModifierHand - this.fovModifierHandPrev) * par1;
            }

            if (entityplayer.getHealth() <= 0.0F)
            {
                float f2 = (float)entityplayer.deathTime + par1;
                f1 /= (1.0F - 500.0F / (f2 + 500.0F)) * 2.0F + 1.0F;
            }

            int i = ActiveRenderInfo.getBlockIdAtEntityViewpoint(this.mc.theWorld, entityplayer, par1);

            if (i != 0 && Block.blocksList[i].blockMaterial == Material.water)
            {
                f1 = f1 * 60.0F / 70.0F;
            }

            return f1 + this.prevDebugCamFOV + (this.debugCamFOV - this.prevDebugCamFOV) * par1;
        }
    }

Anyway, I'm still missing something. If you look carefully, you can see some kind of texture being rendered over the worldview when you are under water. You usually have to be looking for it to notice it. I can't figure out where this is rendered. If anyone happens across this, or just happens to know where it is, I'd be much obliged if you could inform me.

TheGreyGhost · December 17, 2013

Hi

It only renders the yneg face at half the brightness, the ypos face is at full brightness. One of the tricks minecraft uses is to render the different faces of standard blocks at different relative brightness - 1.0 for top, 0.5 for bottom, 0.6 for east west, or 0.8 for north south.

FOV stands for Field of View which means how wide your vision is. It is quite subtle, but if you pay close attention when you lower your head below the water, you will notice that you can only see a narrower view of the blocks (they get a bit wider so less fit into your display).

The semi-transparent "large-pixel" pattern that appears all over your screen when you're underwater is drawn in ItemRenderer.renderOverlays

        if (this.mc.thePlayer.isInsideOfMaterial(Material.water)) 
        {
            this.renderWarpedTextureOverlay(par1);
        }

-TGG

broede · December 17, 2013

Hi

It only renders the yneg face at half the brightness, the ypos face is at full brightness. One of the tricks minecraft uses is to render the different faces of standard blocks at different relative brightness - 1.0 for top, 0.5 for bottom, 0.6 for east west, or 0.8 for north south.

FOV stands for Field of View which means how wide your vision is. It is quite subtle, but if you pay close attention when you lower your head below the water, you will notice that you can only see a narrower view of the blocks (they get a bit wider so less fit into your display).

The semi-transparent "large-pixel" pattern that appears all over your screen when you're underwater is drawn in ItemRenderer.renderOverlays
        if (this.mc.thePlayer.isInsideOfMaterial(Material.water)) 
        {
            this.renderWarpedTextureOverlay(par1);
        }
-TGG

So it IS automatically rendering my under-fluid blocks with that darkness, I just didn't notice it for other factors. Once I added the fog effect that takes place OVER the surface (from underneath), it became a lot darker. And ItemRenderer... holy cow. Never would have suspected to find it in there. That's a great catch.

As far as I can tell, I've got everything I need to make a custom fluid. The only question I really have left is -- given where a number of these settings/effects are taking place, how would it be possible to make these additions without editing base classes? They just seem so deeply embedded in hard code, like the fog effects. Perhaps a forge hook I haven't come into contact with...

Anyway, this has been extremely helpful and I vastly appreciate it. Thank you so much!

TheGreyGhost · December 17, 2013

Hi

No worries, you're welcome :-)

Unfortunately I think you're right about how deeply embedded a lot of these effects are. Some of them you can cover by giving your fluid Material.water, if you're happy with the vanilla water effects, otherwise I reckon many of them would need base class edits.

Of course, if you ask nicely over at the suggestions forum http://www.minecraftforge.net/forum/index.php/board,4.0.html, they might add the hooks for you at the next release...

-TGG

broede · December 18, 2013

Great idea. I posted a thread over there -- let's hope they have time to get around to it for 1.7.

As for the tutorial... I'd feel more comfortable if and when they have hooks for the fog effects, though I suppose I could still discuss how to do it anyway, just with the caveat "this requires base class editing -- only do it for experimentation purposes" or something like that.

Sign In

Custom Fluid Help

Recommended Posts

broede

TheGreyGhost

broede

broede

TheGreyGhost

broede

TheGreyGhost

broede

broede

TheGreyGhost

broede

TheGreyGhost

broede

Join the conversation

Announcements

Recently Browsing

Posts

Topics

Who's Online (See full list)

Browse

Activity

Important Information