A suggestion about automating object registration

[ZDoctor]

Registering items/blocks/etc is a real hassle, and usually big mods add their own support for registering a bunch of items. Which can be broken with an update. Perhaps it would be better if forge automated that process instead. I worked on such a system that may help.

 

For some time I worked on a mode called LazyModder and now LazyLibrary. The goal of the mod was to make modding easier for modders by handling a lot of the repetitive stuff when it comes registration of items/blocks/entities/etc.

 

I was successful and even made a few mods that use the lib, but I think it would be better if it was built in. I will explain a few of the classes and implementation could be as simple as adding all the classes so modders can have the option of using them, or just adding the methods, interfaces, etc directly to the item class. I am a proponent of the former option.

 

My library adds several classes on which others are built upon and has 2 classes dedicated for handling registration of the objects and their models. With an additional class dedicated to handling sorting the objects for registration and is the parent of the last two classes so that register objects are more readily available (similar to a proxy).

 

The EasyRegistry(GitHub) class is has a register method that takes in an IAutoRegister. These classes should automatically register themselves here and modders can do it manually if they like. The RegistryHandler(GitHub) class subscribes to the registration events and registers the appropriate objects to their registry. The ModelRegistryHandler(GitHub) class subscribes to the relevant Model Registration events and handles registering block/item/entity models along with some helper methods for binding TESR and living entity models.

 

The EasyItem(GitHub) class extends Item and handles its own registration. It adds support for subtypes (which are also automatically registered along with their models) and supports custom names based on meta(subtypes). It can even take in an item as an argument and automatically register that item as well. The EasyBlock(GitHub) class is similar to the item class. It extends the block class, has the same constructors and will automatically create an ItemBlock and register that. It also supports changing the ItemBlock as well. The EasyTileEntityBlock(GitHub) class extends EasyBlock(GitHub) and implements ITileEntity and adds default implementations that can be overridden.

 

Finally, the EasyLivingEntity(GitHub) class adds a few default values for entities (tracking range, send velocity update and update frequency; I'm pretty sure I used the values of an IronGolem) and adds egg support by just telling it what color the egg is or calling setHasEgg and passing true (default colors are black). It has a method getRendererClass that will try to guess the renderer class name based on the given entity name and the package of the entity class following the format <Package>.<modId>.client.renderer.entity.Render + <entityName>. The player would have to make their own renderer class within the expected package and would need to link it to their model class.

 

Some code example:

MoTD(GitHub) adds 13 entities with eggs and with models in 13 lines. By passing their Entity classes(GitHub) and created their EntitiyRenderer(GitHub) which the EasyLivingEntity(GitHub) class was able to find by itself.

MOTDBlocks(GitHub) created several blocks that extended EasyBlock(GitHub) by just passing a name and material. And MOTDItems(GitHub) created several items by just passing a name and creative tab to BaseItem(GitHub) that extends EasyItem(GitHub).

 

My hope with the automation of registration is for modders to be able to focus on adding content rather than registering it and perhaps make updating mods easier. My library has a bunch of other classes as well, but these are the base classes I feel would be the easiest to implement. These changes only add code and is aimed to work with the system with no changes to that system needed. Adding these classes wouldn't break anything.

 

[LexManos]

Short answer: No

Long Answer: All of this fluf just causes modders to do things incorrectly. All your default values are wrong, and nobody will change them thus causing duplicated defaults all over the place. Auto-magical registration is just ASKING for things to be statically initialized which your examples are showing are the case. Which is something we've been crusading against for years because it one of the things that prevents mods from being hot swapable. Not to mention your little hack to swap the current mod for registration is bad. As it screws up override tracking as well as bypasses the warning about invalid registry names. At the end of the day, you are not saving any time/code. As you still have to initalize your mods SOMEWHERE {you're doing it in preinit, you SHOULD be doing it in the Register event} and your method promotes way to many bad habits and technical issues that we've been trying to get modders to fix for years.

