Include oredictionary entries scanner into forge

[SpwnX]

Basically, there are still modders who doesnt follow the standard convention for oredictionary names, registering items/blocks "improperly" causing compatibility issues.

GregTech, since 4.04d (Sep 24th) included a special code to detect those "invalid" entries and suggests fixes for them, although since it is only a particular mod, its range is severely limited, therefore I would like if forge included that feature of GregTech.

Example :

2013-10-19 17:42:23 [iNFO] [sTDERR] WARNING: 'diamondNugget' is an invalid OreDictionary Name. The Name doesn't fit to the Type of Item and/or doesn't follow a proper OreDictionary Convention. If you are the Owner of the Mod who adds this Item, please do the following: 
2013-10-19 17:42:23 [iNFO] [sTDERR] Put the 'Nugget' in the beginning of the Name to get 'nuggetDiamond'
2013-10-19 17:42:23 [iNFO] [sTDERR] Private Prefixes could also be a solution if the first Suggestion doesn't apply. In that case the suggestion for the name is 'Translocator:diamondNugget' don't forget to insert the ':' inbetween the Mod ID and OreDict Name, that is the most important part.
2013-10-19 17:42:23 [iNFO] [sTDERR] If you are not the Owner then report it to the Owner of the Mod, which the Item belongs to.
2013-10-19 17:42:23 [iNFO] [sTDERR] WARNING: 'obsidianRod' is an invalid OreDictionary Name. The Name doesn't fit to the Type of Item and/or doesn't follow a proper OreDictionary Convention. If you are the Owner of the Mod who adds this Item, please do the following: 
2013-10-19 17:42:23 [iNFO] [sTDERR] Put the 'Rod' in the beginning of the Name to get 'rodObsidian'
2013-10-19 17:42:23 [iNFO] [sTDERR] Private Prefixes could also be a solution if the first Suggestion doesn't apply. In that case the suggestion for the name is 'WR-CBE|Core:obsidianRod' don't forget to insert the ':' inbetween the Mod ID and OreDict Name, that is the most important part.
2013-10-19 17:42:23 [iNFO] [sTDERR] If you are not the Owner then report it to the Owner of the Mod, which the Item belongs to.

[M3gaFr3ak]

good idea

[SirusKing]

[iNFO] [sTDERR] WARNING: 'obsidianRod' is an invalid OreDictionary Name. The Name doesn't fit to the Type of Item and/or doesn't follow a proper OreDictionary Convention. If you are the Owner of the Mod who adds this Item, please do the following:  Put the 'Rod' in the beginning of the Name to get 'rodObsidian'
[sTDERR] If you are not the Owner then report it to the Owner of the Mod, which the Item belongs to. (Not a bug, just a suggestion)

would be shorter and Less spammy.

[smbarbour]

This is unnecessary.  There is no good reason to spam users about a non-issue.

[SpwnX]

This is unnecessary.  There is no good reason to spam users about a non-issue.

Of course there is, to automatically warn modders (via users, because there is no other way) about improperly registered items, that causes incompatibility issues.

 

@Whoever wants to read another drama regarding GT and TiC: Go to GT thread on IC² forum and grab some popcorn.

[mr10movie]

For the lazy

http://forum.industrial-craft.net/index.php?page=Thread&postID=134314#post134314

[artdude543]

I would agree with this being added, so many people don't use the dictionary properly and you get childish people who break other people's code to make there wrongly defined ores work. *Cough* Tinkers. If normal users don't want to see the "spam" then a config option could be added to not show it. Otherwise people should deal with it, and who even watches there console when loading/playing minecraft?

 

If not then something should be added for developers to see when adding to the dictionary to check whether they are using the correct name structure for the item/block/ore they are trying to register simple.

[jrockjake]

Are you fucking kidding me? Keep this in the Drecktech/IC^2 forums. 

[SpwnX]

Are you fucking kidding me? Keep this in the Drecktech/IC^2 forums. 

I didn't even mention TiC here, by the way.

Also, you just raged (ran out of arguments) there and got banned for insulting people.

No further comments are needed.

 

With this suggestion, i'm trying to help the whole modding community, by enforcing the standard convention, so we can have less problems regarding compatibility issues.

