Black

Let's see I understand you correctly. You set the direction of the pipe through metadata, which saves automatically, and changed the size of the pipe but didn't save that data and when you load the pipe again you expect the pipe size to magically still be there? The solution is extremely simple. Look into TileEntities. Since it is a pipe and you'll probably want it to tick at a regular pace that's the best thing anyway. Then utilize the nbt of the entity to save your pipe size.

Either implement your own ICraftingHandler, register it and check for each crafting recipe and each slot what the item is and if it is your item, set to that slot two of your item with + 1 damage. The other, better way, is to override the getContainerItemStack method in the Item.class. Both have tutorials somewhere floating around should you need them.

So many bumps. Well, a quick look through some classes revealed the following: Entity.class has the following method: protected void setSize(float parwidth, float parheight) and EntityPlayerMP has this method: /** * Returns the default eye height of the player * @return player default eye height */ @Override public float getDefaultEyeHeight() { return 1.62F; } setsize sets the boundingbox. So you can set the size and height of the player there the default eye height method sets, well, the default eye height and is used in the item class and in the EntityPlayer class. The EntityPlayer class also has a variable called Eyeheight. So while I didn't really look deeply into it I think those two functions are a decent start to set the eyeheight and boundingbox. As for the model, I think that the best method is as ShaneCraft mentioned, adding your own render class. I hope this gives you enough information to get a good start on it and stop bumping.

I heavily suggest opening the block class, scrolling down to around one third of the class and being amazed that there is, in fact, such a simple method that you could use. So in a sense I should applaud you, it is more effort to go to this forum and write the question than it is to look it up.

yes, there is. And since you probably won't be happy with just that, have a look at the leave class which decays if it doesn't find wood. And if you want to write a method yourself, use metadata to decrement until it hits zero, then decay the blocks. And I don't see how this can even be a question, there obviously are ways.

My apologies, I seems I misunderstood from my part as well. If you want to show the water, have a look at the cauldron class, that does exactly that. And generally it is just as simple as override the blockactived method, get the players currentitem selected in inventory and swap that item(the waterbucket) with a bucket. To right my wrong, let me give you that little piece of code: /** * Called upon block activation (right click on the block.) */ @Override public boolean onBlockActivated(World parWorld, int parXCoordinate, int parYCoordinate, int parZCoordinate, EntityPlayer parPlayer, int par6, float par7, float par8, float par9) { parPlayer.inventory.setInventorySlotContents(parPlayer.inventory.currentItem, new ItemStack(Item.bucketEmpty, 1)); return false; } This should do the job.

Alright, let me give you some pointers in the right direction. First, Errorlogs generally are there not to be annoying and bothersome, although I don't deny they are, but to point you to the correct error and where it happens. So read the Log! And this is the second time in an hour or so I say this. Your log says it all: Caused by: java.lang.NoSuchMethodException: com.fertilisNatura.fertilisNatura.EntityCustomItem.<init>(net.minecraft.world.World) at java.lang.Class.getConstructor0(Unknown Source) ~[?:1.7.0_25] at java.lang.Class.getConstructor(Unknown Source) ~[?:1.7.0_25] at cpw.mods.fml.common.network.internal.EntitySpawnHandler.spawnEntity(EntitySpawnHandler.java:72) ~[EntitySpawnHandler.class:?] [/Code] It can't get the correct constructor. Ie. You're passing or doing something that a normal EntityItem doesn't ask. Secondly I wouldn't inherit from EntityItem if I were you. This is simply my opinion but I'd inherit from Entity like EntityItem does and simply copy the code and adjust were necessary. It generally allows you to be a bit more flexible but obviously causes a bit of code redunancy. E.g it's a preference. If you do inherit from EntityItem. Then add @Override to your methods, I can't see how you would even interact with your base class if you simply add dead methods that aren't called anywhere. Thirdly, putting your subject title in capitals generally doesn't really help with anything.

Probably yelling at other people that haven't heard of OOP and trying to reinvent the water in minecraft. Oh and by the way, can this error be any clearer? Try to read your logs, it generally helps. Caused by: java.lang.NullPointerException at net.minecraft.client.renderer.entity.RenderManager.getEntityRenderObject(RenderManager.java:207) ~[RenderManager.class:?] at com.julianscode.mobloot.RenderDeadMob.doRender(RenderDeadMob.java:18) ~[RenderDeadMob.class:?] at net.minecraft.client.renderer.entity.RenderManager.func_147939_a(RenderManager.java:300) ~[RenderManager.class:?] [/Code] Basically your RenderObject or the mob you want to render is empty, most likely a case of the event not capturing the mob. Try to see when you kill it if Event.EntityLiving.GetEntityid(); or something like that returns an id.

