sequituri

I was saying earlier that a separate class is not the way to go. However, as CoolAlias was so kind as to point out, if you can refactor most of the guts and hard stuff into a common base class, then your weapons and such could just be declared as subclasses and gain all of the functionality that you don't override. This is good old everyday java programming, so I hesitated to mention it. Check out how ItemTool works for Axes, pickaxes, Shovels, etc.

Objects are passed by value (of object reference) in java (unless the argument an expression). It looks like the single reference is getting modified each time through the loop. But, that explanation doesn't make sense. So, ignore me. I probably would have tried something like this first. LanguageRegistry.addName(new ItemStack(redstoneClock, 1, ix), subNames[ix]+"stone Cloth"); If that didn't work, then I have to dig deeper. Sorry, I cannot be more helpful, not much to go by. [editted for benefit of future readers with similar problem]

That has nothing to do with the topic, he is trying to use a method in EntityLiving, not EntityLivingBase, so he needs to check if the entity in question is an instanceof EntityLiving before casting. Stop confusing people with random comments. I don't find your attitude helpful. Perhaps you could keep your snide comments out of the fora.

That would sure complicate the whole business, but you are right that you can do most anything with a class if you want to. It just isn't always the best way.

Your custom teleporter's constructor has to supply a base class constructor call. super(par1WorldServer);

Okay, so post your new code (where the typo was) and your log, so we can debug for you. Other than that, I cannot guess your issue or help in any other way. If you cannot be cooperative and at least try to work with people, people will start giving up on you.

Not at all. Why would any other mod register one of their axes in an "ore" dictionary? Answer: they won't. Use the instanceof ItemAxe or at least instanceof ItemTool (Here you would check the name for having 'axe' or 'hatchet' in it but not pickaxe) Any coder with any brains is likely not going to make an axe in some other class. The OreDictionary should be reserved for crafting. You should register crafting recipes in Init eventhandler not preinit.

EntityLiving and EntityPlayer are both subclasses of EntityLivingBase, but you cannot cast one to the other unless it is an X instanceof Y (you can cast both to EntityLivingBase, if that's what you need, though.) SO, put an 'if' in there to catch that and use logic.

You could look at something like EntityHorse class. It uses a method func_110226_cD() that sets up the chest and datawatcher for inventory access. It uses the class AnimalChest - something similar might be useful. Like maybe NpcChest with similar code of your own.

flansmod appears to be missing from the mod list, too. The block and item registry seems to be pretty huge for one packet, though.

[Okay, while I was typing this, deiseiben07 posted.] FurnaceRecipes.smelting().getSmeltingList().remove(new ItemStack(Blocks.iron_ore)) will not work. The reason is simple if you understand hashmaps. The key is looked up in an array of hash buckets indexed by the hashCode() return value. Then, if the key is not equals(Object o) to the one to remove/add/get the object looks down to list or hash bucket and checks equals() again (some do a rehash, but not this implementation). Now to the actual reason it fails. No two new ItemStacks will generate the same hash (under normal circumstances.) So, every ItemStack will not match an existing key, and since ItemStack does not implement either hashCode() or equals(o), the Object (superclass) methods are used (they amount to the address of the instance as hashCode). If you put an ItemStack in the map, it stays but will never match anything but that exact reference, ever. You therefore must iterate through the recipes, check with ItemStack.areItemStacksEqual(s1, s2) -- yes, really slow... but the only way right now.

Use your own FurnaceRecipes equivalent... copy and paste, if that's what you do best. Rename and modify to suit.

The server has no reason to inform other players what is in your hotbar slots. So, how are the "other" supposed to render your lantern when it's not visible to them?

Try BiomeGenBase$getBiomeGenArray() It returns the biomeList

what are all these methods called "load" supposed to be for, besides convoluting your code?

Tennox, dude! Are you blind, you've been told by me, and now shown your typing error. Don't blame stupidity or blindness on Minecraft or Forge! It's in the quote Gotolink posted.

Now see, you are changing you requirements. First, you asked if the player was visible - TGG told you how to find that. Now, you want to know if the entity is actually looking at the player - another thing entirely.

Then I cannot help you. When I followed the instructions LexManos provided, it just worked and all the code was there. I'd suggest scrapping it, redownloading Forge, and following the instructions for setting up the project. Beyond that, I got nada.

Yeah well, the SimpleChannelHandlerWrapper(Class handler, Side side) is bugged, as it never calls super(Class inboundMessageType... ) to get the matcher to cache the class and message type. The default constructor for the superclass relies on the parameter matcher to find it in the cache (which it won't because it was never used before) and fails when it is not there. This should be addressed in bugs & software support.

True that. But, my understanding was that the OP was talking about making a mod that didn't necessarily depend on Forge. I guess that was a misunderstanding. Yes, I would have suggested the helper if I had understood correctly. Sorry for piping in.

I'd say this, if he's not flying (isFlying?) or falling (changing Y values in a negative direction) then he is probably on ground. I could be wrong.

Minecraft.getMinecraft().currentScreen

Then it looks like you are using some old 1.6.x code and expecting it to work. It won't work on 1.7.x if you don't get rid of Block and Item IDs that have no further purpose. Blocks and Items are registered as their instances now. The ID is auto-assigned and calling a constructor like Block(ID,...) should not even compile. And you'll need to go through all of that 1.6.x code looking for any reference to a Block or Item id (and things like Block.stone etc.) and change them to the 1.7.x way.

All of that information is nicely presented in your development environment (eclipse) just be using the tools it gives you (like in the dependent libraries section undere forgeSrc). Expand the jar and find all the classes and interfaces it contains.

Fixed that for you. ;-)