Matryoshika

I am so dumb. Of course respawning the same itemstack would give that issue =_= Thank you!

I have a TileEntity called TileSmelter. It only has 1 function right now, where it will have 2 soon. The function that exists right now, is taking placed ores in the world within a small radius, and "cook" them into 1 ingot, dropping the ingot back into the world (which will require energy in the near future.) However, most of the time, the EntityItem that is spawned by the TileSmelter, can be seen for a fraction of a second, likely just 1 tick, before it vanishes. It seems to be that picking up the first spawned EntityItem works fine, but after that, the rest behave as explained, simply vanishing from sight. Anyone able to figure out, or already knows why, the issue is happening? Code can be found here: https://github.com/Matryoshika/Saligia/blob/master/src/main/java/se/Matryoshika/Saligia/Content/Tiles/Utility/TileSmelter.java

Don't use only the item. Compare the itemstack's meta data, as well as making sure the item == dye. I'm guessing you have an ItemStack and that "item" is the ItemStack.getItem()? if so: pseudo-code if(stack.getItem() == Items.dye && stack.getMeta == 15) //If item is a dye, and if the meta corresponds to "white" You can change the models depending on the blockstate. If you just want to change the texture on a side, you can use the resource-pack method of doing so (using .mcmeta files). If you want to -animate- it, you can either use TESR's for tiles (quite bad on performance) or make the block actually place an entity in the world, and edit it that way (cant seem to be able to find the GitHub pages that shows how to do this though)

You need to override addCollisionBoxToList and do nothing in it. Vanilla example: BlockEndPortal; public void addCollisionBoxToList(IBlockState state, World worldIn, BlockPos pos, AxisAlignedBB entityBox, List<AxisAlignedBB> collidingBoxes, @Nullable Entity entityIn) { }

The field blockHardness is protected , meaning only classes in the same package, OR sub-classes in other packages (classes that extend Block) can "see" this field. This tells me that the class you are doing this in, is not a class extending Block . What exactly are you trying to do? Why do you need the blockHardness for a non-block class?

Initial rundown: I have a Block. It is called BlockRitualMaster . Using a Ritual Activator (item) & a correct placement of various blocks around the BlockRitualMaster (looked up using a custom registration of Object[][]'s containing x, y, z, Block), you "activate" it, turning it into sub-blocks, each with their own tileentity that performs a specific task. To help with placing the multiblock around the BlockRitualMaster, the block has a basic TileRitual tileentity that uses a TESR. Depending on what ritual you tried to activate using the Ritual Activator , the tile uses the passed ritual, and looks up the RitualRegistry to see if the blocks the ritual requires are placed. If any are missing, it starts to render the missing blocks, where they should be, for a short period of time, before fading away again. All of this; works just fine. Except for one thing: Depending on where you stand, the first block rendered, keeps it's source-factor. Move the camera a tiny bit, and it renders just fine. Example: Working as intended. Example: Not working as intended. I've changed the whole "render this specific block" to it's own method ( renderMultiblock ) that gets called by the TESR's renderTileEntityAt , and made sure to encompass the method call with the appropriate GL11.glBlendFunc, and returning the blend to it's normal state afterwards, yet that first block keeps rendering odd. TESR code: http://pastebin.com/BUxxap8E TL;DR: First rendered block doesn't behave as it should when it comes to GL11.glBlendFunc. Has alpha in most angles, looks like normal block in the other angles.

You can either create a new parent-json that inverts what block-all/block-cross does and use that for the item-block model, or the easier method, simply not use the block-model as a parent, and instead have it render the .png directly, like this: { "parent": "item/generated", "textures": { "layer0": "underworld:items/sugarbeet" } }

@_Dommi_ I didn't mean for you to copy/paste directly from my github. Your crop creates blaze-powder, no? Then I assume you want it to only grow on soulsand. Use that instead of grass|dirt|sand. The nullpointer occurs here: if (facing == EnumFacing.UP && playerIn.canPlayerEdit(pos.offset(facing), facing, stack) && worldIn.isAirBlock(pos.up()) && this.crops.canSustainBush(state)) Something here, is called, when it does not exist. You could just simply have if-checks before hand and check if they are null, System.out.print(variable + " is null") and return the method. Then you know what is wrong. =_= That's on me, actually. Copied from the github. Lesson learnt: don't code stuff when sick.

@_Dommi_ You need to override onItemUse(ItemStack stack, EntityPlayer playerIn, World worldIn, BlockPos pos, EnumHand hand, EnumFacing facing, float hitX, float hitY, float hitZ) in your seed class. You can see how my itemseeds do so in my previous post. @Winnetrie You... What are.... how... What? You are calling your proxy's init, from preInit... That is not what I told you to do. In your main's preInit, call proxy.preInit(). In your clientProxy's preInit, call ModItems.registerRenders ModelLoader HAS to be registered in preInit. If you use Minecraft::getItemModelMesher, then yes, you register in init, but that is buggy as heck, which is why Forge had to add ModelLoader as a better alternative.

@_Dommi_ Show your ItemSeed class. If the crop-block is placed just fine, then something is likely wrong with your seed. I have a working ItemSeed implementation here that you can take a look at. @winnetrie 1) Mojang will be enforcing lowercase soon for resources, I've heard. It's good practice to follow what will come, and not having to redo all work when updating etc. 2) (Depending on your OS (Windows falls under here)) The dev-environment will ignore lower/uppercase mismatches, and show you the resource for supermod:SuPeRbLoCk == supermod:superblock. This means that if your resources are typed with different cases, they will still show as expected. However, when compiled into a .jar (really just a .zip file with different name) it cannot do this anymore, leading to SuPeRbLoCk =! superblock. It's a pain in the proverbial behind to find all these issues with the naked eye. 3) I don't see you calling ModItems.registerRenders. This has to be done in preInit, in the clientproxy.

