Two Questions: CommonProxy Interface or Class? and Unlocalized and Registry Names

[admiralmattbar]

1. The Forge documentation suggests making the CommonProxy an interface implemented by Client and Server but I see a lot of mods made by great modders who make the common proxy a class that has it's own code that is then extended by Client and Server. Is there a good reason to do this? Why would someone not just put that code in their main class?

 

2. In 1.11 registry names no longer have the capital letter naming convention. Is there any reason not to just give them the same name and create a method that generates registry names for items that gets the unlocalized name? This seems like it would make things much easier but then why did they do it the other way for so long if it's a good idea?

 

Thanks for any replies. 

[Draco18s]

11 hours ago, admiralmattbar said:

1. The Forge documentation suggests making the CommonProxy an interface implemented by Client and Server but I see a lot of mods made by great modders who make the common proxy a class that has it's own code that is then extended by Client and Server. Is there a good reason to do this? Why would someone not just put that code in their main class?

I actually utilized the class version structure to create my EasyRegistry implementation before we had the registry events. I'm not saying it was better, but the hierarchical nature of the common periodproxy being a class meant that item registration (GameRegist.register calls) were in a common location and client only aspects were in the client subclass.

 

However, those methods were generic, they contained no references to outside objects (even the static methods only referenced the main mod class in order to get the proxy instance). All of my blocks and items were handled in the main mod class. 

 

Making that work with IStateMapper (and a few other things) was a hassle, but I managed it. 

 

11 hours ago, admiralmattbar said:

2. In 1.11 registry names no longer have the capital letter naming convention. Is there any reason not to just give them the same name and create a method that generates registry names for items that gets the unlocalized name? This seems like it would make things much easier but then why did they do it the other way for so long if it's a good idea?

Unlocalized name might change for subitems. Look at wool for example: each color had a different name, but the registration name is the same for all of them. Using getUnlocalizedName() for the regisrty name makes no sense. Mods should treat their items the same way. 

[admiralmattbar]

Thanks for the replies!

 

Quote

Unlocalized name might change for subitems. Look at wool for example: each color had a different name, but the registration name is the same for all of them. Using getUnlocalizedName() for the regisrty name makes no sense. Mods should treat their items the same way.

 

Okay, this is exactly what I was looking for. It makes sense why they do different names.