Flenix

That's exactly what I needed, thanks!

That's exactly what I needed, thanks!

I had a quick look through the events list and there's nothing specifically about creating chests, and the generation events don't seem to have any reference to them either - but the InitMapGenEvent does contain vague information about what structures are being generated. I'll have a proper look through the code tonight and see if that's do-able. Hopefully there will be some way to grab it via an event, that's a good idea - but if not does anyone else have any other ideas?

I had a quick look through the events list and there's nothing specifically about creating chests, and the generation events don't seem to have any reference to them either - but the InitMapGenEvent does contain vague information about what structures are being generated. I'll have a proper look through the code tonight and see if that's do-able. Hopefully there will be some way to grab it via an event, that's a good idea - but if not does anyone else have any other ideas?

Hey guys! I've got a slightly weird issue, so bear with me. I'll explain it as best I can. Basically, from what I understand the "normal" method of adding items to worldgen chests is using ChestGenHooks and WeightedRandomChestContent. From my understanding, that adds the item you provide to a list, which is then checked against when a chest is generated into the world, and it decides whether or not to generate your particular item based on the rarity value you provide. Now, in my mod, I'm wanting to add roughly ~150 items to these generated chests. There should be about a 1 in 20 chance that a chest will contain a single one of these items - but I only want it to contain one in that situation. On top of that, some of my items should be "Rarer" than others. Ideally, I want the game to simply call a method saying "I'm generating a chest now, what item should I add?", and then I can run my own code to decide which lucky item gets spawned in this situation (using RNGs to select the item type and then the rarity, and picking an item at random from the relevant category). This is how I handle stuff for mob drops and it works great. Is there any way for me to do that with dungeon chests by default? It's not 100% the end of the world if not as I'm adding my own custom chests alongside them - but it would just be nice to support the vanilla systems too (The other reason behind this is that about 50 of the items require a number of NBT values attached to function properly - meaning I'd have to create all those values for each itemstack when registering it. I dread to think how long and messy the class would get if I were to do that...) Any help appreciated

Hey guys! I've got a slightly weird issue, so bear with me. I'll explain it as best I can. Basically, from what I understand the "normal" method of adding items to worldgen chests is using ChestGenHooks and WeightedRandomChestContent. From my understanding, that adds the item you provide to a list, which is then checked against when a chest is generated into the world, and it decides whether or not to generate your particular item based on the rarity value you provide. Now, in my mod, I'm wanting to add roughly ~150 items to these generated chests. There should be about a 1 in 20 chance that a chest will contain a single one of these items - but I only want it to contain one in that situation. On top of that, some of my items should be "Rarer" than others. Ideally, I want the game to simply call a method saying "I'm generating a chest now, what item should I add?", and then I can run my own code to decide which lucky item gets spawned in this situation (using RNGs to select the item type and then the rarity, and picking an item at random from the relevant category). This is how I handle stuff for mob drops and it works great. Is there any way for me to do that with dungeon chests by default? It's not 100% the end of the world if not as I'm adding my own custom chests alongside them - but it would just be nice to support the vanilla systems too (The other reason behind this is that about 50 of the items require a number of NBT values attached to function properly - meaning I'd have to create all those values for each itemstack when registering it. I dread to think how long and messy the class would get if I were to do that...) Any help appreciated

Hello all. I'm trying to find a way to tell if the player broke a block client-side - any block at all. I've tried using BlockEvents.BreakEvent but that appears to be server-side only... (isRemote only returns false, never true) It's for rendering stuff, so I really don't want to send packets every time the player breaks a block... has anyone got any ideas?

