Matryoshika

@larsgerrits No, he was using it "correctly". Quotation marks as the method wants the chunk coords, but a chunk can of course contain 1-256 different biomes @winnetrie The biome next to the river... It doesn't happen to be in the same chunk? Because all you do, is say "[this chunk] has a river. Spawn [block] in this chunk. Where? Randomly." I recommend that you change your generateOre to make use of a blockpos directly, or at least a regular x & z coordinate instead of chunk coords. This way, you can more easily oversee where they spawn. I also recommend that you instead for-loop through BlockPos#getAllInBox(from, to) and check if the biome is what you want, instead of randomly generating nearby, where the biome can have changed drastically, just 1 block away.

I don't think you can bind textures to .obj models. With my own .obj models, I've baked the texture (material) to the UV-map of the model inside the rendering program (Blender in my case), meaning all I need is the accompanying .mtl file in the same folder as the .obj.

Believe the better place for this thread would be this board: http://www.minecraftforge.net/forum/index.php?board=15.0 And issue seems to be caused by a mod trying to create a new instance of an object, through reflection, but failing, either with wrong varargs, or trying to instantiate it with a constructor that has changed. Take out the mods out one by one, and find which mod is doing this. Once you have done so, and found the culprit, go to their project site (GitHub, CurseForge, wherever-you-got-the-mod-from) and file a bug-report directly to the mod-author. He/she/it needs to fix it.

Completely incorrect. A custom WorldProvider for a custom dimension can do this easily. With the DimensionManager, if that is the correct name (not at my pc atm) you can even re-register other dimensions. Bad practice, but entirely possible.

@Winnetrie Use the model "block/wall_post" as a parent instead of "builtin/generated" @jeffryfisher I might be wrong, but I believe that Forge's blockstate files make use of submodels not multiparts.

Caused by: java.lang.IllegalArgumentException: Invalid hand null at net.minecraft.entity.EntityLivingBase.getHeldItem(EntityLivingBase.java:1654) ~[EntityLivingBase.class:?] at com.moreoresmod.main.handler.GuiHandler.getClientGuiElement(GuiHandler.java:62) ~[GuiHandler.class:?] Issue seems to happen here: return new GuiBackpack(player.inventory, new InventoryBackpack(player.getHeldItem(player.getActiveHand()))); Check the hand and make sure it is not null before returning.

No. As far as I can read from your posts, what my code does, and what you want, are different. Read it through. Learn what happens. Adapt what suits your needs. Create your own code.

Sounds like an issue I had a week or so ago, with one of my blocks. Are you sure that the itemstack is a new itemstack? You cannot really add something to your inventory, which already exists in your inventory, because it IS already in your inventory. Compare the ItemStacks. Either run a few System.out.println(stack.toString) or compare the stacks directly, and see if they equal eachother.

What are you doing with all of these Math.floor 's for? As far as I can see, that's the X, Y & Z coordinate, which for, when looking for blocks, integers will do just fine. Just use BlockPos#getAllInBox to get a list of BlockPos' that you can loop through. I have my own CropGrower (which also harvests them, resetting them to their youngest stage) here. Lines of interest are: #57, and #104->115

I have not yet seen a way to get -only- the modid, but as you have an item, you can get the registryname which contains it, then split the string with the regex ":". Hacky way, but should be do-able.

