How To Change Dirty Water Texture?

I thought to make it more dull and shift hue to blue a little bit (or to red, to make it more dirty and torfy) since that contrast between common and swamp water sticks in the eyes, but I can’t find a way to do it. I didn’t find that texture in .minecraft/mods/gregtech_1.7.10-6.15.01.jar. If you could tell me how to do it, or even give me a texture pack with a default dirty-water texture so I can edit it, I would be grateful.

By the way, I already use a texture pack, which I found here, for more dull stones (especially for that void-black granite), and I suggest to change original textures to be like in that pack.


And I know that I can simply turn off swamp colors in settings, but that’s not the point.


I take the Vanilla Water Texture and make it greener, that is basically what I do, just like Vanilla does it with Biome Colors.

1 Like

What for? Vanilla texture is better, imo. So how can I change it back to default color?

Also, speaking of contrasts, right now I’m mining pyrolusite in basalt—my eyes never had such a strain. Dark dull purple embeds in black.

I bet you can’t see it.


It is all color and not texture based, so there will be coincidences where the ore is barely visible.

1 Like

just like Vanilla does it with Biome Colors.

At first I thought you just changed color-map for swamp, as you said it. So I’d copied default resource pack from vanilla jar-file, loaded it and nothing changed. Then I changed water texture with no result again. So it is not simple water, it’s a different fluid, Dirty Water, with its own texture, but I can’t find it anywhere in your jar-file. I searched for dirt and swamp. Please, help me locate where it is.


Again it is the Vanilla Water TEXTURE with a manually applied hardcoded Color. Yes it is its own dedicated Waterlike Block, but it still uses the vanilla Texture.

1 Like


Now I understand. That’s sad. I guess I found it in main/java/gregtech/blocks/fluids/, is that it:

@Override public int getRenderColor(int aMeta) {return 0x0000ff00;}
public int colorMultiplier(IBlockAccess aWorld, int aX, int aY, int aZ) {
  if (aWorld.getBlock(aX, aY+1, aZ) ==this) return 0x0000ff00;
  if (water(aWorld.getBlock(aX+1, aY, aZ))) return 0x0060ff60;
  if (water(aWorld.getBlock(aX-1, aY, aZ))) return 0x0060ff60;
  if (water(aWorld.getBlock(aX, aY, aZ+1))) return 0x0060ff60;
  if (water(aWorld.getBlock(aX, aY, aZ-1))) return 0x0060ff60;
  return 0x0000ff00;

Is color encoded in ARGB here? Or what does these first two zeroes mean? Are those 0x0060ff60 for block bordering common water, like on that screenshot above.

And do you remember what was the default color?


Default is 0x00FFFFFF, because the Water Texture is normally Blue, so I had to overcompensate the green.

1 Like

I finally managed to compile it. It took some time for me as I know nothing about Java. I used the default color just to see what it will look like. Everything is okay, except that I can’t load my world, but can create a new one. I guess it’s because of different versions, it’s 6.15.01-50-g0418316c-dirty on your Github, and I need just plain 6.15.01. Where could I get source code for this version?


I’ve just found sources on your site, but I have no idea how to compile it. I’ve tried to replace src directory from the github repo with it, and then compile, but it yields an error.


isn’t it a simple “./gradlew build” ?

1 Like

There is no Gradle in that one. I think I downloaded a wrong one, just sources, and should have downloaded Dev.

UPD: No, there is no Gradle in this one too.



I replaced src/main/java/gregtech and src/main/java/gregapi from your Github with the corresponding directories from sources I downloaded from your site. It’s compiled fine and my world can be loaded with it. The only minor problem is that it still displays its version as ‘dirty’.

Here is what I’ve got after several tries:

It’s hard to choose the right color, because I have no idea how it’s applied.


Finally I can enjoy my swamp. It still doesn’t blend with that river well, and the only way to fix it is to loose its greenish color, but then it will not look like dirty water at all. Or add more if-statements there that will check for water around in a larger radius, but that would be clumsy.

It blends more nicely with ocean water.


You git clone it from github, then edit and ./gradlew build from there. That image is just downloads. Mod is the mod itself. Changelog is that changelog version. Defaultconfigpack is just the default config pack as of that version, Dev is the development linking library jar (for developers making mods on top of gt6, and Sources is the development sources library jar (again for developers making mods on top of gt6). For modifying GT6 itself you git clone it from github as it is a fully self-contained standalone ready-to-build project, very frictionless compared to basically any other mod anywhere. :slight_smile:

1 Like

The “problem” was that Github contains “only” the newest version, and I needed the 6.15.01 with Gradle build environment (or what’s it called). And shame on me, I really forgot that I can simply clone the repo and then rollback it to a specific commit—that’s what I’ve done now, but Gradle won’t compile the mod and spits me the error that it can’t zip default config pack (I can’t provide exact message right now). All I did is I cloned the repo, hard reset it to e02e9b01015e43dcd86f2bbae03fd86999a0b651 commit, and run Gradle like this: ./gradlew setupCIWorkspace assemble.

I’ve removed Gradle’s dotdir in my home directory and it compiled as normal.

Lol, I’ve just mixed up two repos. 6.15.01 doesn’t compile for me:

Execution failed for task ‘:defaultConfigPack’.
Could not create ZIP ‘./build/libs/’.

That’s a bit strange.

I’ve also tried replacing Zip with Tar in build.gradle, but it fails in the exactly same way.

task defaultConfigPack(type: Tar) {
	classifier = 'defaultConfigPack'
	destinationDir = new File('./build/libs/')

Execution failed for task ‘:defaultConfigPack’.
Could not create TAR ‘./build/libs/gregtech_1.7.10-6.15.01-dirty-defaultConfigPack.tar’.


I manually created build/libs directory and it compiled well. What’s the fuck :confused: Lucky me that I had some intuition telling me to do this.

I do not remember I did this the last time I cloned the repo and then, to my shame, pasted sources from your site in there.

Zip doesn’t create intermediate directory if you do it like this: zip build/libs/ whatever. So why did it worked for me before?


We recently had this exact same failure on GitHub, something weird must have fucked up and we dont know what…


No it doesn’t, it contains every GT6 version going back many years since greg started using git. 6.15.1 is even a specific tag at that.

That’s one of the big whole purposes of git, lol.

Yeah I’ve heard of that happening on some systems but I need to be able to replicate it. At least you found the workaround, but I’d really like to know what’s up as it doesn’t seem based on java version or gradle version or anything…

Hmm… machine… I wonder if it breaks on low core machines…

Just testing… yeah it compiles fine 16 cores, trying it again with just 1 core as a pristine checkout again, aaand nope, so its not a race condition…

What if I try to just run the defaultConfigPack task with a completely missing build directory… aaaand nope, the Zip task does indeed create the parent directory first as it should…

Tried it on adoptopenjdk-8.0.345+1 above, trying adoptopenjdk-8.0.302+8, same result, trying zulu-, same result…

I can’t replicate the issue… wtf… >.>

It has to be something machine specific, need to find out ‘what’ that machine difference is so I can try to replicate it…

And yes, the build was wiped completely before every run.

Frick I hate java… Have I ever mentioned how much I hate Java? It’s whole ecosystem is just such astounding garbage… >.>

1 Like