Dirt Slabs have wrong colour with MCPatcher

[Mesh]

Ah well, that's a shame but its completely understandable. I for one appreciate the effort to try and fix it!

[FlowerChild]

Ah well, that's a shame but its completely understandable. I for one appreciate the effort to try and fix it!

Thanks man. I really did want to try and sort it for you guys, and will continue thinking about it in the background.

[ko_teknik]

Well, that's it then. If it's something that occurred between 4.A6 and now, I'm all out of ideas as to what it could reasonably be. We're at the point of "you just can't change the code and expect it to still work", because I've tried everything I can think of that might be related.
The unfortunate reality of the situation is that you guys are using a no longer maintained utility that modifies the existing code, while I am continuing to change the code that it modifies. Given that, something will inevitably break eventually.
3+ hours is way beyond the time I should have spent on this already.

Before the version 4.A6 BTW, dirt slab could not stand custom biome color... we had to delete 2 files to get it working.

and now another bug, but i think we can solve it with an older version of mcpatcher..
or maybe if we replace dirtslab.class after patching !

In any case thank you to have try !

[Mesh]

Before the version 4.A6 BTW, dirt slab could not stand custom biome color... we had to delete 2 files to get it working.

Thats a problem I fixed and I can help you over in the Texture forum. I'm also going to do a bit of work on a texture workaround for this grass slab bug and I'll post the solution over there, it won't be perfect by any means but it will serve as a stopgap measure.

[FlowerChild]

You're welcome guys. Wish it could have turned out better.

I just removed the downloads for all test versions in this thread, to avoid potential confusion.

[Gilberreke]

Thanks for the massive effort troubleshooting FC! This solves us a lot of time and effort tracking things down ourselves

To everyone: The MCPatcher issue is a long-standing issue the community will have to solve eventually. I know a lot of people bank on having texture support and this is the only tool we have to enable them properly. I've looked into it a few times, the code is open source here:
https://bitbucket.org/prupe/mcpatcher

What would need to be done:
- Make it easier to install, currently, there are multiple versions floating around with multiple install configurations and none of them work well with certain tools like MultiMC. I have a few ideas on this part and there's been some work by other members in this forum already
- Figure out a way to tailor its patch-mods to BTW. This involves someone learning how to write these patch-mods, how to generate the patches and be able to troubleshoot and help others to write patches

If I ever figure out any progress on this issue, I'll post a new thread somewhere. I encourage everyone who is interested in the topic and knows how to program to do the same thing.

[jorgebonafe]

Ok, so I tested this dirt slab thing with the latest MC on the Sphax TP, and nothing appears to be wrong...

Spoiler

Show

Which is weird, because I didn't apply any fixes to this on the texture side, and someone reported this not working to me the other day.

Am I missing something? Does this bug only happens on some special circumstance I'm not considering?

Edit. I did not use Better Grass on my MCPatcher options. Is this the reason? This bug only shows up when using Better Grass?

[dawnraider]

I've never used better grass and I get it, both using Conquest and using the default.

[Gilberreke]

Jorge: you're probably using an older version of MCPatcher, I think it only happens on newer versions

[jorgebonafe]

Just passing along what we discussed on twitch. Yeah, I'm using MCPatcher version 3.0.4_02. So I guess that's the reason.

[gaga654]

I looked into this a little, and I think I found the problem. It's nothing to do with RenderBlocks at all. MCPatcher has some BTW-specific code in it that tells it to treat the dirt slab like a grass block, and a recent change to the FCBetterThanWolves class meant that it wasn't able to find the ID of the dirt slab in the same place that it used to. I don't think it's that difficult to fix on MCPatcher's end, but I wouldn't know how to go about actually updating/rebuilding MCPatcher after changing it in the source. Also since it's BTW-specific it's sort of in BTW add-on territory, so I wouldn't want to do anything without FC's permission here.

[FlowerChild]

I looked into this a little, and I think I found the problem. It's nothing to do with RenderBlocks at all. MCPatcher has some BTW-specific code in it that tells it to treat the dirt slab like a grass block, and a recent change to the FCBetterThanWolves class meant that it wasn't able to find the ID of the dirt slab in the same place that it used to. I don't think it's that difficult to fix on MCPatcher's end, but I wouldn't know how to go about actually updating/rebuilding MCPatcher after changing it in the source. Also since it's BTW-specific it's sort of in BTW add-on territory, so I wouldn't want to do anything without FC's permission here.

The BlockID hasn't changed, so what has that it can no longer identify it?