[ZDoctor]

 

  On 9/13/2018 at 8:25 PM, LexManos said:

 As you still have to initalize your mods SOMEWHERE {you're doing it in preinit, you SHOULD be doing it in the Register event} and your method promotes way to many bad habits and technical issues that we've been trying to get modders to fix for years.

Expand  

2

I don't quite understand what you mean by this. My mod/lib does not simply register in the preinit. It follows the same specifications that forge wants modders to follow. Modders can initialize items in the preInit, but in the background, my mod tracks these entries and waits for the appropriate registration event before registering them. What bad habits are you talking about? What technical issues?

 

  On 9/13/2018 at 8:25 PM, LexManos said:

All your default values are wrong, and nobody will change them thus causing duplicated defaults all over the place.

Expand  

 

The only defaults I have is for living entities, and perhaps not many will change them unless they know what they are doing or what they are for. But I wouldn't call them wrong as they are based on vanilla values. Perhaps not all of them are at optimal values, but I personally don't know what are or how to determine them. And are you certain that these duplicate default will cause any problems? If so, why?

 

  On 9/13/2018 at 8:25 PM, LexManos said:

All of this fluf just causes modders to do things incorrectly.

Expand  

1

I am not sure how it would cause modders to do things incorrectly. From my own personal experience, it is quite nice to just pass a few values and have everything handle for me. It makes debugging easier as I know what I can count on not being broken. What exactly would the be doing incorrectly? I would love to know, perhaps I can fix it.

 

  On 9/13/2018 at 8:25 PM, LexManos said:

Auto-magical registration is just ASKING for things to be statically initialized which your examples are showing are the case. Which is something we've been crusading against for years because it one of the things that prevents mods from being hot swapable.

Expand  

4

I don't quite understand what you mean by this. Perhaps it's just my ignorance. I assume by "Auto-magical registration" you meant automatic registration. What do you mean having things statically initialized prevents mods from being hot-swappable? I'm no expert about hot swapping, so what does this have to do with anything? The way that Forge is now, you have to restart if you want to register a new item/block/etc and that is more of an issue with Minecraft's code if I am not mistaken. In my eclipse workspace, I've been able to run debug and change code (which as I understand it is hot-swapping the code) and it works as expected.

 

If forge wants to prevent modders from doing certain things, then I would assume a better alternative should be offered. My system isn't perfect, but I know for sure that it is a whole lot easier, consistent and maintainable than the current structure.

 

  On 9/13/2018 at 8:25 PM, LexManos said:

Not to mention your little hack to swap the current mod for registration is bad. As it screws up override tracking as well as bypasses the warning about invalid registry names. 

Expand  

 

On what grounds do you claim this? My system is like a secretary to forge, so if you had to items or whatever that had the same modid and unlocalized name, it would not interfere with any errors forge would have with this. How does it screw up the tracking? It essentially tells forge, "hey here's an object that needs to be registered, and it's for this mod." No duplicate entry would be allowed.

 

Perhaps it is just that my code that the code that I have is a bit hard to parse. Perhaps I'll work on a smaller version so that only the registration is there as to not distract from the code. Is there something that I missed? I truly do want feedback. I am sure an automated registration system would be good for forge. Mods would be easier to maintain and sometimes can carry over to a new version of minecraft. At the very least something should be done about so that the greatest challenge to learning to mod Minecraft isn't just getting an item or block to show up in game.

 

[TheTrollguy_]

The way I automized my registrations:

• Make a HashSet of Blocks/Items in your CommonProxy.
• In your Block/Item constructor, add the current instance of the class to the HashSet. (ie. CommonProxy.BLOCKS.add(this);)
• During RegistryEvent.Register, go through your HashSet and register each object (if we're talking about IForgeRegistryEntrys, otherwise register it during the preInit or init phase). Use a Stream, a for-loop, whatever you want.

The same applies to models and other client-side stuff.

[V0idWa1k3r]

  On 9/15/2018 at 12:26 PM, TheTrollguy_ said:

The way I automized my registrations:

• Make a HashSet of Blocks/Items in your CommonProxy.
•  In your Block/Item constructor, add the current instance of the class to the HashSet. (ie. CommonProxy.BLOCKS.add(this);)
• During RegistryEvent.Register, go through your HashSet and register each object (if we're talking about IForgeRegistryEntrys, otherwise register it during the preInit or init phase). Use a Stream, a for-loop, whatever you want.

The same applies to models and other client-side stuff.

Expand  

This approach screams "static initializers" and static initializers are bad. Just instantinate your blocks/items/whatever directly in the registry event. Not in a static initializer, not in FML events. You are also doing extra unnecessary work, think about it. Thirst you instantinate your stuff somewhere, then you add them to the set in the constructor, then you loop through the set in the event. That's at the very least 3 lines of code per block. Now think of the recommended approach. You instantinate your stuff directly in the registry event as an argument passed to register. That's one line of code per thing. With the recommended approach you are doing only 33% of the work.

Also CommonProxy makes no sense. Proxies are for separating sided only code. Common code goes whereever but your proxy.

[TheTrollguy_]

  On 9/15/2018 at 12:51 PM, V0idWa1k3r said:

This approach screams "static initializers" and static initializers are bad. Just instantinate your blocks/items/whatever directly in the registry event. Not in a static initializer, not in FML events. You are also doing extra unnecessary work, think about it. Thirst you instantinate your stuff somewhere, then you add them to the set in the constructor, then you loop through the set in the event. That's at the very least 3 lines of code per block. Now think of the recommended approach. You instantinate your stuff directly in the registry event as an argument passed to register. That's one line of code per thing. With the recommended approach you are doing only 33% of the work.

Also CommonProxy makes no sense. Proxies are for separating sided only code. Common code goes whereever but your proxy.

Expand  

 

Well, I never actually thought about that approach. Now that I really think about it, it does make a lot of sense. Thanks for the heads up!