ILuvYouCompanionCube

This doesn't make sense, does it? (from the code in EntityLivingBase) protected float applyPotionDamageCalculations(DamageSource par1DamageSource, float par2) { if (this instanceof EntityZombie) { par2 = par2; } [...] } Is there something wrong with my source code?

if your block extends BlockRedstoneLogic check isGettingInput. Its protected. If it doesn't extend BlockRedstoneLogic but at least extends BlockDirectional, copy those methods to you from BlockRedstoneLogic: isGettingInput and getInputStrength. If your block doesn't extend either of those classes, you can still implement those, with a little more work edit: oh sorry... you want to know if your block emits a signal? just return something from isProvidingStrongPower and isProvidingWeakPower. Both those methods are defined in Block

I did understand you wrong. If you know how to do it, I have no idea why you made this question then...

I said it once and I'll say it again. You, my friend, are very smart. Loved the interface idea.

First of all, you need to create a coremod. One of the pages people linked probably already show you how to do that. Then you'll have to have a class that implements IClassTransformer. The only method this interface defines is transform: public class Transformer implements IClassTransformer { @Override //Imagine we wanted to add the field to the EntityPlayer class public byte[] transform(String className, String dontKnowWhatThisIs, byte[] bytecodeForClass) { //note that this will only work in a non obfuscated environment (i.e. running minecraft from eclipse). To make it work within an //obfuscated envirionment, you'll have to find out the obfuscated name for the class you want to add your field to. If you don't know //how to do that, I can elaborate the answer to show you how. if(className.equals("net.minecraft.entity.player.EntityPlayer")) { return patchEntityPlayer(bytecodeForClass); } //note that we return the bytecodes for every class other than the one(s) we need to alter unchanged return bytecodeForClass; } private byte[] patchEntityPlayer(byte[] bytecode, boolean isObfuscated) { //A ClassNode represents a class in a tree-like structure ClassNode classNode = new ClassNode(); //A ClassReader is able to read the java bytecode. It kinda foward events to the ClassVisitor it receaves through it's accept method. ClassReader classReader = new ClassReader(bytecode); //the method accept of the ClassReader let's a ClassVisitor in (ClassNode is a subclass of the abstract class ClassVisitor) //he ClassReader will now read the bytecode on behalf of the ClassVisitor (ClassNode) and call a lot of visit*something* method for it classReader.accept(classNode, 0); //to create a field we instantiate a FieldNode. The first argument is mandatory, the second is the access flag to the field, the third is //the name of the field, the fourth is the descriptor of the field (basically, you need to call Type.getDescriptor and pass the class of //the field as argument. In this case, we're creating a field of type String. The fifth argument is the signature of the field. Since I don't //know what's a signature in the context of a field, and since there's no problem in letting it be null, I set it as null. //The last argument is the initial value of the field. Since this value isn't inherited (I don't know why), we can't set it, //because EntityPlayer is, in game, EntityPlayerSP or EntityPlayerMP FieldNode newField = new FieldNode(Opcodes.ASM4, Opcodes.ACC_PUBLIC, "TheNewField", Type.getDescriptor(String.class), null, null); //ClassNode has a List<FieldNode> that you can access through it's "fields" field. I add my new field to it. classNode.fields.add(newField); //the ClassWriter will actually write the new bytecode. Think of this as a chain. from ClassReader to ClassNode to ClassWriter ClassWriter writer = new ClassWriter(0); classNode.accept(writer); //here we actually return the new bytecode for EntityPlayer, containing the new Field. return writer.toByteArray(); } I made a very basic item to test this Transformer: public class TestItem extends Item { public TestItem(int par1) { super(par1); setMaxDamage(100); } @Override public ItemStack onItemRightClick(ItemStack par1ItemStack, World world, EntityPlayer player) { par1ItemStack.setItemDamage(par1ItemStack.getItemDamage() + 1); Field theField; try { theField = player.getClass().getField("TheNewField"); String theFieldValue = (String)theField.get(player); player.addChatMessage("TheNewField had the value of " + theFieldValue); player.addChatMessage("Altering the TheNewField value to \"MAAATHEMATICAL!!\""); theField.set(player, "MAAATHEMATICAL!!"); theFieldValue = (String)theField.get(player); player.addChatMessage("TheNewField now has the value had the value of " + theFieldValue); } catch (Exception e) { // TODO Auto-generated catch block e.printStackTrace(); } return par1ItemStack; } } Of course, using reflection everytime you'd need to access the item may not be a good idea. To minimize this problem we could at least make a field of type Field in our item class, and we'd avoid the call to Class.getField everytime, by making it just once and storing the return in our field of type Field. All sets and gets would still need reflection though (probably).

I'm definetly downloading pneumatic craft

That's really cool!!! Maybe our chat in this thread will give you some other ideas... I'm thinking of a mushroom that contaminates nearby cows turning them into mooshrooms. Or a plant that infects the player and gives him/her abilities and/or a disease. And you could spread it around while you moved through the world, or maybe infect other players. And why stop on cows and mooshrooms... every mob could have an infested version by a host plant. Most of what I said is probably impossible or not worth the effort of implementing... I'm just letting my imagination go wild here. I'm so into this plant stuff right now for some reason.

