Daeruin

Interesting. That worked great in the PlayerInteractEvent, but not in BlockEvent#PlaceEvent. Perhaps PlaceEvent is only called on one side? There's nothing in the Javadoc about that, but it would make sense given the behavior. That's sad. I was excited to discover that event. It seemed like just what I needed.

It's...not complicated. Well, eventually I'll add more to check whatever conditions I'm interested in. For now I just wanted to make sure it would work at all, and I'm not happy with how the block appears briefly. @SubscribeEvent public void onBlockPlaced(BlockEvent.PlaceEvent event) { if (!event.getWorld().isRemote) { if (event.getPlacedBlock().getBlock() == Blocks.DIRT) { event.setCanceled(true); } } }

When a block is broken, it will call Block#harvestBlock > dropBlockAsItem > dropBlockAsItemWithChance > getDrops > getItemDropped. You could try putting a breakpoint in there and tracing through the chain to see where it goes awry.

I am trying to prevent a vanilla block from being placed under certain circumstances. I have used BlockEvent#PlaceEvent and PlayerInteractEvent#RightClickBlock successfully; however, a brief image of the block always appears on the screen, then quickly disappears. I would prefer to cancel the block placement without this brief image flashing on the screen. Is there a way to intercept the placement earlier? I've looked over the available events and didn't find anything else that seemed like it would work, but perhaps I'm missing something. I have also noticed that when canceling the block placement, the ItemStack size decreases, yet if I move the stack to a different inventory slot or log out and back in, it magically jumps back up to the original size—or even reappears from nothing if the stack was completely depleted. Anyone know what's up with that? Do I need to, like, manually modify the ItemStack to prevent that before canceling the event? Seems weird.

When I was brand new to Java and modding, I had a hard time understanding properties, too. You will be doing yourself a favor in the long run if you work hard at understanding Java. Also try some detailed modding tutorials. I used BedrockMiner's to start out with and found them more helpful than most other tutorials because they address basic concepts. The biggest disadvantage is the most recent ones are still for 1.8.9. But this one might help you get a better idea of what block properties are and how they can work: https://bedrockminer.jimdo.com/modding-tutorials/basic-modding-1-8/blockstates-and-metadata/ Keep in mind this tutorial uses an enum to store the properties, but it looks like for crops you will use an integer. Beyond just defining the property itself (which is the one line you quoted above), there are probably a few methods that refer to the property that you will also need to modify.

Look at BlockFurnace for an example.

I figured out why. It has to do with the way I'm adding things to the list. I was checking to see if the BlockPos was in the list of things I already checked, but I wasn't checking to see if it was already in the list waiting to be checked. Because I do a round of adding stuff to the queue up front, before starting to iterate on the queue, those things were getting added to the queue twice. Should be pretty easy to fix. I don't see an eye icon or <> icon. I have a single row of icons with B, I, U, link, quote, emoticon, two lists, and preview. It looks like you may be doing something special with making the blocks fall. Are you just breaking and harvesting the blocks, or do you have some nifty method for making the blocks fall to the ground horizontally like a real tree? I've been messing with that piece and having some weird behavior for big oak, jungle trees, and regular oaks with branches. I think I can deal with it, but I was curious to see if you've already solved those problems.

I just realized another tradeoff between LinkedList and ArrayList. With the ArrayList, you can keep it around for later use. With the LinkedList, you can't look at an element in the list with removing it from the list, which requires you to store things in yet another list if you want to do something with them later. But if you do everything you need to at the time you get the element from the list, you wouldn't need to store them elsewhere.

Hmm, that puts a damper on things.

Is this a custom block you want to do this with? Or a vanilla block? Could you maybe detect when the block catches on fire and set the block to a different block state and key off that when the block is destroyed to change the block's drops?

Good point! For that matter, it seems possible that modded trees could defy the pattern Draco pointed out early in this thread. For example, you could have long branches with log blocks below another log block.

An iterator works fine if you use the iterator's add and remove methods (iterator.add). I discovered that after running into the ConcurrentModificationException and doing some more research. There's another problem, however, because the iterator's cursor is always in between elements in the collection. When you add a new object to the collection, it gets placed behind the cursor. I have to keep track of how many things I've added and move the iterator back to look at them. I'm thinking I'll switch back to a queue at this point. The only reason I wanted to try the ArrayList in the first place was to see if it was somehow more accurate with detecting duplicates in the collection. I've tried using a LinkedList, an ArrayList, and now a hash set to hold the blocks I've already looked at. In each case, I just used the collection's #contains method to see if the BlockPos is already in the list. Looks like the same thing you're doing here: if (!checked.contains(toAdd)) My code is currently part of a private BitBucket repository. I didn't want it to be public at first, because I was embarrassed. I was going to post some of my code here , but it looks like it isn't possible to do spoilers or code blocks in topic replies. Unless I'm missing something? Come to think of it, how do you do that monospace font in replies? All I see are bold, italic, and underline. By the way, I loved your idea of using a list of BlockPos offsets and iterating through that to scan for log blocks. I tried that in my code, and it's so much cleaner than what I was doing before, which was basically a giant block of code with a million BlockPos.up().north().east() references and the like.

I'm using a method very similar to yours. I've gone through several versions of this already. In my current iteration I'm only using two collections: one for blocks that need to be checked, and one for blocks I've already checked. The collection of blocks that need to be checked is an ArrayList. I use an iterator to work through it and only add blocks to it if they are logs and aren't in the list of blocks I've already checked. When I'm done, theoretically, it should only contain log blocks that need to fall. However, I'm having trouble getting my collections to compare BlockPos objects correctly. It only seems to detect equivalents some of the time, so I always end up with duplicate BlockPos objects in my final list. Is that happening to you? One idea for improving performance is to check for what type of log is being broken. If it's a birch log, for example, you only need to check logs directly above (no branches in birch trees).

