V0idWa1k3r

Additionally ItemStacks can't be null in 1.11 so your inventory class contains issues you will need to fix.

You can't pass the x/y/z like that. BlockPos rounds anything you pass to it to an integer. For rendering the double precision matters. If you want to render an outline around a block I recommend not reinventing the wheel and seeing how vanilla does it at RenderGlobal::drawSelectionBoundingBox/RenderGlobal::drawBoundingBox. That method even is public so you can just offset the matrix/BufferBuilder, call it and you are done. I would also recommend debugging if your methods are called at all.

Your render registration must be done in pre-init for entities. For items/blocks use ModelRegistryEvent. Registering items/blocks must be done in RegistryEvent.Register that is appropriate for the object(RegistryEvent.Register<Block> for blocks, RegistryEvent.Register<Item> for items/etc). Even if you are not yet using new versions of forge you should still use event registration system so you will not have to rewrite all your code when you do decide to update. At the very least you should register your models and renderers using pre-init, not init, if you refuse to use the ModelRegistryEvent for one reson or another. Why are you using RenderManager directly? You should use RenderingRegistry::registerEntityRenderingHandler(Class, IRenderFactory). Client-side only code can't be located in common classes or you will crash the server. It must either be located in your client proxy or in a class that you know for sure will not get loaded on server.

Looks correct. What is ? Is it pointing to fixed coordinates in the world? Is it being synced to the client? => te.BEGIN_LINE_POS.subtract(te.getPos()); Vec3d::subtract already returns a new Vec3d object. EDIT: there was an issue in my example. This line: is supposed to be bb.pos(x + posDiff.x, y + posDiff.y, z + posDiff.z).color(1, 1, 1, 1F).endVertex(); As you need to specify the end position relative to render coordinates aswell, my bad. Change that line in your code too and it 'should' work provided that everything else is correct.

Almost. You should not subtract the start vector as the start vector is the start of the line for rendering. Subtract your TE's position instead - that is the logical start of your line.

So in your packet the constructor that you are using in your TE reroutes to which conviniently sets every field in the packet but the field.

Define "doesn't work". Is it still crashing you? Are you not recieving it? Are the fields not updated? Posting your new code also helps. At this point you might want to use git for your code so it is both easier for you to update us with the changes you've made and for us to see your latest code.

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.