No, that is not the whole error. What I am interested in, is the tiny tiny paragraph: "Caused by: _____" An example of this, would be: [spoiler=Example error] [06:10:28] [Client thread/ERROR] [FML]: Exception loading model for variant saligia:cropgrower#inventory for item "saligia:cropgrower", normal location exception: net.minecraftforge.client.model.ModelLoaderRegistry$LoaderException: Exception loading model saligia:item/cropgrower with loader VanillaLoader.INSTANCE, skipping at net.minecraftforge.client.model.ModelLoaderRegistry.getModel(ModelLoaderRegistry.java:153) ~[ModelLoaderRegistry.class:?] at net.minecraftforge.client.model.ModelLoader.loadItemModels(ModelLoader.java:317) ~[ModelLoader.class:?] at net.minecraft.client.renderer.block.model.ModelBakery.loadVariantItemModels(ModelBakery.java:170) ~[ModelBakery.class:?] at net.minecraftforge.client.model.ModelLoader.setupModelRegistry(ModelLoader.java:147) ~[ModelLoader.class:?] at net.minecraft.client.renderer.block.model.ModelManager.onResourceManagerReload(ModelManager.java:28) [ModelManager.class:?] at net.minecraft.client.resources.SimpleReloadableResourceManager.notifyReloadListeners(SimpleReloadableResourceManager.java:132) [simpleReloadableResourceManager.class:?] at net.minecraft.client.resources.SimpleReloadableResourceManager.reloadResources(SimpleReloadableResourceManager.java:113) [simpleReloadableResourceManager.class:?] at net.minecraft.client.Minecraft.refreshResources(Minecraft.java:799) [Minecraft.class:?] at net.minecraft.client.Minecraft.processKeyF3(Minecraft.java:2146) [Minecraft.class:?] at net.minecraft.client.Minecraft.runTickKeyboard(Minecraft.java:2002) [Minecraft.class:?] at net.minecraft.client.Minecraft.runTick(Minecraft.java:1846) [Minecraft.class:?] at net.minecraft.client.Minecraft.runGameLoop(Minecraft.java:1118) [Minecraft.class:?] at net.minecraft.client.Minecraft.run(Minecraft.java:406) [Minecraft.class:?] at net.minecraft.client.main.Main.main(Main.java:118) [Main.class:?] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_101] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_101] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_101] at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_101] at net.minecraft.launchwrapper.Launch.launch(Launch.java:135) [launchwrapper-1.12.jar:?] at net.minecraft.launchwrapper.Launch.main(Launch.java:28) [launchwrapper-1.12.jar:?] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_101] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_101] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_101] at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_101] at net.minecraftforge.gradle.GradleStartCommon.launch(GradleStartCommon.java:97) [start/:?] at GradleStart.main(GradleStart.java:26) [start/:?] Caused by: java.io.FileNotFoundException: saligia:models/item/cropgrower.json at net.minecraft.client.resources.FallbackResourceManager.getResource(FallbackResourceManager.java:68) ~[FallbackResourceManager.class:?] at net.minecraft.client.resources.SimpleReloadableResourceManager.getResource(SimpleReloadableResourceManager.java:65) ~[simpleReloadableResourceManager.class:?] at net.minecraft.client.renderer.block.model.ModelBakery.loadModel(ModelBakery.java:311) ~[ModelBakery.class:?] at net.minecraftforge.client.model.ModelLoader.access$1100(ModelLoader.java:118) ~[ModelLoader.class:?] at net.minecraftforge.client.model.ModelLoader$VanillaLoader.loadModel(ModelLoader.java:868) ~[ModelLoader$VanillaLoader.class:?] at net.minecraftforge.client.model.ModelLoaderRegistry.getModel(ModelLoaderRegistry.java:149) ~[ModelLoaderRegistry.class:?] ... 25 more

Does console log any errors when it tries to load the model for this block?

What? Tools? Stacks? Enchanted items = unstackable Tools = unstackable Do you mean that you shift-click and craft several tools at once? Or do you mean that the recipe outputs something with stacksize > 1, and nothing happens?

First and foremost: Your forge-blockstate json is incorrect. Please verify your models with JSON validators. I recommend JSONLint which is purely online. It can be found here: http://jsonlint.com/ Secondly: you need to read up on how Minecraft's modeling system works. You are supposed to use "normal" & "inventory" as the "containers" for your model, unless you properly know what you are doing. The "north", "south" etc variants go IN these. I make use of Forge's multi-layer (on a very basic level) here. The multi-layer points to another blockstate file, though you can of course reference other models directly instead. The mentioned "normal", "inventory" or your own custom variants, go in the, and to quote- "WHAT TYPE OF MODEL IS THIS??".

@TGG Thank you. Yes, I know the model of the block cannot be "animated" however, you can -use- that model TO animate. [spoiler=Example] Example code: https://github.com/Matryoshika/Underworld/blob/master/src/main/java/se/Matryoshika/Underworld/Content/Rendering/TERenderEnderPortal.java Example image: The code inside the spoiler is what I have been using mostly, to render special blocks and TESR's, however, for very common blocks, the overhead would have been too much for my liking, thus why I made this thread. However, I've hit a wall that sadly means I need to give up the rotational aspect of the blocks. While I can render the .obj-models, they render without any visible edges in the model. Think of a monotone colored model, where the edges blend together too well. However, you did manage to teach me how to optimize my TESR's, for which I am quite thankful for. The blocks will be too dull as just blocks, so I will keep the TESR's, just have them work in tandem with the actual block-model.

I did. I got 5 Utility blocks. These are meant to do specific tasks, like picking up EntityItems, from example the (internally named) CropGrower that grows and harvests pretty much anything that implements IGrowable, and more (stems, sugarcane etc), or reversely, the blockplacer that places EntityItems if possible. My point is: These are meant to be commonly used blocks for setups in your base! I was testing with 8 of the CropGrowers, and my FPS dropped by a considerate amount! Still above 60, but the point is made. I do not want to create a renderer that will be shared by many (5 made, 10 more planned, who knows after that) blocks, which can make the game unplayable for people who are unlucky enough to have bad computers! As far as I've read, TESR's do not bake the model, hence why they are lacking in optimization. Of course, you can get a baked model and render it after translating it, using Minecraft::renderModel in the renderTileEntityAt method, however, damage is still done, as the TESR is made to scrap and re-draw every damned frame. The model itself is a floating crystal. Translucent. About 85% alpha. It also needs to spin. Apart from the translation, there also needs to be GLxx calls to enable blend, do blend, rotate, and after rendering, undo these (blend is needed as I cannot seem to replicate the behaviour of BlockRenderLayer.TRANSLUCENT ). Translate + enableBlend + blend + rotate + undo blend + undo rotate + disableBlend = 7 calls to GLxx. That's far from a simple baked model.

