V0idWa1k3r

fromBytes is supposed to convert bytes to data, not write anything. toBytes is supposed to convert data to bytes, not read anything. Did you accidentaly mix the methods?

You have infinite recursion all over this method. The method calls itself on like every line but the first 4. That will not work well. Also this way of generating structures will make it nearly impossible for you to change the structure in the future. Consider using structure blocks/Template to generate your structure. This is the entry method that gets called once each chunk. Yours is absolutely empty so your code will never run. Casts like these are redundant as IBlockState::withProperty returns an instance of IBlockState. On a side note this constructor is as undescriptive as it gets. What are u/i/a supposed to be? Why is there a boxed Boolean? Why is it named f? Why do none of these parameters do anything but the b one? Do you yourself understand what this constructor is supposed to do? You probably should not just leave empty stubs like that in your code. If you are generating a method autoaticaly - fill it in then, there was a reason you generated it, was there? Is it not supposed to do anything? Why have you generated it then?

You are still using your TE's positions as the start of the drawing vector. Use the x/y/z parameters from the draw method. Your end vector must be a drawing start vector + delta vector of your TE's position and the end position of the line. If your line goes 10 blocks up from your TE it will be [x + 0, y + 10, z + 0].

You can specify the width of the line with GlStateManager::glLineWidth. Quads are better for more control over the rendering process, as they are quads and can be positioned/rotated/textured as you wish, but lines work just fine for simple things. For example vanilla uses LINE_STRIP(which is a variation GL_LINES) do draw the bounding box over the block you are looking at and it works perfect. Lines and quads are just used for different purposes You calculate the vector that points from your TE to the point you want the line to go to and use your start vector + that vector as your end coordinates.

Do not use GL11 methods directly. Use GlStateManager. Using GL directly messes up with GlStateManager's flags and can screw some things up. Why are you offsetting the matrix by TE's negative position? That is not a good idea, there is a reason these parameters exist. They are used as your render coordinates. Use them. Why? 7 is GL_QUADS. If you are drawing a line GL_LINES(1) makes much more sense. This adds raw data to the buffer. Unless you know how to use this you should not be doing that. Use BufferBuilder::pos to specify position, BufferBuilder::color to specify color and BufferBuilder::endVertex to end the current vertex data. Vec3d start = new Vec3d(te.getPos().getX(), te.getPos().getY(), te.getPos().getZ()); Vec3d end = start.addVector(0, 10, 0); Vec3d posDiff = end.subtract(start); GlStateManager.pushMatrix(); GlStateManager.glLineWidth(1F); GlStateManager.disableTexture2D(); BufferBuilder bb = Tessellator.getInstance().getBuffer(); bb.begin(GL11.GL_LINES, DefaultVertexFormats.POSITION_COLOR); bb.pos(x, y, z).color(1, 1, 1, 1F).endVertex(); bb.pos(posDiff.x, posDiff.y, posDiff.z).color(1, 1, 1, 1F).endVertex(); Tessellator.getInstance().draw(); GlStateManager.enableTexture2D(); GlStateManager.popMatrix(); This is a super-quick(and a bit messy) example that draws the line in 4! calls 2 of which are begin and draw calls. Everything above and below are gl setups/state restoring. I could've even dropped push/pop matrix here as I am not doing anything with the matrix. If you need something more complex than a simple GL line(a line with a texture, more controllable line, rotating line, etc) I suggest you to look at vanilla examples like TileEntityBeaconRenderer or RenderGuardian. The later will need to be adapted to be a TESR but will work just fine.

Why are you trying to draw anything in your tile's update method? Not only is that a different thread, rendering is something that must be done each frame, not each tick. A tick is 1/20 of a second. A frame can literaly be any time value dependant on user's settings, monitor and other things. You must render your things in rederers/render events and nowhere else. getVertexFormat gets the current drawing format. As you are only starting to draw things this getter can't be used. See DefaultVertexFormats for available formats.

Depends on the mod and the way they implement their tools/stage they do it at. The best case scenario is them exposing the material in their API. If that is not the case you can try to get the material from the ToolMaterial enum if they added their material there via EnumHelper or custom reflection. If they did so you can either get that material from ToolMaterial enum by it's name (Enum::valueOf) or by iterating through all values (Enum::values) untill you get the desired material. You must ensure that you are doing it after they've added their material to the enum though or you will not find it.

