Posted March 8, 201312 yr What I'm suggesting is a quick and painless change, which is changing Block.getCollisionBoundingBoxFromPool(World w, int x, int y, int z) to Block.getCollisionBoundingBoxFromPool(World w, int x, int y, int z, Entity e) where the Entity is the one whose collision is being tested at the moment. It should be ignored by minecraft / forge code, but it's useful when you need to override some block collisions in specific ways. While you can use 'addCollidingBlockToList()' to override collision behavior, as long as your AABB is not null, non-living entities such as EntityItem and EntityArrow will still collide with the block, even if you have overriden 'addCollidingBlockToList()' to allow those entities to go through the block. On the other hand, if your returned AABB is null, addCollidingBlockToList doesn't seem to get called at all, so you can't just sneak your real AABB into the list anyways. Did I help? Hitting 'Thank You' would be appreciated. Soon, the lost city will rise from the bottom of the ocean, and spread it's technology across Minecraft.
March 8, 201312 yr that's actually really useful. that would be really useful for making walls that only certain people can go through/people with certain items or armor can go through.
March 8, 201312 yr Author That's sort of what my mod does I have a shield block that allows entities through based on metadata, and it works wonders with living entities... non-living entities, on the other hand, always get stuck. Did I help? Hitting 'Thank You' would be appreciated. Soon, the lost city will rise from the bottom of the ocean, and spread it's technology across Minecraft.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.