coolAlias

It's crashing because your Items / Blocks are static, and you are initializing them statically (i.e. outside of a method), so they try to initialize before your config file loads. Put them inside of a method like so: public static Block glassTable; // changed 'G' to lowercase to match Java naming conventions @EventHandler public void preInit(FMLPreInitializationEvent event) { // all your config stuff first // now all your blocks and items: glassTable = new TileEntityGlassTableBlock(GlassTableBlockID).setUnlocalizedName("GlassTable"); }

Did you see my note? If you are working in 1.7.2, "destroyBlock" is called "func_147480_a". The final boolean parameter determines whether the block will drop items, so if you pass true, you can destroy the blocks and get the drops, or false to just destroy the blocks. Using the destroyBlock (a.k.a func_147480_a in 1.7.2) will also automatically give you a sound and particle effects.

1. Learn Java, if you don't know it already 2. Do what Busti said. 3. Once you have the block coordinates, use World#destroyBlock(x, y, z, true/false) to destroy the block. It is called "func_147480_a" in 1.7.2, if that's the version you are using. 4. If you want to destroy more than one block, destroy the blocks +/- 1 each from x and z to get your 3x3 pattern, as in (x + 1, y, z), (x + 1, y, z + 1), (x - 1, y, z - 1) <-- that's one row, you need three

I have this exact same problem and still have not found a perfect solution. I was able to ameliorate it somewhat, however, by doing my generation on the final PopulateChunkEvents that post every time: GLOWSTONE for the Nether, and ICE for the overworld. LAKE actually is posted last, but it's not posted for every chunk. If you want, you can see what I did here. It's far from perfect, and in fact some of my secret rooms do still get chopped up by chunk borders; if your structure is less than 16x16 in area, as a last resort you can make sure it only ever generates in the center of a chunk; again, not ideal, but it should work. Let me know if you ever come up with a better solution! This problem has been haunting me for months >.<

Excellent point. OP, for further reading on int[] as a key and what you can do: http://stackoverflow.com/questions/2627889/java-hashmap-with-int-array

I'm not sure how your data got to be 724188 bits if you only have 50 entries of 3 integers, so it could very well be something else going on. At any rate, a normal packet should not have this restriction, if it is indeed some special restriction enforced on TileEntity description packets. Another option is to find a more compact way of storing your data, rather than three keys per entry, you can do it in one using NBTTagCompound.setIntArray(String, int[]): while (it.hasNext()) { Entry<int[], Integer> entry = (Entry<int[], Integer>) it.next(); nbt.setIntArray("counter" + i, new int[] {((int[]) entry.getKey())[0], ((int[]) entry.getKey())[1], ((Integer) entry.getValue()).intValue()}); i++; } I'm sure there's a better way to write it without all those casts, but you get the idea.

Hm. Don't see anything odd there... but looking back at your error log there does indeed seem to be a limit: io.netty.handler.codec.DecoderException: java.io.IOException: The received encoded string buffer length is longer than maximum allowed (724188 > 256) I'm not sure if that existed in 1.6.4 or not, but it looks like you are going to have to handle your TileEntity using a custom packet, and possibly even split the data up into several packets. I would just avoid the description packet altogether for this one, given the apparently tiny size it is allotted.

Well there is if the OP actually wants to check for actual radius (i.e. a sphere) rather than a box. If you don't check distance you'd be checking in a big cube, but the way he worded the original question made it sound like he wanted a big sphere. Of course if it doesn't matter much then yes a big cube is easier. Ah, if that is indeed what the OP meant, then you'd be right After playing with Minecraft code long enough, I've started to associate "radius" with cubes @OP If that's the case, you should follow TGG's advice and compare distance squared against the squared radius, rather than using square roots; if that's not the case, then the check is wholly unnecessary.

Post your read and write NBT methods from your TileEntity.

Did you happen to override the getSpriteNumber method in any of your Item classes? /** * Returns 0 for /terrain.png (i.e. Blocks), 1 for /gui/items.png */ @SideOnly(Side.CLIENT) public int getSpriteNumber() { return 1; }

