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.
hardcoded
Now I understand. That’s sad. I guess I found it in main/java/gregtech/blocks/fluids/BlockSwamp.java, is that it:
@Override public int getRenderColor(int aMeta) {return 0x0000ff00;}
@Override
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.
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” ?
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:
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. 
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/gregtech_1.7.10-6.15.01-defaultConfigPack.zip’.
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) {
from('./.defaultconfigs/')
include('**/')
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 
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.zip 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-8.62.0.19_1, 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… >.>
As I mentioned above, the problem is that zip doesn’t create intermediate directories. If you run it like this zip build/libs/whatever.zip whatever.zip it won’t create libs directory, but will spit an error. I did it manually and it worked for me.
Maybe, Gradle has it’s own implementation of zip somewhere, and I did install one from my system repos, and mine doesn’t create directories if they don’t exist (or it needs a specific flag to do so).
I tried manually removing build and then running ./gradlew build: it yields the same error. Again, manually created libs directory solves this problem.
If you need it, I logged ./gradlew build --stacktrace and ./gradlew build --debug with removed build directory.
Gradle doesn’t use the system zip, it uses the zip functionality exposed by the Ant build tool, which wraps the java built in zip handling, which just like Ant’s zip call does create paths as necessary.
Doesn’t touch system binaries at all, it’s all built in to java. Hmm, what precise version of Java are you using? (via java -version)
Yeah same as I saw on the github CI as well, doesn’t really tell the cause though sadly…
openjdk version “1.8.0_342”
OpenJDK Runtime Environment (build 1.8.0_342-b07)
OpenJDK 64-Bit Server VM (build 25.342-b07, mixed mode)
Yeah I had the same in my tests, no clue, I’m leaning back to something about the filesystem I guess… What is your filesystem?
Either way, I pushed a workaround into the latest HEAD.