V0idWa1k3r

This is still not the right way to cast things. This is not about mine or anyoneelses ego. This is about you and your coding. If you don't know the language you are using you won't be able to do much. You will encounter issues you won't be able to solve because you don't know how, like right now. And you will come to this forum again asking a question that can be solved just by knowing the language. And we will have to tell you the same thing I am telling you right now - learn java before starting to mod. You WILL have issues.

Well then you should probably learn java before starting to make mods. Otherwise you are trying to assemble a rocket without a guide.

Yes it is.

They are different classes. An EntityPig is a descendant of EntityLivingBase, but EntityItem or EntityArrow isn't.

You don't have to put anything for "item" since it is a variable already, look at the example provided. As for "model location" you would put something like new ModelResourceLocation(item.getRegistryName(), "inventory"); In your ModelRegistryEvent.

EntityLivingBase#addPotionEffect. You can't add a PotionEffect to an Entity since Entity objects can't have them in the first place. Only the descendants of EntityLivingBase may have potion effects.

You can get the current GUI opened with Minecraft.currentScreen. Then if it's a chest that GUI will be an instance of GuiContainer. You can then access the Container of that GUI with GuiContainer.inventorySlots. Finally you can iterate all ItemStacks of that container with Container.inventoryItemStacks.

Well first of all this recipe's json is broken, it's syntax is invalid. Secondly if the item in the recipe has subitems(read: metadata that defines different states) you need to specify the data property in your recipe too. has 2 variants - normal apple and notch apple thus requires the data property Has 2 variants - dirt and coarse dirt thus requires the data property There is no item with a registry name of grass_block. This should work without issues since it has no subitems. Has 7 variants - stone, granite, diorite and andesite(+ polished variants) thus requires the data property Since potions use NBT data to differentiate between different potion types you would need to specify that NBT data in the ingredient. Unfortunately 1.12.2 isn't capable of recognizing NBT in ingredients. You would need a custiom recipe ingredient parser.

I mean rotate it in your mod, in your renderer. GlStateManager#rotate

Item already has a method that allows you to give your armor a custom model public net.minecraft.client.model.ModelBiped getArmorModel(EntityLivingBase entityLiving, ItemStack itemStack, EntityEquipmentSlot armorSlot, net.minecraft.client.model.ModelBiped _default) Just return your custom model there and it will be rendered instead of the default one.

Yes, I've acknowledge that. It's just that you've explicitly mentioned that this doesn't work for the OP because they are using a primitive type. I just clarified that it doesn't matter whether the type is primitive or a reference type, it won't work regardless.

Nobody is saying that modding is a good place to start if you know nothing about programming or the language. It really isn't. Modding expects you to know quite a lot about how java functions. Minecraft isn't a good place to learn how to code in java. It's too complicated for it's own good and in a lot of cases is plain bad as in it teaches you bad practices. It is a fine place to start if you have the basics nailed down. Or at least know other programming languages which feature OOP.

To me this looks like the entity is upside down. Maybe something is wrong with your modelling software and the way it exported the model? In any case you can rotate the entity by 180 degrees around the z axis to fix this.

Well technically in java this doesn't matter. Consider this example: class A { public String foo() { return "1"; } } class B extends A { @Override public String foo() { return "5"; } } class Main { void bar() { A a = new A(); this.baz(a); System.out.println(a.foo()); } void baz(A a) { a = new B(); } } This will output 1, not 5 because changing the variable a in method baz changes the local copy of that variable that the method operates with. Even though A is not a primitive type. If you wanted the change to apply in a scope outside of baz you would need to pass A as a reference. Which java can't do. However changing a field inside of the passed A would change it for bar too. I am sure you know this already, I am just pointing this out to avoid confusion for members who may not be so familiar with java.

Well so far it's still present on forge's github in the 1.13 branch. And from what I can tell there are issues with gaining access to private things within a module that isn't "open" to reflection. So in theory they could still function just fine without the final modifier. Worst case scenario we will have to replace them with a lazy getter that would querry the registry. Something like this. For example(not intended for actual use, just an example of how you can acheive similar functionality) public static final Lazy<Block> TEST_BLOCK = Util.querry(new ResourceLocation(MODID, "test_block"), Block.class); ... class Util { private static final Map<Class<?>, IForgeRegistry<?>> regCache = Maps.newHashMap(); public static <R extends IForgeRegistryEntry<R>, T extends IForgeRegistry<R>>T getCachedRegistry(Class<R> registryClass) { if (!regCache.containsKey(registryClass)) { IForgeRegistry reg = GameRegistry.findRegistry(registryClass); if (reg == null) { throw new IllegalArgumentException("Not a registry object!"); } regCache.put(registryClass, reg); } return (T) regCache.get(registryClass); } public static <T extends IForgeRegistryEntry<T>>Lazy<T> querry(ResourceLocation name, Class<T> registryClass) { return new Lazy<T>(() -> getCachedRegistry(registryClass).getValue(name)); } }

