V0idWa1k3r

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.

As I understand the new system only chunks will use numerical IDs to resolve a blockstate at a given location. So while they are not going away and are still used for serialization you have no control over them and the mappings won't hold them since each chunk has it's own set of IDs <-> Name pairs. You will simply tell the game in this event that "Oh, X actually equals Y". Kinda like telling the game that modid:some_name is just a pointer to modid:some_other_name. So when the game asks for modid:some_name it will just be resolved to modid:some_other_name. Think of it as making a symlink.

You can't do this. Blocks are singletons meaning that these values will apply to all blocks in the world when you change it. Resolve the needed connections in your getActualState method. Or migrate the variables responsible to the connections to a TileEntity.

Wait untill 1.13 is even available for modding, then ask the question. There will likely be a way to hook into the conversion methods to map metadata to corresponding blockstates. Vanilla has this option, why wouldn't mods have it too? However as of right now it is too early to worry about this. Wait untill an mdk for 1.13 is released.

Send a packet to the client, use Minecraft#displayGuiScreen when handling the packet on the client. What examples do you need?

There is a SlotItemHandler that extends Slot but takes a IItemHandler instead of IInventory.

Do you need the server to know about the GUI as well? Or are you only opening it on the client? If you only need the client then you can use Minecraft#displayGuiScreen to display your GUI. You can construct the chest's GUI yourself, it only takes two IInventory objects(one is the inventory of a chest, the other of a player). Note that in this case you will need to send a packet to the client from your command. If you need the server too then you need a Container opened aswell. Use the IGuiHandler to return a vanilla chest GUI/Container pair if the ID is correct.