So I'm taking it that using an Entity instead of TileEntity is the only viable option for animation without the overhead, and with sane amounts of code per implementation? All this trouble for rotating the yaw of the model =_=

There was an issue a few months ago with a specific mod, that did something like this. It would get a list of patreons on startup, from a database, and render the skins of them etc in a few machines. Guess what happened when one day, the db was down. Crashes, everywhere. Every damn server that had this mod (which was in a pack distributed by FTB, so not few cases, mind you). The dev's github had an explosion of angry server-owners and an even larger host of seriously annoyed players that morning.

I'm talking about 1 degree every ~2 seconds. I thought the blockstate was locked at multiples of 90? (or was that 22.5?) If this is that easy, I'm going to cry...

Not sure at all that this will work, but I did see a public method in the BlockModelRenderer yesterday called renderModelBrightness . What happens if you call this instead of using the tessellator? (renderModelBrightness does a few jumps, and at last lands on renderModelBrightnessColorQuads which seems to draw the model for you (remember to translate the model to where you want it before doing this!)) The call would thus be Minecraft.getMinecraft().getBlockRendererDispatcher().getBlockModelRenderer().renderModelBrightness Pass true for the last boolean btw. If false, it seems to color... the model with the value of the passed brightness... I'm not stating that this will work. I'm working on the tangent that your model has no brightness = renders completely dark. If that's incorrect, well then, then we know that is not the case.

I've been coding a couple of "utility" blocks (speeds furnaces, picks up stuff, places stuff, etc). They all look the same (.obj models FYI, with only difference being the colour). I want to change their yaw, that is, make them rotate around the y-axis, very slowly. That is all I want these to do. However, I do not see TESR rendering being an option at all, due to the amount of different blocks, each with their own functionality. A player just near a couple of these (7-, will see a notable decrease in FPS. So, I'm asking this: Is there an option available to render these models, that fills these requirements? 1) Less overhead compared to standard TESR. 2) Gives access (direct or hell, even with reflection if needed) to rotating the model around at least the y-axis. 3) Easily implementable for several different blocks. (For example, being required to pass the type, brings issues with long list of copy/paste'd code with only difference being the passed type, every 20 lines.) I have already tested Forge's own CapabilityAnimation to render these, but that very quickly becomes extremely bulky when being implemented for several blocks. The added requirement of having a block, tile AND an entity, for each damned model... just no. Please spare me. The damned ClientProxy (or the class being initialized FROM it, would be ~amount of blocks*30 lines long. With 5 already made, another 10 planned, and who knows in the future, that'd be a ridiculous copy/paste'd wall of text) If I'm out of luck, and nothing like this exists, I'm thinking of simply removing the TileEntity code, and have the block place down a proper Entity instead, which does the same thing that the TileEntity did, of which I can have it's onUpdate() simply edit the yaw by a degree every ~2-3 seconds. Would there be any significant drawbacks from this?

The issue is caused by a missing file. Caused by: java.io.FileNotFoundException: xelamod:models/item/Hoja.json It is looking for a file in src/main/resources/assets/xelamod/models/item, which is called Hoja.json.

No. Never set the RegistryName FROM the UnlocalizedName. If anything, it is supposed to be the other way around. Unlocalized name can change at any time. RegistryName should NOT change, as that will erase any crafted/placed items/blocks in any map with the old RegistryName. And either in your item/blocks constructor, or when you are registering it.

1) Do not use GameRegistry.registerItem() , just simply use GameRegistry.register() . The registration was streamlined some time ago. 2) You are never setting a RegistryName for this item, as fas as I can see. 3) Please dear god of any religion, burn the tutorials that use Minecraft::register() . You need to use ModelLoader instead. Minecraft::register is VERY prone to cause issues, which is why forge provides its own rendering registration. 4) Don't extend builtin/generated. I believe you should extend item/generated instead. Not at my pc so cannot check the exact name. 5) If you get an error in your console, then -please- post that error here. We cannot know the full issue without the cause. I have a very simple tutorial on how to register and render items here. It demonstrates looped registration vs. monotonous retyping the same lines over and over, so do carry that in mind. Stick to either the simple or looped files

Translation / Scaling: Do this inside the program from which you exported the .obj model. I use blender, and find myself using 0.5 default scale, and I believe translated by 0.5, -0.5, 0.5, xzy respectively (blender switches z & y for some reason =_= ) to get the normal Minecraft 1³ block You "texture" the .obj through materials that can either be filled with various colours, or you import a texture and connect it to the material, through the use of a UV-map. If you chose to use this second option, you need to also bake the model. The material that has all this information, is stored in the .mtl file that is exported along with the .obj file.