I had thought that it might be some kind of class signature, so I tried changing back the hierarchy that class was dependent on, and that didn't seem to help. I had previously changed a parent class (FCBlockSlab) of FCBlockDirtSlab from abstract to a full on base class as I was implementing a number of other slabs that relied on near identical functionality and wanted to unify all the code for them.

But given I tried reverting everything I could think of that might identify the class, I eventually gave up on that idea. If you know what it is specifically that is used to identify the class by MCPatcher, I could probably finally fix this.

[Niyu]

I think I've found it.

The code MCPatcher uses to get the dirt slab is:

Code: Select all

        Block block = null;
        try {
            Field field = Class.forName("FCBetterThanWolves").getDeclaredField("fcBlockDirtSlabID");
            field.setAccessible(true);
            block = BlockAPI.getBlockById(field.getInt(null));
        } catch (Throwable e) {
        }
        fcDirtSlab = block;

and in 4.A7 this line has been removed(comparing it to the 4.A6 code)

Code: Select all

private static int fcBlockDirtSlabID;

since instead uses a more elegant map as a cache.

I haven't been able to test it, but with MCPatcher, the block is used in a condition to change the color multipliers.

Code: Select all

        } else if (fcDirtSlab != null && block == fcDirtSlab) {
            colorMultiplierType[0] = COLOR;
            colorMultiplierType[2] = COLOR_AND_NONCOLOR;
            colorMultiplierType[3] = COLOR_AND_NONCOLOR;
            colorMultiplierType[4] = COLOR_AND_NONCOLOR;
            colorMultiplierType[5] = COLOR_AND_NONCOLOR;
        } else {
            colorMultiplierType[0] = COLOR;
            colorMultiplierType[2] = COLOR;
            colorMultiplierType[3] = COLOR;
            colorMultiplierType[4] = COLOR;
            colorMultiplierType[5] = COLOR;
        }

[FlowerChild]

I think I've found it.

Wow dude. Nicely done. That makes total sense and I never would have worked that out through guess work. The ID map was the last culprit I would have thought of.

Ok, so easy enough to fix. I can just recreate that specific ID field, and set it with a duplicate value from the ID map.

I'm way too far into working on the next release to feasible recompile a quick fix for it though, and even if I do, there's no guarantee that alone will do the trick given all the other changes I made in recent releases. I'll make the change to workaround it but I'd urge people not to rely on me being able to fix such problems in the future.

You're really sitting on a ticking time bomb with BTW and MCPatcher compatibility that needs to be resolved in some other way. So I really hope that if I'm able to resolve this specific issue for you guys on my end, it doesn't derail efforts to find other solutions.

[Niyu]

I mainly work looking at java code that doesn't work and figuring out why. With the pointers from gaga654 it was quite easy.

And don't worry about it, I completely understand that in any time using MCPatcher could stop being feasible and have no problem with it. I only use it for that vanilla CTM pack magikeh released and i could perfectly live without it.

[FlowerChild]

Can someone with this issue give this a try?

Papa needs a new pair of oysters!

I realized that I could jury-rig a version since this change only affects one file.

[dawnraider]

When I tried launching the game, it froze and wouldn't actually launch. When I killed the process, it returned the crash log below. Reverting to 4.A9b did not produce this.

Spoiler

Show

Code: Select all

MultiMC version: 0.5.2-1096


Minecraft folder is:
instances/BTW1/minecraft


Java path is:
C:/ProgramData/Oracle/Java/javapath/java.exe


Java is version 1.8.0_161, using 64-bit architecture.


Traits:
  texturepacks
  legacy-instance

Mods:

Window size: max (if available)

Java Arguments:
[-XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump, -Xms512m, -Xmx4096m, -Duser.language=en]


Minecraft process ID: 4312


Using onesix launcher.

Launching with applet wrapper...

MCPatcherUtils initialized:
Minecraft directory: C:\Users\Braden Moore\AppData\Roaming\.minecraft
  (assets, libraries, versions)
Game directory:      C:\Users\Braden Moore\AppData\Roaming\.minecraft
  (resourcepacks, saves)
