coolAlias

Crash Log This is the old code involved in this particular crash. So of course it's obvious I can check for instanceof EntityPlayerMP before sending the packets, case closed, but the bit I don't understand is I have always worked under the impression that checking if world is not remote implies that EntityPlayer IS an instance of EntityPlayerMP, and that assumption has never before been challenged. Interesting point number two, this crash evidently only happens when Treecapitator is loading alongside, and judging by the various 'com.mumfrey.liteloader' lines in the crashlog, it seems reasonable to me that perhaps mumfrey's liteloader is partly or wholly responsible - either that, or I have completely misunderstood a lot more than I imagined (always a possibility ). My question, then, is how could I possibly have an instance of EntityClientPlayerMP when the world is not remote?

I don't see anywhere in there where you tried to implement what I suggested, storing the cooldown in the ItemStack's NBT tag. The way you have it now, every single player with your item is using the same cooldown field (which doesn't even cool down, since you didn't implement onUpdate). Item#onCreated only gets called if the item is crafted, btw, so your NBT tag will not be initialized if you get one from the Creative tab, by command, as loot, or any other such means.

That removes the error for that bit, but still the line next to that wont work. It doesnt have getItem() or itemID And we're supposed to magically know what the next line is? As for the article being outdated, sure, slightly, but any required code changes would be readily apparent with just a bit of Java knowledge and poking around a little in vanilla code. Anyway, show your code or we cannot help.

Don't make a field in your Item class - every single one of your weapons will then be on the same timer, so if I right-click, my friend's timer will start, too. This is because Items are each a static object, i.e. there is only ONE of each Item in the game. Instead, you need to store the timer in the ItemStack's NBT compound. See the Forge Wiki article.

I never got around to updating the actual tutorial code due to the crappy editor on MinecraftForums, but I have commented on it several times and linked to updated tutorials, as well as showing full implementations on Github that use the SimpleNetworkWrapper. It's not that difficult to update if you were using the old Packet Pipeline code.

Perhaps this tutorial will help you.

LivingUpdateEvent - check for the player, then cancel the event: the player entity will then not process entity updates, so can't move, be attacked, etc. You'll have to test if it works for your specific case, as canceling this event has a very wide-reaching impact.

Then how about you do a little experiment: // don't initialize it right away and make it static so you can access it in the next method public static Item[] itemList; public static void initItemList() { itemList = new Item[]{WinterItems.crystalSword,WinterItems.refIcePickaxe,WinterItems.candyCaneAxe,WinterItems.commonItem}; } Then call the initItemList method from your main mod class during FMLPostInitializationEvent. See if that doesn't work for you; if it does, then you know that your items weren't initialized when you created the array in your previous code.

First, please don't P.M. me about problems - the forums exist for everyone to learn. Second, learn Java - you would know what to do with most of the errors you mentioned if you just took some time to study. I mean come on, you copied the Battelgear2 code exactly into your project and it's complaining because it can't find other class and object references - what did you expect to happen? Third, my apologies - I forgot to mention that Battlegear2 uses byte-code manipulation to make certain fields in EntityArrow public, but even this would not be a problem for you if you understood Java better. I know this may sound harsh to you, but it really does boil down to the very simple fact that you aren't going to get very far until you become comfortable with Java.

EntityArrow does not have an onImpact(MovingObjectPosition) method at all - that's why you get an error 'overriding' it. It can be quite tricky to extend EntityArrow and get any real functionality out of it, but it is possible. My solution was to take advantage of the fact that 'onEntityUpdate()' does not do anything in EntityArrow, thus allowing me to override onUpdate() with my own code and still get the standard Entity class update functionality, and then rewrite the entire class around that so that I could manipulate any part of it that I wanted. Battlegear2's solution is much simpler, but not quite as flexible: use Forge events to trigger methods within your arrow class. Both approaches have advantages and disadvantages; it all depends on what you need to accomplish. For yours, BG2's approach is probably easiest - check when an entity is hit with your arrow, then spawn an exploding entity at that position with a timer of 3 ticks (or however many you need). Reason for the extra entity is EntityArrow is set to dead when it strikes an entity, so you will no longer have the benefit of its update tick (in this particular solution), unless you only want it to explode when hitting the ground.