An ItemStack will never be equal to an item. Also that is not how you make a condition. What is this mysterious drops object and how does it work? Again, this is a horrific way of making conditions. There is so much unnecessary stuff in it. Also you terminated whatever the condition was supposed to control with a ; meaning that the code in your brackets will get executed regardless.

Override Block#removedByPlayer, it fires when the block is broken by the player. Check whether the player is holding your picker item and if they aren't send your message and return false, otherwise invoke the base implementation(return super.removedByPlayer). That is if you want it harvested by breaking the block. If you want to harvest the block with a right click then do what I've said earlier: And by "do what you need to do" in this case I mean drop the item and set the block to air.

Yeah. In general anything that is a part of the registry should be instantinated in the appropriate registry event. If you need a reference to that object later you can use ObjectHolders.

Well you should then inspect your code and actually understand what it is doing. Programming without a clear understanding of what the code does is like trying to assemble a rocket without a manual or assembly markers. What behaviour do you actually want? Afaik when you break a fruit in pam's it breaks like a normal block and doesn't revert to age 0. Pam's fruits are harvested by right-clicking.

Even though this is named preInit it actually fires during init due to the parameter you've specified. Don't do this. Instantinate your items in the appropriate registry event and there only.

Well first and foremost your handler does absolutely nothing with your message. So I have no idea why you are getting any results at all in the first place. Unless some other code you've not shown does something else. public static class Handler extends ClientMessageHandler<PacketProgressBar>{ @Override public IMessage handleClientMessage(EntityPlayer player, PacketProgressBar message, MessageContext ctx) { return null; } } What is ClientMessageHandler btw? Is this message being send from server to the client or the other way around? From your description it seems like you want a server -> client message but then this public PacketProgressBar(int Storage, int x,int y,int z,ForgeDirection dir){ this.data = new NBTTagCompound(); data.setInteger("EnergyStored",Storage); Gui gui = Minecraft.getMinecraft().currentScreen; if(gui instanceof GuiEnergyInterface){ GuiEnergyInterface GEI = (GuiEnergyInterface)gui; GEI.storage = Storage; } } makes zero sense since it accesses client classes. Also don't use NBT to send ONE integer. Just send that integer. Your code takes some values from the thing you've passed to it on the server and then proceeds to reach across sides to set the values on the client. It also writes some data to NBT, sends it over the network and does nothing with it. This is not how messages work. Read the docs.

I wonder why indeed... This is not what you use events for. Events are when you need to hook into existing behaviour, not when you need to create a completely new one. Just override Block#onBlockActivated, check if the item in the player's hand is your item and do what you need to do. if (!(state.getValue(AGE) != 3)) { } What is the purpose of this code? The condition will never be true and even if it was it does nothing. Well so far you've done absolutely nothing to change the default breaking behaviour, thus it breaks as all other blocks.

https://minecraft.gamepedia.com/Talk:Chunk_format

@Override public Item getItemDropped(IBlockState state, Random rand, int fortune) { return new ItemGlowstoneBowl(); } You can't just create a new item and be done with it, you must provide an existing, registered item. @Override public ItemStack getPickBlock(IBlockState state, RayTraceResult target, World world, BlockPos pos, EntityPlayer player) { return new ItemStack(new ItemGlowstoneBowl()); } Same here. The new keyword creates a new object(and you need an existing one). This is basic OOP. To obtain a reference to a registered object use ObjectHolders.

I already told you how to handle the setNormal change. Include the normals per vertex. Old Tessellator had global states which would get applied to vertices. New BufferBuilder doesn't have them and as such you have to specify them for each vertex. putX simply puts the raw data passed into the raw int buffer instead of putting it into corresponding buffers with a corresponding format. Unless you know what you are doing you should be using simple vertex creation operations, like pos, color, normal, tex and lightmap.