Blockstates for items: blockstates files, model loading (yep, it is the same stuff I've already linked as that code uses blockstates for items(to be fair it uses them for itemblocks but there is no difference whatsoever for other items too)). The idea is - when you are loading a model for an item forge will first look in the models/item folder to find the model file, and if it can't find any it will look in your blockstates folder for the blockstates file. The syntax is absolutely the same and everything functions as you would expect it to, just for items instead of blocks. ModelRegistryEvent.

This is not how you get a value from a field using reflection. There is a Field::get(Object) method you must call to get a value the field stores. The object parameter is an instance of a class the field belongs to. If the field is static you simply pass null. If not - you need to pass the instance to get the value from. Additionaly you need to call Field::setAccessible(true) before doing anything with a field, as if it is not public you will get your access denied.

Pretty much, although I've never done it through the item.json model and I do not know if it is possible. You can still have obj models for items as forge can use blockstates files to define item models. And you should probably call it not in your preinit but in your ModelRegistryEvent or at least in your client proxy. but yeah, that's pretty much it.

For entities you need your own obj model loader/renderer. For items/blocks you need to put your model and material(.obj and .mtl files) in an appropriate models subfolder in your assets, point to that model through a blockstates file for example(if you are using forge's blockstates for items) and you are done. There are a few thing you need to know: 1. When specifying an obj model to be used you must include the obj extension in the path too. 2. You must call OBJLoader.INSTANCE.addDomain(modid) with your modid as a parameter before the models are loaded. Here(and the resources folder) is an example provided by forge itself.

Just set the blockstate at the position of your block to lava when it's mined. See BlockIce::harvestBlock for an example (although I'll admit it - it is a messy one but it should give you a general idea of how to do it).

TileEntity::markDirty is indeed still around, even in 1.12(and I checked - it does the same thing). It marks the chunk it is in as "dirty(1.12 name)/modified(1.11.x name)" aka "needs to be saved to disk as there were changes" and updates the comparator output for the block.

I think that you simply put your jsons in the recipes folder in your assets/modid/ folder and they just work, no registration required. Registry event is for adding recipes via code. Edit: well, as Choonster answered your first question first I'll edit my answer to relate to your new question

Mod example: https://github.com/McJty/RFTools/tree/1.12/src/main/resources/assets/rftools/recipes Vanilla example: See at %forgelibrary%/assets/minecraft/recipes. For some reason I can't find any info on json recipe format on the official mc wiki, maybe I'm just too tired at the moment. You can try, maybe you'll have better luck. The syntax is very similar, forge just introduces a couple new types you can use. Here is the original gist by Lex with some examples and clarifications but it might be outdated as there were changes to the system, use at your own risk.

Forge already provides those classes for you. ShapedRecipes, ShapelessRecipes, ShapedOreRecipe and ShapelessOreRecipe exist in the version of forge I've mentioned. You should however use the json recipe system as that is the suggested way of doing recipes now (since it makes it easier for the end-user to edit recipes on demand which is common nowdays and Mojang may introduce S->C json recipe sync in the future versions).

IRecipe is a IForgeRegistryEntry as are all it's implementations at least in 14.21.0.2343 so there should be an event for them. Not sure about the version you are using. The recipes and registries have been going through a lot of changes recently and will go through a lot more so I usually try to stay on the latest available version so I have the chance to adapt to the changes gradualy instead of having to rewrite everything once things settle down.

Your methods in the AMServerHandler(and in your AMClientHandler) are not annotated with SubscribeEvent. Even if you annotate the class with EventBusSubscriber you still need to annotate the methods that you want to be listening for the event specified. Also CraftingManager.register is private in the latest versions of forge, so you must use the appropriate registry event.

Have you removed from your 's EventBusSubscriber annotation(that you have now called AMServerHandler)? Just leave the annotation be as EventBusSubscriber(modid = Reference.ID) and check if that helps. As I've said objects being in registry is common for both client and server, it makes no sense for the server only to have them registered, the client needs it too.

Well expand the RecipeList(p_194042_1_) and see the recipes that it contains. One of those recipes has no registry name set for it's output(the one that has one of your items/blocks as it's output)

When the breakpoint is hit inspect the locals in that method. Your culprit is within the parameter of the method if I assume the method usage correctly.

Eclipse, IDEA

Correct me if I'm wrong but I think that this value param is dictating the physical side for the forge to run the subscribption on(FMLCommonHandler::getSide) and not the logical side(FMLCommonHandler::getEffectiveSide)? Therefore if the SERVER is specified as a side here would FML not subscribe the class to the event bus unless the code is running on an actual server(that is the Minecraft Server is chosen as a run configuration or the user launches a server)? In any case blocks(and items) being in the registry is a common thing. It makes no sense for them to only be present on the server, the client needs to know about them too.

metadata can only go up to 16(actual values [0 - 15]). Apart from that the power your block sends is defined in Block::getWeakPower method, you can access your tile from it, access the capability and get the power you are emitting. You might need to notify neightbour blocks when you are changing that value with World::notifyNeighborsOfStateChange (see how BlockLever does that). You can do that directly from your tileentity.

I am pretty sure he needs to both annotate the class with EventBusSubscriber and methods with SubscribeEvent. EventBusSubscriber just tells forge to perform EVENT_BUS.register(TheClass.class), you still need SubscribeEvent to actually tell forge what methods to use as listeners.