V0idWa1k3r

Weren't you told to update to a modern version of minecraft? Simply creating a new thread and prefixing it with [1.12.2] while staying on the old version is not good enough. Do actually update.

Seeing a mods.toml file I am assuming you are in 1.13. Recipes in 1.13 are not located within the assets folder. Instead they are now located within the data folder as they are now a part of a datapack instead of a resourcepack.

To add my 2 cents on the issue: IHasModel makes you write redundant code. It's not bad in a sense that it will break compatibility or something, it's bad because you literally write way too much code. For an interface that's suposed to simplify the code it's doing the exact opposite. Consider the following: A typical IHasModel usage: class ItemX extends Item implements IHasModel { ... @Override void registerModels() { Mod.proxy.registerModel(this, 0, "inventory"); } } class ClientProxy implements IProxy { ... @Override void registerModel(Item i, int meta, string variant) { ModelLoader.setCustomModelResourceLocation(i, new ModelResourceLocation(i.getRegistryName(), variant)); } @Override void registerModel(Block b, int meta, string variant) { ModelLoader.setCustomModelResourceLocation(Item.getItemFromBlock(b), new ModelResourceLocation(b.getRegistryName(), variant)); } } @EventBusSubscriber class ModelHandler { @SubscribeEvent public static void onModelRegistry(ModelRegistryEvent event) { for (Item i : ModItems.ITEMS) { if (i instanceof IHasModel) { ((IHasModel)i).registerModel(); } } for (Block i : ModBlocks.BLOCKS) { if (i instanceof IHasModel) { ((IHasModel)i).registerModel(); } } } } And then you have to duplicate the code in ItemX for every item class you have. While you can have something like ItemBase do that for you you will STILL have to replicate this code for every item that doesn't extend ItemBase, like custom tools or armor or god knows what. Now compare this to the "correct" approach to the situation: @EventBusSubscriber class ModelHandler { @SubscribeEvent public static void onModelRegistry(ModelRegistryEvent event) { StreamSupport.stream(Item.REGISTRY.spliterator(), false).filter(i -> i.getRegistryName().getResourceDomain().equalsIgnoreCase("modid")).forEach(i -> ModelLoader.setCustomModelResourceLocation(i, 0, new ModelResourceLocation(i.getRegistryName(), "inventory"))); } } ..and you are done. No, really, that's it. How about items that have damage? @EventBusSubscriber class ModelHandler { @SubscribeEvent public static void onModelRegistry(ModelRegistryEvent event) { StreamSupport.stream(Item.REGISTRY.spliterator(), false).filter(i -> i.getRegistryName().getResourceDomain().equalsIgnoreCase("modid")).forEach(i -> { ModelResourceLocation staticLocation = new ModelResourceLocation(i.getRegistryName(), "inventory"); if (i.getMaxDamage() == 0) { ModelLoader.setCustomModelResourceLocation(i, 0, staticLocation); } else { ModelLoader.setCustomMeshDefinition(i, it -> staticLocation); ModelBakery.registerItemVariants(i, staticLocation); } }); } } What about special cases? This is where an interface is acceptable. There, that's all the code you need and even this can be simplified further using streams better than I did. No need to repeat your code for each new item. CommonProxy: Of course a common proxy isn't going to cause incompatibilities. There are 2 issues with this concept - the first one is the name, the second one - the whole concept. The tutorials on the internet don't explain you what a proxy is or why it is needed, they just blindly tell you - create these classes, do that and this and it will work. The thing is though - a common proxy makes no sense at all if you think about it. Proxies existed to separate sided only code. If your code is common it goes anywhere else but the proxy. Think about it. A network handler wouldn't have a "Common" side - it has a client and a server. Why would a proxy have it? As for the "clutter" argument - please provide me an example of things you put in your common proxy that would otherwise clutter your mod class. What code do you even have there? 95% of all things were done with event handlers anyway, you rarely needed to do something in your FML lifecycle events. Additionally I just want to point out that I indeed had helped people on this very forum that had an issue with their code where the whole case of the issue was indeed the CommonProxy. So it's not even harmless. Also we are talking about 1.13.2. Proxies are gone anyway. As for the whole "it's fine for a beginner, they will learn to do stuff properly later" argument - no, they won't. Look at the most popular mods out there. They still use IHasModel and CommonProxy. And many other things. Clearly those people haven't learned.

IBlockColor is a thing too.

Please upload your repository correctly so I can test it out locally. The root directory of your repository should be the root directory of your project with other files also included. Additionally please post an up-to-date error log. Your blockstate file points to learningmod/models/blocks/fast_furnace.json but that file doesn't exist. package main.java.wsman217.LearningMod; Your package names should be lower case. public static CommonProxy proxy; CommonProxy makes no sense. Proxies exist to separate sided-only code. If your code is common it goes anywhere else but your proxy. @Mod.EventBusSubscriber public class CommonProxy Don't have your proxy be an eventsubscriber, that loads the class regardless of the side you are on which is against the whole point of proxies.

Don't decide whether to register things or not based on a value in the config file. Register everything, but disable the recipes and remove the items from the creative tab when needed. You could override IForgeItem#getMaxDamage.

If you are running this code on the client only the server has no clue that you are even doing it since you are not interacting with it in any way. If you are running it on a server I have no idea why accessing a random URL on the internet would trigger a "cheat response". Forge mods do it all the time with their update checkers, whether they are forge provided or custom.

ObfuscationReflectionHelper. It also has an advantage of you only needing to provide it with an SRG name.

