[1.15.2] Unlocalized names

[Purplicious_Cow]

On diesieben07's great issues and recommendations post (linked below), item #7 reads: 

 

7. Do not use the unlocalized names for things other than displaying the name of a block/item. If you want to access the registry name for a registry entry, use IForgeRegistryEntry::getRegistryName.

 

Can someone explain why this is an issue? I have some small bit of code doing this now, and have not experienced any issues....

 

 

 

Edited December 13, 2020 by Purplicious_Cow

[Draco18s]

Unlocalized names are for display purposes. The registry name is what identifies the item with the game.

 

Which one makes more sense to be the primary key?

[Purplicious_Cow]

Yes, clearly the registry name, which I will change going forward (on the versions I can still do so), but that was not my question. You are hinting at a Client vs. Server issue, but not quite. This method has been in the Inventory Pets code since 1.7.10 and players have not seen issues. Is it simply a recommendation to avoid future deprecation, or is it just a performance recommendation? Was hoping for a technical answer.

 

 

Edited December 13, 2020 by Purplicious_Cow

[Purplicious_Cow]

48 minutes ago, diesieben07 said:

That said - neither of these are particularly good ways to check for a specific item. Instead you should just check against a known Item instance, for example someStack.getItem() == Items.BUCKET to check for a bucket.

Thanks diesieben07. I use the getItem() method for 99.9% of cases. I had used the unlocalized name in earlier version of inventory pets to check cross-mod (e.g., identifying the bosses from OreSpawn for example, or to avoid conflicts with other mod items). The fact that the unlocalized name can change is a good reason to use getRegistryName().

 

Thanks both for filling in the gaps.

[Purplicious_Cow]

Ahhhhh! Brilliant. Thank you. I didn't realize you could create a dummy register object from another mod.

Edited December 13, 2020 by Purplicious_Cow