That's what he already asked you to do... no one can help you if you don't show your code.

Your last line is wrong - it should be 'properties.setTag(EXT_PROP_NAME, compound);' rather than 'compound.setTag(EXT_PROP_NAME, compound);' Personally, I think you may have confused yourself by naming your parameter 'properties' here: public void saveNBTData(NBTTagCompound properties) { That tag compound is NOT your properties, it is the tag compound given to you to which you are going to add the new tag storing your properties. I would have swapped the names 'properties' and 'compound' - semantics, but names are powerful.

Did you register your projectile using EntityRegistry#registerModEntity ? Are you spawning the entity on the server? Your Entity should have a constructor with a single World argument as well: public YourEntity(World world { super(world); }

Depending on how drastic the differences are, you could put the different parts in a single model class and render the appropriate part according to the entity's state (which you would need to sync to client with DataWatcher or other means). What I mean is basically this: public class YourModel extends ModelBase { private ModelRenderer arm1; private ModelRenderer arm2; private ModelRenderer everythingElse; @Override public void render(Entity entity, float f, float f1, float f2, float f3, float f4, float f5) { super.render(entity, f, f1, f2, f3, f4, f5); setRotationAngles(f, f1, f2, f3, f4, f5, entity); everythingElse.render(f5); if (((YourEntity) entity).useArm1()) { arm1.render(f5); } else { arm2.render(f5); } } Obviously you could make the code look nicer by using an array for all the possible arms and returning the index of the arm to use from your entity's function, but this is the basic gist of it.

Where are you calling your render code from, and can we see the rest of that class?

Always on point - can't slip anything past this guy

Awesome - gotta love it when that happens That is what Iterators were designed for, though - you can safely remove an element via an Iterator without affecting the remaining iterations.

If you're replacing the recipe to return your custom Item (which isn't a terrible solution, at least any more than changing the vanilla class is), why can't you just override whatever methods you need in your custom class? You shouldn't need ASM or Reflection at all unless you are trying to change the vanilla class. Btw, Forge (FML, actually) does have a ReflectionHelper class, but you still need to know what you're doing to use it.

if (!world.isRemote) { // do your thing here }

Use the player's look vector and either one of World's raytracing methods or iterate manually over the vector until you hit something. I'm sure there are plenty of solutions on this forum if you search.

You should only be making a new ItemThrowableEgg ONCE, and then referencing that instance everywhere else (assuming you only have one ItemThrowableEgg - if you have more, make multiple instances). That's why in every item-making tutorial, you always see stuff like this: public static Item throwableEgg; // preInit throwableEgg = new ItemThrowableEgg(); GameRegistry.registerItem(throwableEgg, 'throwableEgg', modid); ItemStack egg = new ItemStack(YourMod.throwableEgg); throwableEgg is the reference that you can use everywhere, because the item only exists as a single object - if you made a new Item for every single item in the game, that would waste a lot of memory.

Put the same method in your class, and tell it to return something else: @Override public boolean isItemTool(ItemStack stack) { return true; } @Override is helpful in that it informs you if you have the correct method (i.e. the method that you think exists in the parent class (Item) actually exists), but is not necessary for functionality. Use it anyway, though, to save yourself a lot of headaches.

It's because you are using client-side logic (Minecraft.getMinecraft(), mouseover, etc.) to place the entity, so you are only placing it on the client side; during the next tick, the server tells the entity "hey, that's not where you are" and moves the entity back. You need to set the position on the server, i.e. when world.isRemote returns false, and figure out how to determine a MovingObjectPosition without objectmouseover. Or you could handle the logic client side and send a packet, but that is more work.

What exactly are you trying to do?

Did you not see "player.posY + player.getEyeHeight()" in my code snippet? There's a reason for adding the player's eye height, and that is that on the server, player.posY is the player's feet. As for your NPE, it is clearly possible for no block to be hit by the ray trace (looking up into the sky or looking at an entity), so you need to check for that.