I have been interested in doing this, as well, and got some code working a few days ago that broke the logs for any tree. I was using a HarvestEvent. I was just letting the leaves decay on their own. I got sidetracked trying to re-place the logs horizontally on the ground, and now it's all messy and not working at the moment. clowcadia, it's pretty clear that code from BlockLeaves isn't checking some predefined data about which leaves belong to any particular tree. I haven't gone through in detail, but it looks like it's just checking a 4x4x4 area around the leaf block in question to see if that area contains a block that can sustain leaves (i.e., a log block). You could do something similar and just break every leaf within 4 blocks of each log in the tree. A more promising direction would be looking at the world gen classes to see how trees are generated. If you're cutting down an oak log, you can do a scan that mimics how the world generator places oak trees and destroy all the leaves in that area.

I am such an idiot. I was testing in creative mode.

I am using the AxisAlignedBB measurements shown in my original post. I copied them directly from BlockCactus. I am already doing this. Sorry, I didn't include it in my original post.

This seems like it should be straightforward. I have a campfire block, and I want players to take damage when they run into it. I copied this code directly from BlockCactus, but it doesn't work. Instead of taking damage, the player auto-jumps on top of the block. protected static final AxisAlignedBB CACTUS_COLLISION_AABB = new AxisAlignedBB(0.0625D, 0.0D, 0.0625D, 0.9375D, 0.9375D, 0.9375D); protected static final AxisAlignedBB CACTUS_AABB = new AxisAlignedBB(0.0625D, 0.0D, 0.0625D, 0.9375D, 1.0D, 0.9375D); @Override public AxisAlignedBB getCollisionBoundingBox(IBlockState blockState, World worldIn, BlockPos pos) { return CACTUS_COLLISION_AABB; } @SideOnly(Side.CLIENT) public AxisAlignedBB getSelectedBoundingBox(IBlockState state, World worldIn, BlockPos pos) { return CACTUS_AABB.offset(pos); } @Override public void onEntityCollidedWithBlock(World worldIn, BlockPos pos, IBlockState state, Entity entityIn) { entityIn.attackEntityFrom(DamageSource.cactus, 1.0F); } I saw a comment somewhere about using addCollisionBoxToList, so I played around with that a little. I didn't get anywhere with that. What do I need to do here?

Oh, of course! Simple and works perfectly. Here's the method I ended up creating: // Attempts to insert the player's held item into the appropriate slot in the campfire // Returns true if something was inserted, otherwise false public boolean insertHeldItem(EntityPlayer player, EnumHand hand) { ItemStack heldItem = player.getHeldItem(hand); int destinationSlot = 0; if (isItemFuel(heldItem)) destinationSlot = SLOT_FUEL; else if (FurnaceRecipes.instance().getSmeltingResult(heldItem) != null) destinationSlot = SLOT_INPUT; else return false; ItemStack remainder = inventory.insertItem(destinationSlot, heldItem, false); player.setHeldItem(hand, remainder); if (remainder == heldItem) return false; else return true; } SLOT_FUEL and SLOT_INPUT are int constants I use to identify the campfire's slots, and inventory is my tile entity's IItemHandler instance. I created the method to work with both fuel and input (anything that can be smelted). I call it from the block's onBlockActivated method anytime the campfire is already burning and the player's held item isn't null. However, for some reason the first item I place into the inventory that can be smelted doesn't start cooking automatically; I have to open the GUI and remove and replace them in the input slot. It works fine from them on. I'll have to dig in and figure out why.

I am trying to create a campfire block, and I had this idea that if a player is holding a log in their hand, it would be cool if they could just right click on the campfire block and add that log to the fuel slot in the campfire without opening the GUI (I like the idea of players interacting directly with things, without a GUI as intermediary, when possible). I can get the log into the fuel slot, but I'm not sure I'm doing it in a good way. I had to make the tile entity's ItemStackHandler public in order to access it from the block's onBlockActivated code, and I'm not sure that's a good idea. It does give me access to methods like setStackInSlot to put the log into the fuel slot. However, doing that leaves behind an itemstack in the player's hot bar with a size of 0. I'm not sure how to avoid that. Any advice you have would be appreciated.

The next page button and the "2" button do not work for me. As soon as I click them, all the replies disappear. The only way I can view replies past the second page is with the "latest unviewed reply" button, if the next reply happens to be on page 2.

Woo-hoo! That worked. Many thanks.

Ninja'd. How do I do that? Do I cast my world parameter to WorldServer? (On the server side, naturally - !world.isRemote)

I have read tutorials and other posts on this forum stating that you can initiate a particle on the server, using world#spawnParticle, and the server will automatically send out the required packets. For example: http://jabelarminecraft.blogspot.com/p/minecraft-forge-1721710-modding-tips.html I have done a few packets before, but it bugs me to go to that effort when a single line method call should work. I already tried sending a packet to spawn the particle directly on the client, and it didn't work. It will play the sound correctly, and the println statements appear, but it won't spawn the particle. Here's the packet:

How . . . logical. I'm not sure if those corner cases would ever apply to me, but just to be safe I changed it: @Override public boolean shouldRefresh(World world, BlockPos pos, IBlockState oldState, IBlockState newState) { return !(oldState.getBlock() instanceof <myblock> && newState.getBlock() instanceof <myblock>); }

That's a good idea, but in this case the block is basically transparent. When I put that exact same call in the block's randomDisplayTick method, I can see the particles just fine.