In addition ItemRenderer#renderItem draws the item into a different buffer than your FastTESR gives you so if you keep using it nothing will change in terms of performance. You will need to upload the bakedmodel of your items to the FastTESR's buffer.

Smelting recipes are now done through json aswell. https://minecraft.gamepedia.com/Recipe#JSON_format

Is your TE ITickable? If is is then you can simply do these things on the first tick(have a boolean or something). Otherwise you might be able to do it in TileEntity#setWorld, as far as I can tell it is called after the NBT was loaded. Just make sure you are on the server.

Block#updatePostPlacement.

I am not sure this is the method's signature and you don't have an override annotation over it. Place that annotation and make sure the signature is correct. Also don't manually override methods, use your IDE. As for other issues: Don't use BlockBase, there is already a BlockBase, it's called Block. Don't ever use static initializers. Instantinate your stuff directly in the appropriate registry event. IHasModel is stupid. All items need models and nothing about model registration requires access to private/protected data. Register your models directly in the ModelRegistryEvent. You can even do it with a loop and write a metric ton less code. And even if you don't use a loop you still write 1/3 of the code you would with IHasModel.

https://github.com/MinecraftForge/MinecraftForge/issues/5470 As far as I can tell this bug has been fixed so you just need to simply update your forge instead of manually adding things to that map.

Entity#remove

EntityType.create(NBTTagCompound, World)

https://en.wikipedia.org/wiki/Generics_in_Java. A type parameter is declared within the <>. Say a List<T> is a generic class where T is the type parameter. When you create a new list you specify said type parameter, like new List<String>. Now String is the type parameter, meaning that List now only accepts strings. If you want said List to accept anything you declare a wildcard as it's type parameter(new List<?>).

EntityType is a valid registry entry, you don't need to change it to anything. Of course it has a generic parameter you must provide, this is basic java. Since this is a forge event a wildcard type will do.

Whether the server should send the velocity data to the client. public static <T extends Entity>EntityType<T> registerEntityAndEgg(IForgeRegistry<Item> itemRegistry, Class<T> entityClass, Function<? super World, T> factory, int eggPrimaryColor, int eggSecondaryColor, int trackingRange, int updateFrequency, boolean sendVelocityUpdates, String name) { EntityType<T> type = EntityType.Builder.create(entityClass, factory).tracker(trackingRange, updateFrequency, sendVelocityUpdates).build(TestMod.MODID + '.' + name); itemRegistry.register(new ItemSpawnEgg(type, eggPrimaryColor, eggSecondaryColor, new Item.Properties().group(ItemGroup.MISC)).setRegistryName(name)); return type; } Or something along those lines, I am not writing code for you, this is just an example that you will need to adjust to your needs.

Well, you can create a helper method but in general yes, you will need an EntityType for each entity.

It prevents you from overriding other classes. Say you want to create a custom elytra - well, you have to override ItemElytraWings(or whatever it's called) since minecraft uses a lot of instanceof checks. With your ItemBase though you can't. And now you have to duplicate your code for no good reason. It is not needed. You are just creating extra classes for no good reason. Why do you need it? Everything is now passed to the constructor via the corresponding Properties object and setRegistryName already returns you your object so you can chain it. It serves no purpose apart from enforcing cargo-cult programming. In general you shouldn't abuse inheritance just to write less code, that's not what inheritance is for. If you really need it create a helper method: public static <T extends IForgeRegistryEntry<T>> T setCommonParameters(T object, String registryName) { return object.setRegistryName(new ResourceLocation(TestMod.MODID, registryName)); } // In your registry handler event.getRegistry().register(setCommonParameters(new Item(new Item.Properties()), "test_item")); But even this is not needed since you can just do event.getRegistry().register(new Item(new Item.Properties().group(GroupsRef.GROUP_TEST_MOD)).setRegistryName(NAME_VOID_INGOT));

public static EntityType<EntityItem> storedItemType; @SubscribeEvent public static void onItemRegistry(RegistryEvent.Register<Item> event) { // Here for example I am creating a type for the EntityItem, you would need your own entity here with your own parameters. storedItemType = EntityType.Builder.create(EntityItem.class, EntityItem::new).tracker(32, 1, true).build("v0idstestmod.test_entity"); event.getRegistry().register(new ItemSpawnEgg(storedItemType, 0xffffff, 0x00ff00, new Item.Properties().group(ItemGroup.MISC))); // Your other registration code ... }

public class DebugItem extends Item { public DebugItem() { super(new Properties()); getCreativeTabs().add(ItemGroup.MISC); } } Instead of this you could do this: new Item(new Item.Properties().group(GroupsRef.GROUP_TEST_MOD)).setRegistryName(NAME_VOID_INGOT) For the future - you can always look at how vanilla does it's things. You can see how items are constructed at the bottom of the Item class, blocks at the bottom of the Block class, entities at the top of EntityType, and so on.

The first parameter is the EntityType of the entity to spawn. As I've told you in your other thread construct it in this event using the builder, I've even shown you how to do so with an example line. The last parameter is the parameters of the item(max stack size, it's ItemGroup, container item, etc). Look at how other items are registered in the Item class.

Dont use ItemBase, there is already an ItemBase, it's called Item. Don't use static initializers, ever. Instantinate your stuff directly in the appropriate registry event. As for the error itself - read it. It tells you what's wrong right there, in the exception message. All registry names must be lowercase. They may include numbers from 0 to 9 and characters like ., _ and -. Nothing else is allowed and you have a capital I in there.