I never tried that... And you shouldn't. But if you don't mind risking conflict with other mods and random crashes... I think that if you don't change the NAME of the vanilla class and run recompile.bat and then reobfuscate.bat (not reobfuscate_srg.bat) you should output your class with the correctly obfuscated name, the same obfuscated name as the untampered vanilla class I'd guess. I don't know where to put it though. I don't really know where minecraft class files are located in this 1.6.2 version.

Maybe something with the new version. I haven't used EnumToolMaterial since 1.5.2. Let's wait for the pros' opinion on this one. It could be a bug on forge or you could be doing something that's deprecated and no longer supported.

You can't change the behaviour of a vanilla block without changing it's class file. The only relatively safe way to do that is using ASM APIs for transforming java bytecode, so you register for a certain event and your callback receives the bytecode (as a byte[]) and the name for every class minecraft launcher loads. So you decide which ones you need to transform. That's kinda advanced stuff, and since you're new to modding I'd suggest you don't try that right now. Register that block you made and use it instead of the normal farmland. Maybe there's a world event you can subscribe to prevent vanilla farmland blocks from being placed (everytime one is placed you set it to dirt, or something). But I don't know if there's such a thing. edit: only mentioned that as a possible inspiration for more experienced modders to try and answer your question.

That's really weird ... Efficiency is the 4th argument (3rd number, the one you posted as 8.0F). You sure that's the one you're changing?

I see. This way I get no negative numbers. You guys are smart! Thanks.

They should all change, but that's the efficiency when using the tool to harvest the block it's made to harvest. Try making a shovel and compare the speed you harvest dirt with your tool material with the speed of a wooden shovel.

I don't know how those fields work. Apparently they can be both negative and positive. What those fields really mean? Are they like the speed of the entity?

If you can, don't make it just for farming. Make it as general as possible, like something that generates spores (or whatever you call it) that floats randomly, that when in contact with something (specific or not) produce something (maybe something different depending on the surface it lands).

someone make this polen thing please! imagine the possibilities. Make it something other modders could subclass. It would be a whole new world of possibilities. Specially if it was like a plugable behaviour... I'm imagining a mob releasing spores that would spawn horrible mushrooms that would release more spores and all those mushrooms would become mobs at night. And there's so much more that could come from that idea.

I think the polen thing is a little out of my league haha. It would be super cool though. I'm just not experienced enough to try that. About subclassing EntityItem, that was my first idea. I asked because I thought maybe there would be something ready for cases like that. Since there are things like EntityEvents and all that (things I don't understand yet). I have other ideas, but now that you mentioned that, I'll go for subclassing EntityItem.

I'm trying to figure out a way to use a dispenser as a auto-planting machine (if there's already a vanilla way to build an auto planting machine please let me know). I got a few ideas in mind. But to make it really cool, I need a way to use the EntityItem dropped by the dispenser. I need to know when the EntityItem stops. Does it have an event I can subscribe to or something? Or a callback I can register to execute somewhere between updates... So, basically, I want to run code when the EntityItem dropped by a dispenser is stopped.

basically what you need to do is make up a name for that field and put it just after the type public static ItemAmethystPickaxe [b]amethystPickaxe[/b] = ... //the rest here stays the same the word in bold is an identifier. Everything in your code needs one, otherwise how else would you refer to that piece of code again if it doesn't have a name. But suggest you to drop modding for just a few days and read as much as you can about java. Then when you grab the basics, start modding again. It will be a lot less confusing.

You don't have an identifier for that field your code: public static ItemAmethystPickaxe = ... ItemAmethystPickaxe is the type, I can tell that by the constructor you're invoking. You need a name for the field too. Like maybe amethystPickaxe, or whatever you want. edit: that's extremely basic Java by the way. Either it was a typo and you forgot about the identifier (it happens) or you should take a break from modding and grab an introductory book about the Java programming language

I'm not 100% sure of this, but I think those names on that srg file are for types, fields and methods only. I don't think there are parameters or local variables in there. I'm just guessing (it would be extremely painful to actually search for any local identifier in that huge file) but I think it makes sense. Anyway, unless theres a way of avoiding what OwnAgePau said, I think I'll leave local identifiers as they are. At least now I know comments are safe.

Oh... And is that avoidable? I noticed some bat files like updateids, updatenames, updatemd5. Would any of those fix that thing you said?

Can I make the code for the minecraft classes clearer to me by adding comments, renaming parameters and local variables (but never renaming types, fields or methods)? Will that break something? like recompilation e reobfuscation or something else?

I think something would go wrong only if another mod tryed to modify lines he already modified in his substitute of the class file, right? And wouldn't that same something go wrong as if he had modified those same lines via ClassVisitors and all that? I think that if he keeps the class as similar to the original as possible, there's as much harm in doing his way as in doing the ClassVisitor way. And even using the ClassVisitor way you could rewrite the whole class file and change it completely if you wanted.

I think the way he did it is an option. When you need to change a lot of stuff, you can provide a substitute class file for the class that you need to be changed. But of course, it must have all the fields and methods of the old class, with the same descriptors. and nothing can be made less accessible than before. And the return values of methods and the values of the fields must always be coherent with the original class'. Other than that, I think he can do that, as long as he doesn't actually overwrite the original class file in it's disk location... and same fully qualified name for the class, and same annotations for methods and fields (in this last case, just to be safe... It's a large code, and some changed annotation may break something somewhere)