[smbarbour]

The whole "private prefix" notion is completely contrary to the point of the ore dictionary in the first place (which is to allow mods to specify interchangeable items).  My counter-proposal, therefore would be to print an opt-in list after all of the mods have loaded of the strings registered in the ore dictionary and the number of items registered to those strings.

 

Anyone interested in compatibility would have done research into the strings that were already in use.

[SpwnX]

The whole "private prefix" notion is completely contrary to the point of the ore dictionary in the first place (which is to allow mods to specify interchangeable items).  My counter-proposal, therefore would be to print an opt-in list after all of the mods have loaded of the strings registered in the ore dictionary and the number of items registered to those strings.

 

Anyone interested in compatibility would have done research into the strings that were already in use.

The private things are special cases, when the standard can't be applied and then must be registered that way to avoid unintended compatibility (Different items with same or close names). Example : GT gears and BC gears.

A standardization is required because nobody uses all mods at once, so there is kinda no way to get all registered things to be displayed to a modder for compatibility. Not to mention that it would bring extra work if everyone register the same stuff differently. Example "rodIron", "ironRod", and "rodFe" [Fe is the iron element]registered by three different mods for an iron stick (rod shape, 1/2 iron ingot of material).

[smbarbour]

A standardization is required because nobody uses all mods at once, so there is kinda no way to get all registered things to be displayed to a modder for compatibility.

 

If the modder cares about compatibility, load all the mods he or she cares to be compatible with and call OreDictionary.getOreNames(), and if they want to go even further, iterate over the string array that it returns to call OreDictionary.getOres(oreName) and get a List of ItemStacks.

[SpwnX]

A standardization is required because nobody uses all mods at once, so there is kinda no way to get all registered things to be displayed to a modder for compatibility.

 

If the modder cares about compatibility, load all the mods he or she cares to be compatible with and call OreDictionary.getOreNames(), and if they want to go even further, iterate over the string array that it returns to call OreDictionary.getOres(oreName) and get a List of ItemStacks.

Mod compatibility is meant to be global, not something restricted to certain mods. Guess what forge does, by allowing several different mods to run together, without any problems?

Standardization of oredict names allow cross-mod compatibility between mods even if they don't know the existance of each other, so the end user will never find incompatibility issues of items of the same type if both mods follow the standard.

 

So, this is not something unnecessary and not making mods follow the convention will eventually cause item incompatibility issues between mods, like GT and TiC rods are incompatible because of different oredictnames for same item.

[smbarbour]

A standardization is required because nobody uses all mods at once, so there is kinda no way to get all registered things to be displayed to a modder for compatibility.

 

If the modder cares about compatibility, load all the mods he or she cares to be compatible with and call OreDictionary.getOreNames(), and if they want to go even further, iterate over the string array that it returns to call OreDictionary.getOres(oreName) and get a List of ItemStacks.

Mod compatibility is meant to be global, not something restricted to certain mods. Guess what forge does, by allowing several different mods to run together, without any problems?

Standardization of oredict names allow cross-mod compatibility between mods even if they don't know the existance of each other, so the end user will never find incompatibility issues of items of the same type if both mods follow the standard.

 

So, this is not something unnecessary and not making mods follow the convention will eventually cause item incompatibility issues between mods, like GT and TiC rods are incompatible because of different oredictnames for same item.

In the example you list, GregTech chose to not use the names that were already in use.  Also, the code that GT uses specifically ignores a large number of entries that do not follow the guideline, such as bronzeTube, ironTube, obbyTube, leatherSeal, and stoneBowl

 

Bonus fact:  one of the entries in the list of specifically invalid names is in fact appropriate according to the guideline:  woodRod.  According to the guideline: "- For anything wooden, please use "wood", then the type"

[LexManos]

No, Forge doesn't have a standard naming policy, aside from the things that we name. It is up to the modders to agree on the naming policy themselves.

I understand the debate as it sits, however, this is purely a debate between modders, Especially in the manor that GT has decided to go.

The wiki is created by the communitty not us. But ya, the answer is no, unless I get a large group of modders who aproach me with a actual standard they ALL have agreed on.

 

When it comes to the oredict, either you use the names that other people use, or your shit wont be found.