Well, seems that the rendering of the itemblock uses blending with destination factor of 0 (or equivalent outcome) as after hours and hours of debugging, I found I could replicate the dark model by rendering the placed block with blending dfactor of 0. In the end, I had to compromise. Couldn't get [placed block] & [held itemblock] to ever be fully the same, so now it uses default model, and the extra is added through in-world activation. For others if they have similar issues: The actual part of the item-block rendering that had the dfactor of 0, was during the tesselator call. Tessellator tessellator = Tessellator.getInstance(); tessellator.getBuffer().begin(GL11.GL_QUADS, DefaultVertexFormats.BLOCK); Minecraft.getMinecraft().getBlockRendererDispatcher().getBlockModelRenderer().renderModel( world, getBakedModel(), world.getBlockState(te.getPos()), te.getPos(), Tessellator.getInstance().getBuffer(), false); tessellator.draw(); Without that, everything rendered fine, except the body of the TESR was of course missing. The block itself had proper dfactor, just not the itemblock.

Hello! I've been working on a block (Metamorphic Table) that converts ItemStack A -> ItemStack B when right-clicked / fed items (Using predefined recipes). It is animated. Depending on what item you are holding, and if that item has an output in the table, it renders the output as a ghost-item, figuratively and literally. After hours of tearing my code apart, I've managed to make it render [in world], [in inventory] & [in Hand], however, when held, the model turns dark, akin to a forgotten GL11.glDisable(GL11.GL_LIGHTING), though as far as I can see, everything is put back to it's original state before being 'popped. TESR code Anyone able to see why this would happen?

As mentioned by diesieben07, that will not work. Items are Singletons. You change a variable in the Item-class for one item, you change it for all. This also goes for Blocks. Change one, change them all. Data can only be "stored" in these, using either Meta-data (4 byte max for blocks) or using the itemstack's ability to store NBTTagCompounds . @ratepenade I'd recommend saving the wanted string to NBT, and then grab that NBT in Item#addInformation .

[This client] doesn't know anything about [that client]. You would need to use packets for everything, to even get it to work remotely. It would be much easier and faster, if this was server-side only.

In Eclipse, you can use File->Import. From there, select General->Existing Projects into Workspace. Then you just need to define from what root-directory to look for the files, and finish. If you have the project stored somewhere on the internet using Git (GitHub, GitLab etc) you can select: File->Import. Select Git->Projects from Git And choose either Existing local Repository, which will import the files from the self-explanatory local repository OR you can choose Clone URI, which will download the files from the remote repository (From GitHub etc)

Just use GameRegistry#register(Object) to register your blocks and items. ModelLoader also has to be called in preInit, after your registration of the blocks. Also, for the ModelResourceLocation , do not manually prefix the name. Simply call block.getRegistryName , and it will prefix it for you. If I have a block that I call "superblock", in a mod called "supermod", getRegistryName will return "supermod:superblock" for me. This also means that the files for which the blockstate & models will try to look for, have to have the same name as what was used for the setRegistryName , which here would be "superblock".

Where do you register the render for these? (main or proxies?) When do you register them? (preInit, init, postInit) How do you render them? Minecraft::getItemModelMesher() (think that's the method name) or with ModelLoader? Post your classes that deals with these.

Post your actual Client-Proxy. You pasted the ModItems class twice.

If the NPE is caused by getRegistryName() , then either the item/block you are trying to get the registry name of, does not have a registry name, or you are trying to access the registry name before you actually do set it. If the NPE is caused by the, as mentioned, Item.getItemFromBlock(block) , then skip that method altogether. Instead, create an ItemBlock using the block as the passed parameter, and then register that. ItemBlock is instantiated just like an ItemStack.

The Ore recipes, make use of one or more items from the OreDictionary. If I want a recipe to use any type of dye, like bonemeal, and also include any other dyes added by other mods, like Forestry drops, then I'd just have to specify the string "dye". For a dye of a specific colour, I'd specify something like "dyeBlack". Common OreDict names and naming conventions can be found here.

If you must maintain BlockContainer , then in getRenderType , do not super, but rather return EnumBlockRenderType.MODEL instead.

You're saying that tiles HAVE to use TESR? Cant you just render the normal way? Where the heck am I saying that? I said that vanilla code, AKA the tiles created by the people in Mojang, uses TESR. I never stated, and never will state, that you HAVE to use TESR's for tiles, as that is not true.

I would recommend you use a graphical user interface for Git, to see what you are doing. Git is very powerful, but sometimes hard to understand what you are doing. As NoVa linked, there is SourceTreeApp, but I also know of GitKraken & SmartGit. Of course, there are several others out there as well. See which you find the best. You can also use GitLab.com to gain your own "private" project, which can be easily exported to GitHub if wanted (can also import projects from GitHub to GitLab).