Minecraft version:   1.5.2
MCPatcher version:   5.0.3
Max heap memory:     3641.0MB
Max direct memory: 3641.0MB
WARNING: configuration file C:\Users\Braden Moore\AppData\Roaming\.minecraft\mcpatcher.json not found, using defaults
java.io.FileNotFoundException: C:\Users\Braden Moore\AppData\Roaming\.minecraft\launcher_profiles.json (The system cannot find the path specified)
	at java.io.FileInputStream.open0(Native Method)
	at java.io.FileInputStream.open(Unknown Source)
	at java.io.FileInputStream.<init>(Unknown Source)
	at java.io.FileReader.<init>(Unknown Source)
	at com.prupe.mcpatcher.JsonUtils.parseJson(JsonUtils.java:46)
	at com.prupe.mcpatcher.Config.getSelectedLauncherProfile(Config.java:99)
	at com.prupe.mcpatcher.Config.load(Config.java:74)
	at com.prupe.mcpatcher.MCPatcherUtils.setMinecraft(MCPatcherUtils.java:447)
	at net.minecraft.client.Minecraft.<init>(Minecraft.java:289)
	at avv.<init>(SourceFile:38)
	at net.minecraft.client.MinecraftApplet.init(SourceFile:38)
	at net.minecraft.Launcher.init(Launcher.java:109)
	at org.multimc.LegacyFrame.start(LegacyFrame.java:66)
	at org.multimc.onesix.OneSixLauncher.legacyLaunch(OneSixLauncher.java:124)
	at org.multimc.onesix.OneSixLauncher.launch(OneSixLauncher.java:292)
	at org.multimc.EntryPoint.listen(EntryPoint.java:162)
	at org.multimc.EntryPoint.main(EntryPoint.java:53)
WARNING: could not determine selected profile, defaulting to MCPatcher
Launcher profile:  MCPatcher

228 recipes
27 achievements
...Add-On Handler Initializing...
Better Than Wolves Version 4.A9 Pustules Lancing C Initializing...
BTW reading custom config file...
Exception in thread "main" java.lang.NoSuchFieldError: fcSawDust
	at FCRecipes.AddItemRecipes(FCRecipes.java:905)
	at FCRecipes.AddAllModRecipes(FCRecipes.java:16)
	at FCBetterThanWolves.Initialize(FCBetterThanWolves.java:603)
	at FCAddOnHandler.InitializeMods(FCAddOnHandler.java:51)
	at net.minecraft.client.Minecraft.<init>(Minecraft.java:304)
	at avv.<init>(SourceFile:38)
	at net.minecraft.client.MinecraftApplet.init(SourceFile:38)
	at net.minecraft.Launcher.init(Launcher.java:109)
	at org.multimc.LegacyFrame.start(LegacyFrame.java:66)
	at org.multimc.onesix.OneSixLauncher.legacyLaunch(OneSixLauncher.java:124)
	at org.multimc.onesix.OneSixLauncher.launch(OneSixLauncher.java:292)
	at org.multimc.EntryPoint.listen(EntryPoint.java:162)
	at org.multimc.EntryPoint.main(EntryPoint.java:53)
Process was killed by user.
Clipboard copy at: 02 Mar 2018 17:09:14 -0700

[FlowerChild]

When I tried launching the game, it froze and wouldn't actually launch. When I killed the process, it returned the crash log below. Reverting to 4.A9b did not produce this.

Ug... yeah, forget that then. Will unfortunately need to wait until next release. Looks like I've already changed a bit too much under the hood for a quick patch, as I had initially feared.

Thanks for trying it though! I'll take down that download link.

[gaga654]

I think I've found it.

Yeah, that's the part I was talking about. Forgive me for not explaining it better, I was quite tired when I wrote that post.

As for mcpatcher, it works by doing a very granular "find and replace" routine on the java bytecode, which is why it's been so robust up until now.

Edit: I've been messing around with editing MCPatcher and when I changed that line to be hardcoded to id 206 (dirt slab), the problem was resolved. So adding the "fcBlockDirtSlabID" should almost certainly fix things. (The reason that it's necessary for mcpatcher to read it from the file in the first place is that it won't necessarily be 206 if you edit the ids in the config file.)

For those who don't want to wait until the next BTW release, here's a version of mc patcher with the aforementioned hack. As mentioned, this won't work if your config is edited so that dirt slabs have a different block id.

[Whuppee]

Thank you all for your work in figuring this out and to gaga654 for the mcpatcher edit!

[FlowerChild]

If someone could let me know if 4.AAAAAAAAAAHHHH fixes this, I'd be much obliged. Amongst everything else, I included the aforementioned fix attempt as well.

[Whuppee]

I just did a clean install with normal mcpatcher (not gaga's edit) and my grassy dirt slabs look great. Thank you! =)

[FlowerChild]

I just did a clean install with normal mcpatcher (not gaga's edit) and my grassy dirt slabs look great. Thank you! =)

Excellent! Thanks for the confirmation :)