I don't want to be a wisenose or anything of that sort but I would like to point some things out: 1. Minecraft has allready got a water bucket, and no, that wasn't added in the last update. 2. Have you tried looking at the classes of the bucket and waterblocks? 3. Have you tried looking at the classes of the bucket and waterblocks? (yes I typed this twice, go look at it!) 4. It's the same for any other block actually, it's just replacing the block with air.

Have a look at the custom player skin code. That's exactly what it does. And yes, that is also possible for mobs. I remember a mod that allowed you to take a sample of yourself and make a clone of yourself that followed you around. So yeah, it definitely is possible.

Well first start by adding @Override to your TileEntity.updateEntity method. Since it is just a method that isn't called right now. Furthermore you just say worldObj.isDaytime() to check if it is daytime in your tileentity. Secondly, check whether it is the server you need or the client with worldObj.isRemote, I gather the cycle is set on the server side. That's about all you need I think.

Well, all you really have to do is think logical. Let us analyse what you want: - change texture - right click - change metadata - stick The block class has a convenient right click method which we can simply override @Override public boolean onBlockActivated(World parWorld, int parXCoordinate, ...) { return false; } The metadata as well can easily be set in this method by calling: parWorld.setBlockMetadataWithNotify(parXCoordinate, parYCoordinate, ...); If it is just two texture you can toggle inbetween them by putting an if statement as a parameter: ParWorld.getBlockMetaData(x, y, z) == 0 ? 1 : 0 Selecting what to hold can also be achieved here, simply use the player parameter player.getHeldItem().getItem().equals(Items.stick) And rendering, well, you allready know a switch and then it is a simple matter of finding the correct method, as there are several that do just about the same things so I won't post any and leave it up to you, have a look in the Block.class and simply get the metadata and return the correct texture. Not that hard is it? All you have to do is think logical, have a look in the base classes what is allready there, what you can use and you're good to go.

Well, there are about 101 ways to do that. What did you have in mind?

Thank you, that's something at least, but what if it's something no one has never done? It is clear that you have never really programmed anything else except minecraft before, or minecraft seriously for that matter. But I applaud you that you're willing to take the effort, many "modders" are sadly stuck in the tutorial stage. Finding how to do something, or we can coin the term problem solving, is one of the major parts of writing code. Or rather it is the most important thing, even more so than written transparent code, writing code according to the standard, understanding different principles and being able to apply them. Let us, for convenience sake take a simple example: a minecraft tree. Making a minecraft tree is simple, we can easily find tutorials on it and minecraft has trees. But let us start a thinking process: What do we want to create? A minecraft tree, that's simple. OK. But what do we need to create that minecraft tree? Well, since it is minecraft we'll need blocks for that tree. Well, do we want to create new ones or do we want to reuse blocks? Well, lets create them. How many do we need? Looking at the other tree examples we'll need two. Let's create them. Generally one would follow the minecraft way here so knowing or having tutorial is handy. Well once those two blocks are created we can proceed. Well, what now? We have our two blocks what do we do with them? It's simple really, we place them in the world. But how do we do that? Well, generally we'll want a tree class, a class that's specific for our tree, so we'll define how it'll look and what it'll do in that class. Once we are in our class we can proceed with placing them. We want to place a tree anywhere we can so we'll want a method and the code to place it inside. And then it is a simple matter of calling the parWorld.setBlock command with the correct id and location( base location xyz + or - value). Something which has been created for us, if it hasn't we'll have to create a method or class that can do that etc. However, we still need to be able to be called by the minecraft code, so have a look at the examples, ah, they inherit a class. Because they inherit it is best to inherit that as well. And so on and on and on. In reality one would look first at the examples and try to copy them as close as possible so as to not run into problems you shouldn't run into. If there are no examples, e.g. you are writing your own application, it is best to look at it structurally, what do I want, what do I need for that and how will I do it. And it helps writing it out on paper if you're not fluent with it. The same for code, both even have several types of diagrams to help people structurize and ease programming and example for logical thinking is a flow chart, and example for coding is a Nassi–Shneiderman diagram. Once you are more advanced (I say more but really every single experience or thing you learn changes how you program) you will notice those things more easily. It's like learning to be a butcher. Let's say you have a cow in front of you, well if you've never done it before or are still learning you'll need to think. Where to cut best not to spoil the meat for instance. A professional butcher doesn't need to thing, he knows that if he cuts there it'll be good. The same applies to programming. Take our previous example for instance, we put a setblock line everytime we wanted to place a block. A programmer who's more at ease with the code will use for loop since clearly if you want to place 10 identical blocks in one line then there has to be a better way to do so. In general it comes down to you trying things out, make a tree from a tutorial then create a tree on your own, then add an extra block to that tree, then make it sparkle etc. And I would also suggest looking up java tutorials, it'll introduce new techniques to you and you'll be far more flexible. This will show in your logical thinking and in your code. And even, in life outside coding(does that even exist?) you'll find applications because if the next time you have an art history exam with a difficult question you'll say: What do I want? What do I need for that? And how will I do it? You'll set your pen on the paper and start writing List<? extends AnswerInMyBrain> Answer = new Answer(); And it'll throw an error...

