Since Tinker's Construct 1.7.10 was put aside to focus on development of the 1.8 version, I've tried to use this mod to maintain the mining progression using vanilla tools instead. So far, it seems to be more or less successful. However, there is still a glitch I need to fix before I do any releasing for my modpack.

While I was working on this, I had decided to swap tin and iron in the progression order. However, I am unable to figure out how to switch them in the tooltips. Is there a specific method to correct the tooltips enough so that the altered order is reflected (Copper pickaxe mines tin, and bronze pickaxe mines iron)?

By setting the correct harvestlevel names?

No.

Okay, so I'm doing it correctly, but the tooltips still show incorrect levels.

ToolOverride.cfg:

thermalfoundation {

. . . 

    tool_pickaxecopper {
        I:pickaxe=2
    }

. . .

}

HarvestLevelNamesOverride.cfg:

HarvestLevelNames {
    S:Level2=Tin
    S:Level3=Iron
    S:Level4=Diamond
}

And copper, which should now show "Tin" for its mining level, is still showing the original level 2 harvest level (Iron).

I thought I did that, although maybe I misunderstand...

In "HarvestLevelNamesOverride.cfg", I have the following lines:

HarvestLevelNames {
    S:Level2=Tin
    S:Level3=Iron
    S:Level4=Diamond
 }

Am I doing this incorrectly?

It is. However, the meaning of "no" is defined by the context, In this case, I read the answer as a negative of my question, "Am I doing this incorrectly?" Since "incorrect" means "wrong, I took it to mean I was doing this correctly, or right. If your meaning is different, then please clarify.

I actually read that as "Am I doing this correctly". That was confusing, yes.
Yes you're doing it wrong.

Okay... what am I doing wrong?

Still not reading the huge comment at the top of the file that explains how to use it.

Well, that's unexpected. I figured the meaning of "no" was well defined.

Try turning on logExcessiveOverrideChanges in the main config. It should make lines like Harvest Level Name Override: Changed Level %s to %s get printed to the log.

I can't get this to work regardless. I've tried the following variations:
HarvestLevelNames {
Level3=minecraft:redstone
Level4=minecraft:diamond
}

HarvestLevelNames {
S:Level3=minecraft:redstone
S:Level4=minecraft:diamond
}

HarvestLevelNames {
Level3=Redstone
Level4=Diamond
}

For kicks and giggles, I even cut and pasted the sample Level5=minecraft:emerald, but that also doesn't work.

I've read the instructions on the headings multiple times. I've changed the levels using the text, using registered names, both inside and outside the harvestlevelnames and materialnames namespaces, and with and without the "S:" prefix. I've even attempted to rearrange the material names in the opening comments of the override files with them on them. I apologize if I'm annoying, but I am completely out of ideas, and nothing I've read on the configuration files are helping.

Owch. All this time, I thought it was the harvestlevel names being ignored. Now I can see it's the block harvest level overrides being ignored. Two steps forward, one step back. Thanks for the help; let's see if I can make something of this.

Okay, here's what I've come across. First of all, here is the BlockOverride.cfg file as I have it:

http://pastebin.com/bhzQs6b6

Here is the log of overrides, ending with a caught exception:

http://pastebin.com/g1vmVHVY

I'd suspect the exception is part of the problem, except, as you might notice in the log, despite my consistently assigning level 3 to iron and level 2 to tin in the configuration file, iron was still overriding to 2, and tin to 3, in the log. No names were referenced, much less changed.

Hm, it seems like the actual exception message is being hidden due to reflection, unfortunately. There's something going wrong in this block during the "BlockOverride" phase, but it re-throws the exception and Mantle only seems to catch it as a InvocationTargetException because the exception was thrown inside a Method.invoke call.

Either IguanaOverride should print the stacktrace or Mantle should handle InvocationTargetExceptions by unwrapping them before printing the stacktrace (ex.getTargetException().printStackTrace()).

For now, it's hard to tell what's going wrong, except that it has to do with the default BlockOverride config.

See #180

@bonii-xx, you could not re-throw the RuntimeException to allow the pulse to continue even if one override config fails to generate/process. Why should one thing erroring stop execution of all the following things?

Because people are supposed to fix their shit. :P

Right, but broken things shouldn't be able to break unrelated things. I'd argue that one of two things should happen:

• Error is caught in IguanaOverride, printed, and not re-thrown. Executing continues as normal
• Error is re-thrown in IguanaOverride and not caught by Mantle, causing an actual crash

The way it works currently is the worst of both worlds: it breaks more than it should and it's not obvious that it's blocking execution of other, seemingly unrelated code (that is, it doesn't actually crash).

It should indeed not be rethrown. That was an oversight.