And again I with my localization problems. @squeek502 ExtraTiC uses part.partname.materialname template for its localization but that seems TiC Tooltips looking for toolpart.partname.materialname template from Tinkers Construct and can't find ExtaTiC's one because they are different. Is it a thing that you can fix on your side or I'm again wasting your time?

Where does this end up showing up? I'm pretty sure TiC Tooltips defers all localization of tools/tool parts/materials to Tinkers Construct code or item.getLocalizedName() now.

Maybe to support ExtraTiC some extra code will be required. I've translated almost all ExtraTiC names using custom names (3873 lines).
Example: Tartarite Rapier made out of Tartarite Sword Blade, Tartarite Crossbar, Tartarite Rod.
Search for Tartarite Sword Blade results in "Тартаритовое лезвие меча" (This is correct item name)
But when you press Ctrl to check the materials of which rapier is made you'll see "Тартаритовый лезвие меча" (This is incorrect name)

Okay, yeah that's on ExtraTiC's side. All I do is call itemStack.getDisplayName().

ExtraTiC implements its own part class with its own getItemStackDisplayName/getUnlocalizedName methods. From decompiling ExtraTiC:

snipped as requested by Glassmaker

ping @Glassmaker !

Here's the Tinkers Construct implementations of those same methods for comparison.

But maybe you can support ExtraTiC method? Because if @Glassmaker change this to Tcons method... well, I think I will need to change 3k lines of my localization. I'll die when I complete it.

Hm, I didn't see that you said it gets the correct name for the part itself. Something weird is going on if that's the case, because that should use the exact same methods...

Will look into it further.

Okay, here's what's going on:

• ExtraTiC adds its own IToolPart implementation, and then manually adds recipes for casting materials to create those parts. So, when you pull an ExtraTiC part out of NEI or create it manually, you get an instance of ExtraTiC's Part class.
• When you create a tool using an ExtraTiC Part, it then becomes a Tinkers Construct DynamicToolPart internally, which does not have the same properties (tool.getHeadItem() will return a DynamicToolPart instance). This then uses the Tinkers Construct implementation of getItemStackDisplayName, so the localization ends up differently.

The problem here is that I'm not sure there's a good way for me to convert a DynamicToolPart into its ExtraTiC Part equivalent without a lot of hackery that I'd really rather avoid (something like create an unlocalized name -> Part translation map).

The reason I don't want to do this is because, as far as I know, all of what I talked about above (ExtraTiC implementing its own Part and manually registering casting recipes) is totally unnecessary. @bonii-xx added methods to the API that makes part registration/casting/etc totally automatic. See, for example, how I register plastic in The Vegan Option. @Glassmaker might have some reasons for not using those methods, but I don't know what they are. ExtraTiC remaining closed source after multiple years of promising that it would go open source really makes it hard for me to tell...

May as well reopen as its not really resolved.

Well, if there are no easy way to support ExtraTiC methods. ExtraTiC should go for Tinkers implementation.

Yeah, like @bonii-xx have mentioned, my own parts are made before tinkers 1.7.x for 1.7.10 therefore Dynamic toolparts weren't there when I made my parts, and converting them to the new system means users will be losing their parts, so I decided to keep my implementation of IToolPart.

A workaround is to get the name with ExtraTiC parts when the material ID is 100-199 and 2000-2999, the Damage of the item is the same as the material ID.

Another way, is to cache tinkers' recipes, and use that to get the part names, as you can match the material ID with IToolPart.getMaterialID().

Also @squeek502 , as ExtraTiC is copyrighted software, you shouldn't post decompiled source code, so can you kindly remove the pasted code above?

I have an idea of how I could do it. I already aggregate the ExtraTiC parts, so adding a bit extra to that and then checking the mat ID range as you suggested should work.

Removed the code as requested.

Awesome :D

And, Thank you :)

To add to that, the separate parts in Extra-TiC are a relict from the time before the TCon ones were expandable like that.

hmm ....
Although so I'm not from the Java corner - but that's for "cumbersome" ...
always the same code - only 1 part changes ....

it is not much more effective to create an array and execute the whole action by loop? The array can then even invite "external" and the code is clearer and slimmer ...

private String[] TiCParts = {
"PICKAXE_HEAD", "SHOVEL_HEAD", "EXCAVATOR_HEAD",
"HAMMER_HEAD", "AXE_HEAD", "SCYTHE_HEAD", "LUMBERAXE_HEAD",
"SWORD_BLADE", "LARGE_SWORD_BLADE", "KNIFE_BLADE",
"FRYPAN_HEAD", "BATTLE_SIGN_HEAD", "CROSSBAR",
"MEDIUM_GUARD", "LARGE_GUARD", "FULL_GUARD",
"BINDING", "TOUGHBIND", "TOOLROD", "TOUGHROD",
"LARGEPLATE", "CHUNK", "ARROWHEAD", "TOOLROD",
"CHISEL_HEAD", "SHURIKEN", "BOW_LIMB", "CROSSBOW_LIMB",
"CROSSBOW_BODY", "BOLT"
};

int size = TiCParts.length;

for ( int i=0; i<size; i++ )
{
part = (Item) ExtraTiCPartsHandler.getDeclaredField(TiCParts[i]).get(null);
extraTiCParts.add(part);
ToolPartHelper.boltParts.add(part);
}

untested .....

from 140 lines to 20 lines :)

@ReneMuetti, you skipped over each part needing to be added to a different ToolPartHelper list. It would still be possible to compress the code by creating a Map<String, List<Item>> and iterating that, but it's not too big of a deal.

As I write'm lazy, it's just a lot to me. I am jein Java developers. Therefore, I have probably not read it properly. But I'm pretty sure that there is associated also with Java arrays. Thus, the care would massively improve in my view.

It was not in my interest to criticize your developments. I only want to make a suggestion.

I myself come from the PHP corner - dorch I would deal with the whole with an array and a foreach loop. It would massively improve the maintenance and readability of the code.

I do not like "duplication" :)

@ReneMuetti, you're totally right that it can be improved. That particular piece of code was written a long time ago when I was still new to Java.

Fixed. Thanks!

Thanks for confirming. Will release an official version tomorrow.

For reference, fixed by a53608d

I have recorded the version.
There are some properties (modifiers) not translated.
In places, it also affects Vanilla properties

@Adaptivity, can you confirm that this build fixes the issue?

TiCTooltips-mc1.7.10-1.2.5-test.jar

I have my update anyway MC server today ...
Then I would look at the same time with :)