V0idWa1k3r

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.

Blocks do not have any NBT data associated with them. Do you mean ItemBlocks or TileEntities? ItemBlocks are not different from regular items in this regard. You can use Block::getActualState to return an IBlockState that relies on something like a TileEntity to define values for some of it's properties. See BlockFlowerPot for more details and an example.

That is not how you use events. This is how you use events. The :: thing is just a way to write method references I use(and I use it because that is the 'official' way to write method references in java). When I say use ModelLoader::setCustomModelResourceLocation I do not mean that you should literally copy the line into your code. I mean to use the setCustomModelResourceLocation method from the ModelLoader class. And get rid of the Minecraft.getMinecraft().getRenderItem() entirely - you do not need it.

Well show your code and that error then. You... pass a new instance to the registerAll method. Like event.getRegistry().registerAll(new Obsidian_ingot()); That is essentially what you are doing already, you are just creating an unnecessary local to immidiately discard it. To set a registry name call Item::setRegistryName(%yourname%) somewhere, in your item constructor or chain it after instantinating your item.

Just use the ModelRegistryEvent as you would use any other event, like the registry events you are currently using. You use ModelLoader by calling ModelLoader::setCustomModelResourceLocation in the same way you are calling ItemModelMesher::register. The arguments are the same. I'm sorry, I haven't quite understood your question here. Could you explain it a bit better?

Do not use ItemModelMesher, it is buggy and outdated. Use ModelLoader and do it in the ModelRegistryEvent. Why do you create a local to immediately discard it? Just pass a new instance of your item to the registerAll method, you do not need a local. Also make sure that you have set the registry name of the item you are registering. That is not how things are registered. Create a public static final Item %NAME% = null field and annotate it with ObjectHolder with the registry name of the item. You can either include your modid in that registry name or annotate the class with that field with ObjectHolder and give it your modid.

You are using the wrong coordinate getter. You need WorldServer::getSpawnCoordinate, not World::getSpawnPoint

All redering must be done on the rendering thread. You need to use render-related events. You can still access capabilities and such from the render thread just fine. If the data you need is only present on a server then yes, you need a custom packet to sync the data to the client.