Excuse the fact that I am somewhat late but I needed to find the time to give the minecraft code a look. In any case I wrote these few lines and they work splendidly, the only thing that they don't do is increase the chance for rare drops, which, unsurprisingly, are safely put away behind dumbly written methods and variables. If you do want that, the best way I see is a wrapper class around EntityLivingBase, something which I believe you stated you didn't want so I avoided it. The other possibility is creating a hashmap with the entities as keys and everytime an entity is encountered it doesn't know yet, spawn about a thousand of them, capture the drops, check which drop are below a certain amount and add those drops in a List<EntityItem> to the value in the hashmap. A bit convoluted to say the least, although I don't think the mobs would show themselves so the temporary lag should be negligent. Other than that, is just about regulates everything you could want. public final class KillMobs { public static void KillPresentMobs(World parWorld, EntityPlayer parPlayer, int parItemDropAmount, AxisAlignedBB parAxisAlignedBB, int parArmourDropChance) { List<EntityItem> OldentityItems = parWorld.getEntitiesWithinAABBExcludingEntity(parPlayer, parAxisAlignedBB); Random rnd = new Random(); //Loops through current entities and selects the mobs. for(EntityLivingBase Ent: Iterables.filter(parWorld.getEntitiesWithinAABBExcludingEntity(parPlayer, parAxisAlignedBB), EntityLivingBase.class)) { if(rnd.nextInt(100) <= parArmourDropChance) { //drop armor if the conditions are right(random is below chance and selected slot has armor) Ent.entityDropItem(Ent.getCurrentItemOrArmor(rnd.nextInt(4)), 0); } //kills entities and captures their drops(it does not prevent them from falling) Ent.captureDrops = true; Ent.attackEntityFrom(DamageSource.causePlayerDamage(parPlayer), 100f); List<EntityItem> ItemDropList = Ent.capturedDrops; for(EntityItem DropItem: ItemDropList) { //adds extras for the amount specified by parItemDropChance for each item dropped Ent.entityDropItem(new ItemStack(DropItem.getEntityItem().itemID, parItemDropAmount, DropItem.getEntityItem().getItemDamage()), 0); } ItemDropList.clear(); } //Checks if mobdrops are on, if not it will delete the mobdrops. if(parItemDropAmount == -1) { for(EntityItem OldItem: Iterables.filter(OldentityItems, EntityItem.class)) { for(EntityItem EntItem: Iterables.filter(parWorld.getEntitiesWithinAABBExcludingEntity(parPlayer, parAxisAlignedBB), EntityItem.class)) { if(EntItem == OldItem) { EntItem.setDead(); }}}}}} And if you'll excuse me now, I need to go complain to my cat about how horrible the minecraft code is written.

Well, there are a few ways to go about this, but the most common practice would be to compile one into a jar and use it as a library for the second. Have a look as how you would implement a feature of buildcraft into your own mod for instance. There are tutorials about that and if you do the same thing you should be able to use it as a basic API. As for codewise, basically make your code very trans parant with lots of getters and setters and whatever methods you need to interact with your variables in your base mod. In other words, decent programming behaviour is a must. And you have to create it as if it is a mod if you want to use it in a forge environment. An Api is just another mod that you're using so there is nothing different from the usual ones.

Have a look at this tutorial, it mentions and fixes the problems you describe.

Well it is very simple actually. If you punch or touch him you need to override the correct function, neither of which I see in your provided code. Furthermore, if you override a squid it is quite normal it won't do anything as a squid doesn't interact with the player, with the exception of dying of course. Basically, look at the base class of EntityWaterMob base class. Have a look at the following functions: protected void attackEntity(Entity par1Entity, float par2) { } protected Entity findPlayerToAttack() { return null; } public Entity getEntityToAttack() { return this.entityToAttack; } public void setTarget(Entity par1Entity) { this.entityToAttack = par1Entity; } And if you need to right click the entity have a look at the base class EntityLiving(below EntityWaterMob): protected boolean interact(EntityPlayer par1EntityPlayer) { return false; } So really, all you have to do is go into the classes your mob inherits and look which functions you need, override them and add what you need. Everyone needs to do that.

Well, how about this then. public final class KillMobs { static ArrayList<EntityItem> ItemDropList; public static void KillPresentMobs(World ParWorld, EntityPlayer player, int ItemDropAmount) { List<Entity> entities = ParWorld.getEntitiesWithinAABBExcludingEntity(player, player.boundingBox.expand(5.0D, 5.0D, 5.0D)); for(Entity Ent: entities) { Ent.captureDrops = true; Ent.attackEntityFrom(DamageSource.fallingBlock, 100f); ItemDropList = Ent.capturedDrops; for(EntityItem DropItem: ItemDropList) { Ent.dropItem(DropItem.getEntityItem().itemID, ItemDropAmount); } ItemDropList.clear(); }} } It adds to the usual drops the amount you wish to add without reflection and displays the kill animation. It's not perfect yet, e.g. the arraylist should be replaced with something that can be modified more quickly, it doesn't modify the droprate(which you didn't ask) and it can't drop nothing(unless you destroy entities on the floor) but in general it works. And I don't think I need to tell you that the above is a static class so it is easy to test.

Well to be honest, I have no idea what you are trying to do, apart from making another nice machine, but from your previous reply I deduce a mob grinder. If this is the case, how about this: List<Entity> entities = ParWorld.getEntitiesWithinAABBExcludingEntity(player, player.boundingBox.expand(5.0D, 5.0D, 5.0D)); for(Entity Ent: entities) { Ent.setDead(); } If you call this every say, quarter or half a second you should easily get them all without needing to cast, although that function too takes some time. player.boundingbox can obviously be substituted by your blocks boundingbox or coords. And if you're trying something more interesting, please enlighten us.

One thing I sometimes use to access methods I cannot get to with reflection and am burdened by efficiency is code redundancy. Basically partially recreating the method you need that is private or protected in your own class or subclass and use that one. Now I know that EntityLivingBase is quite complex but what you can do is create a new EntityLivingBase class, invoke it on load time to take from the original class the data it needs, build in a timer and at regular intervals adjust the data again. That way you can use that class and use it on maximum efficiency. The downside is that it produces duplicate code, reduces transparency, and depending on wether you need it or not, speed of updating it can weigh it down a bit, but still, it should be faster than reflection. And if you tweak it to fit your situation I believe you can just about do anything you need to do. This isn't really a wrapper class as such since it creates its own methods but it can be used like that. Just a note though, I wouldn't call this proper coding practice, but it works when it has to.

That seems indeed to be the best solution and one I hadn't thought of yet. Thank you for your help.

Well, a plant itself has a updatetick() method which you can override to let it grow. However I believe it to be quite a hassle to store your data without an nbt tag. I'm to inexperienced to really tell you what the best method is but to me it seems making it a tile entity is the best way to go. And I explained you allready that a tileentity has a UpdateEntity() method that ticks every 1/20th of a second. So you can simply use that to diminish your counter. Or you could use the UpdateTick() method from the plant itself and set the value you want to diminish to 16 and simply count down with that. It's much simpeler and friendlier than a TileEntity. And if it needs to be longer you can always declare a temporary variable and everytime the method ticks diminish the temporary variable, and if that one reaches a certain treshold diminish your metadata. Quite a lot of ways to do this really.

You're understanding me incorrectly, I'm basically creating new blocks on runtime by means of itemdamage, or mob id if you prefer. Basically I take one mob from the EntityEggs HashMap, take the spawnegg colour for that mob and apply it to the block together with the mobid. That way I can have a block for every mob that is added. That might be true but that still doesn't answer my question. I need to be able to name my own blocks, which I do not know the name of yet before compile time because they are made on basis of those mods/mobs that are added. And the way I understand lang files is that you have to add the names beforehand which I cannot use since I need to add them once the game is running. Let me tell you a simple example: Mod A adds a mob called 'Golem'. In turn, my mod creates a woodlog for that mob, with the colours of its spawn egg. And should name it Golemwood Log. In the old code I could do that simply by running LanguageRegistry.addName(new ItemStack(BaseLog, 1, Egg.spawnedID), EntityName + "wood Log"); with EntityName being the name gotten from the entity. But I am quite unclear as how to do this with the language files.

Good evening, It generally depends on wether this is a block that's only appearing once or twice in a world or is plentiful like a block of dirt. In case of the first you can simply use a tile entity, set a variable to the desired number of ticks, save them with nbt, and under updateEntity() simply diminish the variable. As for the effect, I suggest looking up a decent tutorial on potions. Greetings, Black