Leaderboard

Never register your things into the registries whenever like that. Register your biome in a RegistryEvent.Register<Biome> to the registry passed to you in that event.

The yes it is obviously your block, and the problem may be that the string in your @ObjectHolder annotation doesn't match its registry name?

The other thing you can do is offset your block placement by +8, +8 on x and z. Yes, this will place blocks into neighboring chunks, but those 3 chunks are safe and won't cascade.

Yes I meant the latter. Instead of doing new MultiPartEntity do new EntityTest.

You're fine.

What part of Have you failed to understand after FIVE PAGES (and at least four people trying to help) of thread? You have done fuckall to your folder names since I went to bed. Jesus mother foxing christ on a crutch.

Just make a basic entity that extends Minecraft rideable & register it & get it to work, then go into rendering

IC2 is the name of a mod, its modid is industrialcraft2. TiC is the name of a mod, its modid is tconstruct. Reason being short modids are a bad problem because there may be another mod out there with the id rc, ab, or cd. This would cause forge's mod loader system to crash. You are programming get used to writing a lot.

You specify As the path and not rc:items/ which is where all your actual textures are. So you have two options Learn how to read the log messages and find your errors, and change your file path to be rc:item/ Learn how to read the log messages and find your errors, and change the path in your json to be rc:items/ Also rc is a terrible modid, its so short.

You could take a look at my Shard Compressor it uses a custom recipe system that I will later implement to use the json format. Overall the actual furnace code is a mess and is made so much simpler by a forge addition, the IItemHandler. It greatly simplifies the code you have to write in the update method.

Proabably, look at some open source mods. Tinkers construct, Mekanism come to mind. Minecraft By Example is a great resource too

FastTESR is for rendering tile entities in batch. That happens by initalizing the drawing buffer once, then the mods can upload vertices to the buffer passed and after everything is done there is a final draw call. That is way more performant than a regualr TESR since a regular TESR can use anywhere from 1 to infinity draw calls per render invocation where as FastTESR uses 1 draw call per however many TileEntities there are and draw calls are expensive. That however comes at a cost of a fixes BufferBuilder format and a fixed GL state. So yes, you can't use GlStateManager in a FastTESR since it screws with the GL state. In general you should use a FastTESR for a model that you can draw with the BufferBuilder that may or may not be animated. I have some utility methods to use with a FastTESR(like rendering an obj model or a cuboid) here if you want an example of what the FastTESR can be used for. However a FastTESR can't be used for some things. Pretty much anything that requires GL state changing or draw calls is incompatible with a FastTESR, and item rendering requires both. Hope this explanation makes it clearer for you as to when to use a FastTESR and when to use a regular TESR.

Your recipe json has syntax errors. Specifically these lines: As an advice - install any kind of json syntax plugin in your IDE. It will then tell you if your json has syntax errors. Alternatively you can check your json files through a json validator like jsonlint.

Wow, that's a pretty crazy model (in terms of there is a lot of boxes). Instead of changing the offset I think you need to use the setRotationPoint() method. That is what places the rotation point in 3D space relative to the entity position. The way it works, if I remember correctly is: 1) You create a box by specifying the size in x, y, z. 2) You also specify the offset which is the point WITHIN the box where rotation occurs. 3) You then need to specify the rotation point which is actually placing the block in space. 4) You can then set rotation angle (around that point). Note that I believe that the naming of the methods is sort of misleading. You would think that setting the rotation point would imply setting the point within the block where it rotates; but it is the opposite, the offset does that and the set rotation point actually moves the whole block. Anyway, that is what I remember from when I used to do complicated animations. Also, for easier debugging you might want to try a much simpler model. Like maybe just make one block that you can control up and down first.