In your custom ItemBlock class, remove everything to do with icons, such as the "registerIcons" method. For reference, this is what one of my custom ItemBlock classes looks like: public class ItemSecretStone extends ItemBlockWithMetadata { public ItemSecretStone(Block block) { super(block, block); } @Override public String getItemStackDisplayName(ItemStack stack) { return StatCollector.translateToLocal(getUnlocalizedName() + (stack.getItemDamage() > 7 ? ".name.unbreakable" : ".name")); } } The only reason I even needed a custom class was to get the display name to work as I wanted (that and the vanilla ItemBlockWithMetadata no longer works when registering blocks, but that's another issue), otherwise I would just use the vanilla ItemBlock class.

ItemBlocks use the Block texture sheet and will render as your block renders; you should not register icons to your custom ItemBlock, as that will attempt to access the Item sprite sheet and crash.

The ItemStack's stackTagCompound may be null, so if you are using an unenchanted item, that line will crash. Simply null check.

Just to point out, EntityLivingBase#rayTrace and EntityLivingBase#getPosition are both CLIENT only methods - you will crash if you run your code in multiplayer. See this post for more information on getting the coordinates the player is looking at.

You can use the initial x/y/z coordinates as the starting and ending points of the for loops and there is no need to check the distance. Performing a sqrt operation every iteration increases the performance cost significantly.

Making this way more complicated than it is - there is no reason to copy the entire getLookVec method... just look at EntityLivingBase#canEntityBeSeen for inspiration on how to do it in a simple fashion: public boolean canEntityBeSeen(Entity par1Entity) { return this.worldObj.clip( this.worldObj.getWorldVec3Pool().getVecFromPool(this.posX, this.posY + (double)this.getEyeHeight(), this.posZ), this.worldObj.getWorldVec3Pool().getVecFromPool(par1Entity.posX, par1Entity.posY + (double)par1Entity.getEyeHeight(), par1Entity.posZ)) == null; } There you can see how one could easily modify this to return what you want; World#clip(Vec3, Vec3) returns a MovingObjectPosition if something was in the line of sight, either an entity or block, or null if the player is looking at air. The first Vec3 is based on the player's current position, the second the position you want to teleport to. For that you can use the vector from the player's position (yes, the same one as the first) and add the normalized EntityPlayer#getLookVec() coordinates multiplied by whatever distance you want. In sum, you have 2 Vec3, both based on player position and one modified by the look vector, and you throw those into World#clip. Done in 3-4 lines of code, using tools already available in Minecraft.

I meant using the metadata as a counter - there aren't enough bits in there to store a full block ID (only 4 bits of metadata storage per block). If you plan on having that many respawning blocks, you're probably going to have a huge performance hit irregardless of whether you use ticking blocks or tile entities, though slower tick rates should help ameliorate this somewhat. Instead of making a new fake block for every single one of your blocks, I was more suggesting that you take your original block and only allowing it to be harvested say when metadata is zero; upon harvesting, instead of breaking, you pop out whatever drop you want and keep the block there, but set its metadata to 15. When the update tick runs, decrement the metadata at those coordinates by one. Of course you will have two different icons, one for its harvestable state, and one for its dormant state. Again, this all depends on your blocks - if you are using the metadata for other things, it may not be available for you to use as a make-shift timer, but if you have at least one bitflag to determine the harvestable state, you can simply use a Random to determine if the flag gets reset during the update tick, which will effectively do the same thing if you make the chance low enough.

If you don't require your ores to regenerate at an absolutely perfect rate, you can forgo tile entities altogether by setting your block to tick randomly, return some value from tickRate(World), and handling what you need in the block's updateTick method. While this saves some on memory, it limits you to using the block's metadata as a counter, which may or may not be feasible/sufficient for your needs. Just to toss out another option

Exactly. NEVER use Minecraft.getMinecraft() for anything unless you are absolutely sure it will only ever run on the client. If you ran your original code on a server, it would crash as soon as your tiger tried to attack.

I beg to differ. Look vectors are exactly what is needed here. objectMouseOver is useful, but can only be used on the client, so if you want to be able to teleport on the server without sending a packet, the look vector is perfect. I've used it lots of times. @OP accessing Minecraft.getMinecraft().anything will crash your game if you try to access it on the server side (i.e. when the world is NOT remote), since getMinecraft() is all client-side only. If you want to use objectMouseOver, you will need to do so only on the client and send a packet containing the coordinates you need, then resolve the teleport from the server side; otherwise, you can try using the look vector.

Hi there, getLookVec() returns a normalized look vector, so all the coordinates (xCoord etc) squared and added together will equal one. It is not a real world position, but relative to your current position, so you need to add these values to your initial position (e.g. player.posX += vec.xCoord * 50D, etc.). Like mentioned earlier, you can multiply each vector coordinate by some value that will extend the distance, so if you multiply by 50 you will be teleporting 50 blocks along the player's look vector, but that might be inside of a block. You can either manually iterate along the vector path until you hit a block, or you can use the World#clip method with your multiplied look vector (plus the initial coordinates), and the player's initial position as a vector. This will return a moving object position which may be null or may contain the information on the block hit.

Probably the biggest part of your problem is you've copied all of the arrow code into an EntityThrowable; you now have class variables such as "inGround", to name only one, that are duplicates of those in EntityThrowable. While this isn't a problem in itself, you are calling super.onUpdate(), meaning that the EntityThrowable is calculating trajectory, whether it's in the ground, collided with entities, etc, and then you do so again using your own variables. Not only is this wasteful to run the same calculations twice, I'm sure you can see how it could cause all sorts of problems, as your arrow is essentially updating twice each tick. Yet for some reason you don't call super on the read and write from NBT methods, when you most certainly should. Anyway, to say the least, I think a major recode is in order.

@sequituri: Certainly didn't expect the code to be so inflexible... I wonder how Mo' Creatures does it? @OP: You can use the vanilla creature types just fine for custom entities provided your entity matches the type (i.e. Mob, Animal / Creature, Ambient, WaterCreature). Note that you will be competing with all mobs that use the same creature types, so for testing you should definitely set your spawn rate to 1000+ just so you can see them spawn. I haven't done much with entity spawning, but Ambient creatures are almost nonexistant in vanilla minecraft, so if you can code your entity to be an ambient creature type and still get the tameable functionality, you won't have much to compete against - but it's more work >.<

diesieben to the rescue! Sorry I didn't try that code out myself - just saw it was error free and assumed EnumHelper would do the rest. That's pretty odd that it doesn't pass the correct parameters automatically, as sequituri pointed out; an oversight, perhaps?

It crashes when you give your mob meat because you are using the EntityWolf's code exactly: this.dataWatcher.getWatchableObjectFloat(18) < 20.0F DataWatcher (18) is added during entityInit for EntityWolf, but you do not add it - wolves use it to track current health, though I'm not really sure why that's necessary. As for sitting, the animation isn't going to happen automatically; chances are the entity IS sitting when you tame it, but since their is no animation you can't tell and just think it's not following you. Try right clicking it again after you tame it and see if it doesn't follow you around, or put in a println statement in your interact method to tell you the sitting state.