V0idWa1k3r

Looks correct to me unless I am missing something. Please show your updated code and the error log. If you want the dpetal item to be an instance of ItemSeeds why have you created a ItemDpetal class in the first place?

What do you want the dpetal item to be? If it is supposed to be a ItemDpetal then you would set the value of dpetal to an instance of ItemDpetal. If it is supposed to be ItemSeeds you would need to set it's registry name explicidly with Item::setRegistryName

dpetal = new ItemSeeds(ModBlocks.darklilac, Blocks.FARMLAND); You never set the registry name for the dpetal(at least not in the code you've posted), and the ItemSeeds class does not do that for you. Your ItemDpeal class does but you do not use it. Side note: do not use ItemModelMesher, it is outdated and buggy. Use ModelLoader.

You do not need to write the itemstack into NBT. You need to write TE's data into NBT and set that NBT to itemstack's tag with a BlockEntityTag key. Currently you are creating a new NBT, writing the ItemStack in there, writing your TE data in there and discarding the NBT. The ItemStack has no NBT associated with it as a result. Use ItemStack::setTagInfo to write an NBT into your ItemStack's compound.

You are referencing a client-only class in your common code, hence the crash. The previous solution works because you are using a proxy.

1180 != 1178. That's one of the reasons to use descriptive class names.

You are still using DrawBlockHighlightEvent. You need a different event.

Somewhere in it's loop it raytraces the block you are looking at. I'm not quite near my pc atm so I can't tell you exactly where. You can do the same using World::rayTraceBlocks. You would still need to offset everything properly before rendering though.

Well, there are docs but they are currently being worked on and might feel a bit vague in some parts. The idea is that you never have to manualy set any fields yourself. Create any class, annotate it with ObjectHolder and give that annotation your modid. In that class you then can declare any amount of fields annotated with ObjectHolder with those annotations having a value of a ragistry name. The field must be public(or private) static final %Type% %name% = null. The =null and final part ensures that you do not put anything into this field on your own. The name can be any name you want, obviously and the Type is the class of the thing that is registered with the registry name specified in the annotation for the field. For your obsidian item the field could look like @ObjectHolder("ItemObsidian_ingot") public static final Item OBSIDIAN_INGOT = null; Then you would just reference this field anywhere you need to get an instance of your item. In your model registration as an example. The field gets populated by forge automatically after you've registered all your things in the appropriate registry event.

You are still not registering your item correctly. You need to use ObjectHolders as I've described earlier in this thread otherwise you are registering a model for a completely separate Item object that has nothing to do with the item you have registered. Additionally this is not all your updated code. The Item's class itself would be nice to see, or at least it's constructor, and your class that registers the items.

If you are using DrawBlockHighlightEvent then your problem lies in the fact that the event is not called at all if the entity is in water, I think that is a vanilla thing. You could switch to using a different event but that means more work for you as you will have to raytrace the block on your own and apply the correct translations.

We still need to see your ModItems class where you do most of the registering related things.

Each quad contains 4 vertices, not 5 as you are specifying. It makes little sense for a square to have 5 corners, doesn't it?

Considering that the ordering of the vertices was taken from vanilla's rendering that uses an entirely different GL mode(3 - LINE_STRIP) as opposed to the one you are using(7 - QUADS) - that will most likely not work. Or it will produce a very weird result. Even the number of vertices is incorrect as each quad requires 4 vertices and the vertices you've posted are only enough for 4.5 quads which isn't right. If you mean the general usage and syntax - sure.

You use it as the name suggests. Each of your vertices will then contain a position(pos) and a color(color) and that's it. pos(0, 0, 0).color(1, 0, 0, 1F).endVertex() is a valid vertex for this format.

BLOCK is a format designed for drawing blocks, hence the name. Do you need to render a block? No, you need to render a colored cube. POSITION_COLOR will suffice. You would need to disable texture2d using GlStateManager before drawing with that one though as you are not using any texture.

-> BufferBuilder -> begin(7, %FORMAT%). The format can be obtained at DefaultVertexFormats and the names are pretty descriptive. -> pos/color/lightmap/tex/whatever based on the format + endVertex() at the end. The order of the elements(pos/color/etc) matters and the name of the format chosen shows the order. Your vanilla example shows that pretty well. draw is still draw. All other logic should be pretty much the same. You might need to play around with vertex ordering though.

...Or he could simply make the onModelRegistry method static and let forge automatically subscribe his InitEventHandler to the event bus without having to do this explicidly as he already has the EventBusSubscriber annotation... Additionally ModelRegistryEvent is fired before init, registering an event handler for it in init makes no sense.

It is forge:ore_shapeless, not forge:shapeless_ore

Show your updated code and your log. Are you registering your item correctly?

My point still stands for this issue aswell.

As eclipse suggests you are 1. Calling your registerRender with wrong arguments(you do not need to call it to begin with) 2. Referencing a non-existing item field/local. You register models for your items in the ModelRegistryEvent using the ModelLoader's setCustomResourceLocation method. That is all you need to do. If you are struggling with understanding methods and fields I suggest you to learn basics of java before starting minecraft modding.

You are supposed to use the ModelRegistryEvent as a single parameter to the method and annotate it with SubscribeEvent, like you are doing with the registry events.

There are a lot of threads related to recipes in 1.12 on this subforum that you could quickly find. Create a valid json that is your recipe and put it in assets/%modid%/recipes. And you are done - forge will load the recipe for you automatically. See this thread for more info. Also here is the initial gist that shows the basic syntax and the ideas behind the json recipe system.

What? The docs? Or the way to use ModelLoader? While I do agree that the docs can be vague at some points this page is not the case. You use ModelLoader in the same way you would've used ItemModelMesher, the method is named setCustomModelResourceLocation and it accepts the same parameters as the one in the ItemModelMesher. Here is an example usage of the method. And in the same class here is an example of event handling.