citizenslave

It's happening on the third click after the tasks targeting players and villagers have both been removed. At that point, you only have one item left in the targetTasks list, and it's at index 0. If you change your conditional to: if (zombie.targetTasks.taskEntries.size() > 1){ Then it won't try to remove the task at index 1 when it doesn't exist.

That will still allow a "tamed" zombie to attack villagers after the first right-click. After the second right-click, they won't attack villagers either. Cast the task.action and check the targetClass property against EntityPlayer.class to change this. Sorry for the screwups, still a newb to this and this was actually my first dive into the AI.

Third time's the charm. I actually tested it this time.

Yeah, I missed that they weren't static...makes it a lot harder for me to test them now too...you'll have to get your item's right click target entity, check if it's a zombie, then run the code from my edit on the casted entity. public boolean itemInteractionForEntity(ItemStack itemStack,EntityPlayer player,EntityLivingBase target) { if (target.worldObj.isRemote) return false; if (target instanceof EntityZombie && ((EntityZombie) target).targetTasks.taskEntries.get(1) instanceof EntityAINearestAttackableTarget) { ((EntityZombie) target).targetTasks.removeTask((EntityAINearestAttackableTarget)((EntityZombie) target).targetTasks.taskEntries.get(1)); } return false; }

zombie.targetTasks.removeTask(zombie.targetTasks.taskEntries.get(1)); Let me know if it works, I didn't test it. You'll have an issue if it is supposed to be a "toggle" as the EntityZombie constructor code puts it into the array second, and if you add it back with zombie.targetTasks.addTask(2, new EntityAINearestAttackableTarget(zombie, EntityPlayer.class, 0, true)); it will be third. Adapt accordingly.

I'm pretty sure this is an issue with a custom block. Check your error: java.lang.ArrayIndexOutOfBoundsException: 2403 at josiah.FirstMod.EntityForestWalker.func_70636_d(EntityForestWalker.java:163) That 2403 is the block ID of the block your Forest Walker is trying to pick up, and it's outside the bounds of your 257 bit boolean array. I don't know if the blocks are yours or from some other mod you have loaded, but your class needs to adapt to it. Forge updates the EntityEnderman array to 4096, which I seem to remember seeing as an upper bound in a tutorial. Unless the parameter is stored somewhere as a 12 bit value instead of 32, the only reason for that constraint is the expanded size of EntityEnderman.carriableBlocks, so perhaps that is some kind of standard that you can rely upon for whatever other mods you may have and an array size of 4096 may be a better solution (WAY simpler too!) without more control over custom block IDs. That is certainly an option that would help to simplify the code, but at the expense of its flexibility. I did suggest when I posted it that an entity guaranteed to have a carriableBlocks field would allow that and extending a class that has such a field (like EntityEnderman) would be one way of making that guarantee. Just a design decision on my part to reflect instead, your mileage may vary.

This is what I came up with. Watching the logs, you can see that something (Forge?) updates the EntityEnderman::carriableBlocks field to a boolean[4096], but that happens at runtime somewhere and doesn't account for any custom entities that may be copying the original EntityEnderman.java file from Forge. This code COULD be shorter if your blocks subclassed a subclass of Block that ALWAYS had an isCarriable boolean field and you only used the EnderSafe class to register a subclass of Entity GUARANTEED to have a boolean[] carriableBlocks field, but I wanted the methods to serve as replacements for GameRegistry.registerBlock(Block block,String name), EntityRegistry.registerGlobalEntityID(Class<? extends Entity> entity,String name,int id), and EntityList.entityEggs.put(Object id,Object eggInfo) without imposing tighter coupling against the parameters. I'm not sure how much I LIKE this as a solution, but I didn't find anything else internal to Forge or Minecraft, so I hope it helps anyone else who is having this problem, even if it's only helping them to find a better solution. Frankly, since Forge handles the array for EntityEnderman, you COULD just write all of your Entities to have a carriableBlocks array big enough to start with, but that's just TOO simple, right? public static boolean[] carriableBlocks = new boolean[A_REALLY_BIG_NUMBER]; Good luck.

I'm getting the same error myself while working through a tutorial where I'm essentially just copying the EntityEnderman class. The issue is with the EntityEnderman::carriableBlocks array, which stores an array of boolean true/false values determining whether or not the block with the id of the array's index can be picked up by an Enderman. Here's the rub: it's initialized to a [256] size array, which is sufficient for vanilla Minecraft's block IDs, but not for all of the custom block IDs we introduce and then spam around our chunks. Our Enderman or custom mobs sufficiently similar to them try to pick up one of our custom blocks, the index at the block ID is out of the [256] bounds of the EntityEnderman::carriableBlock array, and you're done. I'm about to write a wrapper function for GameRegistry::registerBlock() that tries to resize a carriableBlock property on every entity to at least the associated block ID, but I don't want to start hacking EntityEnderman even at runtime if I can avoid it. Anyone have a better solution for me? One that's compliant with the MCF API would be nice...