I'm toying with this too right now, and noticed this thread is actually relatively fresh so thought I'd reply. Worth noting I'm in 1.7.10, but Zethariel's method is exactly what you want. Using nothing but information from this page, I've gotten the original player entity hidden and a pritnln of test when my own render calls doRender. TL;DR this code produces this result (note the lack of player model, that's in 3rd person): @SubscribeEvent public void renderPlayer(RenderPlayerEvent.Pre event) { if (event.entityPlayer.getHeldItem() != null && event.entityPlayer.getHeldItem().getItem() instanceof YOUR_MOD_CLASS) { event.setCanceled(true); //This hides the player RenderPlayerCustom renderPlayer = new RenderPlayerCustom(); //Initialize your render class renderPlayer.doRender((AbstractClientPlayer) event.entityPlayer, event.entityPlayer.posX, event.entityPlayer.posY, event.entityPlayer.posZ, 1.0F, event.partialRenderTick); //you can get the player, their coordinates and the partial ticktime from the event. That 1.0F, oddly, never gets used in the end, just passed around a bit. Unless I missed something. } } //in a custom class extending RenderPlayer @Override public void doRender(AbstractClientPlayer p_76986_1_, double p_76986_2_, double p_76986_4_, double p_76986_6_, float p_76986_8_, float p_76986_9_) { System.out.println("Test!"); } Then you just need to do your actual rendering code, which is whatever you want. Everything posted here should work - anything beyond this will be different between 1.7 and 1.8 because of how rendering changed. Shame as I'm effectively doing the same thing (although I'm adding elbows too) and I'd share my code otherwise. Ah well, good luck! EDIT: One other thing of note, if you copy the doRender method from RenderPlayer as a basis to work from, remember it does things like checking if the render event has been cancelled. You'll need to do some edits before it'll work

I've figured out the CAUSE of the issue, but still need a solution. My rendered block is ever so slightly larger than a standard block - stretching 1/16th to 1/8th outside its ordinary bounds. Now, I CAN remodel it and fit it within the block, but doing so just makes it appear a little bit too small IMO, so I'd rather find a solution. Anyone got any ideas? (Photo examples) Bad one (Block Y is 0.8-1.3, giving an 0.5x0.5x0.5 block) Note how the texture is 8 wide as it should be, but is a full 16 high. Good one (Y is 0.5-1.0, same size block) Here the texture is correct, rendering 8 pixels on each axis: And an example with both. Lower is 0.3-0.8, upper is 0.9-1.4

Not sure about 1.8, but assume it hasn't changed too much, here's how I'm doing it in 1.7.10. My block renders a railing if there is no block on a side, so here it checks for a block, and creates a collision if there isn't one (so you can't just walk through the railing.) if (hitboxNorth) { setBlockBounds(0.0F, 0.0F, 0.0F, 1.0F, 1.0F, 0.0625F); super.addCollisionBoxesToList(world, x, y, z, bb, list, entity); } if (hitboxSouth) { setBlockBounds(0.0F, 0.0F, 0.9375F, 1.0F, 1.0F, 1.0F); super.addCollisionBoxesToList(world, x, y, z, bb, list, entity); } if (hitboxEast) { setBlockBounds(0.9375F, 0.0F, 0.0625F, 1.0F, 1.0F, 1.0F); super.addCollisionBoxesToList(world, x, y, z, bb, list, entity); } if (hitboxWest) { setBlockBounds(0.0F, 0.0F, 0.0F, 0.0625F, 1.0F, 1.0F); super.addCollisionBoxesToList(world, x, y, z, bb, list, entity); } I was told you need the super after each like this. I'm not 100% sure the person who told me that is correct, however, as I've not finished this code myself yet so haven't tested any other ways. But, this adds multiple collisions which effectively is what you need

Hello all. I'm trying to make some new blocks, and I'm using the RenderBlocks renderStandardBlock method for doing so. However, it's treating textures oddly, and I can't figure out why. I've stripped my class right down to bare basics, trying to emulate this guide: http://greyminecraftcoder.blogspot.com.au/2013/07/rendering-non-standard-blocks.html In that article, you can see the textures get truncated, so they render as if a full block, but only actually show the relevant part of it. In my case, this happens (as I want it to) on the top and bottom textures. However, the side textures are all showing the full size texture scaled down: Has anyone got any idea why this might be happening? I'm guessing I've just missed something minor, but I can't seem to find any other examples that are any different to mine... Render class: package co.uk.silvania.cities.core.client.renders; import org.lwjgl.opengl.GL11; import co.uk.silvania.cities.core.blocks.BlockWalkway; import co.uk.silvania.cities.core.client.ClientProxy; import cpw.mods.fml.client.registry.ISimpleBlockRenderingHandler; import net.minecraft.block.Block; import net.minecraft.client.renderer.RenderBlocks; import net.minecraft.client.renderer.Tessellator; import net.minecraft.world.IBlockAccess; public class WalkwayRenderer implements ISimpleBlockRenderingHandler { @Override public void renderInventoryBlock(Block block, int metadata, int modelId, RenderBlocks renderer) {} @Override public boolean renderWorldBlock(IBlockAccess world, int x, int y, int z, Block block, int modelId, RenderBlocks renderer) { renderBlock(0.25D, 0.9D, 0.25D, 0.75D, 1.4D, 0.75D, true, renderer, block, x, y, z, 0); return true; } @Override public boolean shouldRender3DInInventory(int modelId) { return false; } @Override public int getRenderId() { return ClientProxy.walkwayRenderID; } public void renderBlock(double minX, double minY, double minZ, double maxX, double maxY, double maxZ, boolean existsInWorld, RenderBlocks renderer, Block block, int x, int y, int z, int meta) { renderer.setRenderBounds(minX, minY, minZ, maxX, maxY, maxZ); renderer.renderStandardBlock(block, x, y, z); } } As for getting the texture, in my Block's class: @Override public IIcon getIcon(int side, int metadata) { return Blocks.planks.getIcon(0, textureMeta); } Any help much appreciated

Still having problems here and it makes me feel sad inside

^What they said. For the generator, you need to use the TileEntity's onUpdate method. If there is fuel in the slot, then find the fuel's value (look in TileEntityFurnace for that), then remove the item and add that value to the TileEntity's saved value. You'll need to use NBT for that. It's likely you want to show that value in some sort of GUI too, so you'll need to sync it to the client. I won't provide the code, because obviously it's important to learn it, but the methods you'll need in your TileEntity for that are: void writeToNBT(NBTTagCompound nbt) - Writes the custom fuel value void readFromNBT(NBTTagCompound nbt) - Reads the value back for usage Packet getDescriptionPacket() - Writes NBT to a packet to be sent to the client void onDataPacket(NetworkManager net, S35PacketUpdateTileEntity pkt) - Reads the packet on the client (to show the value in a GUI) With those, you can generate fuel and save the value, but it won't keep any extra coal in the inventory - you'll need to implement IInventory for that, as well as make a container. As for your pipes, you'll need a tank or similar first (Similar to above, a tile entity with NBT stuff). Then in your onUpdate, check around your tank for a pipe, and if there is one, fill the pipe with your liquid (which is effectively a tiny tank). Alternatively, you could just track through the pipes until you find another tank/block that accepts liquids - which is how ExtraUtilities works but can be slow for large networks.

The arguments for Slot are IInventory inventory, int slotId, int xPos and int yPos. So, it's the last two numbers that position your slots in relation to your GUI. Judging from the math you've used there, I'm guessing you just looked at an example which utilizes a for loop. For loops are great for adding multiple slots which are grouped together, so if you have two rows of 3 slots (?) you'd just use two for loops - One counts to two and adjusts the Y value, and the second counts to 3 adjusting the X. Of course, you still need to define the starting point, hence for example (44 + k * 18) - starting at 44, add on k * 18 - adding 18 for the first iteration, 36 for the second and so on. It's worth noting as well (as this threw me off at first), in all the vanilla Minecraft GUI's (and therefore most mods which copy them), the slots are actually 18x18 texture-wise, there's a buffer of 1 pixel on every side. So, although the physical white-box slot is only 16x16, you need to add 18 for each space (hence the multiplication of 18 in the code you have)

Is your GUI taking up the full size of the PNG file? The width/height you specify are purely the size of your ACTUAL GUI within the file. So, if you have a 256x256 file, but your drawn GUI is actually only 200x200, it's the 200x200 you need to specify.