kauan99

So, this is Gumball here. This is my very old account from when I was little. My "Gumball" got summarily banned cause I asked a question about Minecraft Forge on a forum about Minecraft Forge. Go figure... anyway, send any new PMs about this thread to this profile. Thank you.

That was my initial ideia but I think that can be a performance breaker. The number of objects of MyEntityAnimal can be any arbitrarily big number (as many as the player spawns through eggs or breeding) and I think things would break pretty soon. Unless there's a way to make nearby MyEntityAnimal mobs act as one (they do just one search and share the location of the special blocks found among each other). Do you think that's possible?

Hi everyone! I'm studying EntityAnimal now. I'd like to know if it's possible to make it look for a certain type of block. I can make it find another Entity or subclass of entity using an algotithm kind of inspired by the one in EntityAINearestAttackableTarget.shouldExecute(), but I don't know how to use Bounding Boxes to detect the presence of blocks (yeah, still shooting in the dark when it comes to bounding boxes. Why doesn't anyone answer my questions about that? :'(). I use the same World.selectEntitiesWithinAABB used by shouldExecute method mentioned earlier. Is there way to make an EntityAnimal find a block? (one that doesn't involve nested for loops to look at every block in an area around the animal, cause I think that would have a sensible performance impact) Thanks in advance!! P.S.: I didn't post my code for finding entities because it's not relevant, would be distracting and it doesn't do what I want, that is, to find a specific block. But if anyone is interested I can post it, as an off-topic answer.

That's basically it. And since EntityPlayer implements ICommandSender, I'd like to add, for making the answer more accessible that you can do this: void someMethod(EntityPlayer player, (some other args)) { player.sendChatToPlayer("Hello, player"); } Meaning that you can send chat to a player from any method thart has an EntityPlayer as a parameter, simply by invoking sendChatToPlayer on the EntityPlayer object. It doesn't necessarily has to be an EntityPlayer object. As long as the object implements ICommandSender (as already explained by Major Tom) it will have that method defined.

Well I really don't understand about modifying minecraft classes but I'll try a wild guess. Maybe doing everything in the actual EnumArmorMaterial class is the reason it only works for eclipse. I'm not sure (and not willing to test) but I think changing a minecraft class in eclipse doesn't change it's corresponding class in your minecraft folder. Unless you are also copying the classes you change into your actual minecraft folder somehow. Those would have to be the re-obfuscated versions of those classes.

I copy-pasted your code and filled in with the missing registering and item instantiation, ran the game, and everything worked fine. So there's either something wrong with your minecraft/forge files or, as I said before, the error is somewhere else, not in those two harmless little pieces of code you posted.

Hi all! When I register an entity EntityRegistry.registerModEntity(MyAnimal.class, "OneAnimal", myAnimalID, this, trackingRange, trackingUpdateFrequency, true); What are those two "tracking" arguments about? I thought it would be the rate at which the method EntityAnymal.onLivingUpdate would be invoked but that's not it. That method gets invoked even more often than 20 times per second (maybe it's a client/server thing and the method gets invoked once for the server and again for the client, I don't know) I thought that if I set trackingUpdateFrequency to like 20 MyAnimal would only get it's onLivindUpdate method invoked once a second. Which is not the case. So, what are those tracking related arguments, what's entity tracking anyway, and is it possible to make MyAnimal.onLivingUpdate to get invoked less frequently? thanks all.

It does have a constructor, even if it's an implicit one. And more importantly to this situation, a static constructor. advkit.AdventureKit.<clinit>: this is telling you that theres something wrong with the static constructor of advkit.AdventureKit, be either explicitly or implicitly, all types must be statically initialized (clinit stands for class initializer while init is your instance constructor). If you don't have an explicit static constructor, then check if all the static fields in your advkit.AdventureKit class are properly initialized before being statically referenced. Also check advkit.ItemHeadlamp.<init> and net.minecraft.item.ItemArmor.<init>. Remember that the error stack is a stack. If some method A is one line above some other method B, it means A invoked B. So the origin of the error is the bottom of the stack. The 2 little pieces of code you posted do seem fine. I think you are failing to notice something else.

I may be wrong but it looks like the origin of the error is in the static constructor of advkit.AdventureKit. And the error itself is a null reference being used as if it was not null. Do you initialize all you need in your advkit.AdventureKit static constructor? Maybe it's just my lack of expertise but for me the tiny pieces of code you posted are only enough for guessing.

Hi again! Don't copy things word by word. It's very likely people answering on these forums will make small errors like typos because in eclipse things like that are automatically corrected for you. Now, let's see those errors you're getting. The first one is really strange but it's very easy to fix. Look at the beginning of your code. There are a lot of import statements up there. Import statements save you from having to call each type by it's fully qualified name all the time. The full name of a type (class or enum or whatever else Java has to offer as a type) is prefixed with the package that type belongs to. for example, minecraft class Item has this full name: net.minecraft.item.Item. And here's what's wrong! you are importing the wrong type. Look there, you are importing a class named Item that belongs to another package: Change this: import cpw.mods.fml.common.Mod.Item; to this import net.minecraft.item.Item; Ok, the second error is a stupid error of mine. But this happens when you're outside an IDE. Just remove the reference to ZanofiteSword from the argument list of setUnlocalizedName. I don't even think that method has an overload that takes an Item reference as an argument. My bad: Change this: public static final Item ZanofiteSword = (new ItemSword(itemzanofitesword, ZanofiteToolMaterial)).setUnlocalizedName(ZanofiteSword, "ZanofiteSword"); To this: public static final Item ZanofiteSword = (new ItemSword(itemzanofitesword, ZanofiteToolMaterial)).setUnlocalizedName("ZanofiteSword"); As for the third error, just remove that line entirely. Did I really write that? I'm sorry, sometimes I answer these from bed, just before going to sleep (which is the case now). That line doesn't make sense at all. And the last one. You have a field named itemzanofite (the first field in your class) and it's an integer. The overload we want to use of the method GameRegistry.RegisterItem has the following signature: void GameRegistry.RegisterItem(net.minecraft.item.Item arg0, String arg1) (don't copy-paste that anywhere, I'm just making a point). Which means it expects an Item as first argument and a String as its second argument. So, instead of passing your int field, you need to pass your actual Item field: Change this: GameRegistry.registerItem((net.minecraft.item.Item) itemzanofite, "ItemZanofite"); To this: GameRegistry.registerItem(ZanofiteItem, "Itemzanofite"); (Also notice the different casing in the String passed as second argument. You have to use the same string you passed to setUnlocalizedName) AND finally, don't forget to invoke your SwordWork method from inside the load method. As it is now, that method never get's invoked and it's work is never done. So your sword is never properly registered. Add this line to the load method: SwordWork(); That's it. I hope it works now, but if it doesn't work because of minor errors like those you had before applying these corrections, it's probably gonna be easier to figure out what's wrong and fix them after reading this post. Good Luck!

Sorry to do this, but I'm stuck. Anyone??

Why would you move your files? Just read what I wrote and do that. It will work

Hi all. I just tested the first case I suggested above in a simplified manner. I added a line this.maxX += 1 to the constructor: public class TwoBlock extends Block { public TwoBlock () { super(TwoBlockID, Material.rock); this.maxX += 1; } } I correctly get a block that's 2x1x1, with it's enlargement portion being at x + 1 relative to the point where I place it. But, I can only collide with the x, y, z portion of the block. I can pass through the x + 1, y, z portion of the block, the enlargement portion. I cross it unimpeded when I move along the Y or Z axes, and I get some sort of partial collision when I move along the X axis, i.e. when I walk inside the enlargement portion towards the normal portion. If I do this, I get pushed back a little bit when I reach the normal portion. How would I build this block so I would collide normally with it? I'm gessing I'd have to use those methods I asked about earlier? Thanks for any help!

Thanks for replying! Let me see if I understand something: Do I ever need to override those methods? If I ever need a block that is not just a standard 1x1x1 block. Let's say I need a 2x2x2 block for some reason. Would I have to write another implementation of those methods? I ask because I'm still not sure when those methods are invoked and for what purpose. In that case of the 2x2x2 block, could I just change the values of block.maxX, block.maxY, block.maxZ instead of overriding any of those 3 methods to make my bigger block? In a second hypothetical scenario, Imagine that for some reason I need a block with a complex shape (for example, imagine the shape we use to create an iron golem. Let's say for this question's sake I need to have a block shaped like that). Then, I think just changing block.maxX, block.maxY, block.maxZ wouldn't be enough. So, in this case, I'd have to override those methods. Is that what those methods are for? Or I didn't understand a thing...?

Hi all. After successfully implementing the 6 textured block, I decided to try the bounding boxes again. I'm reading the Block class, method by method. To be able to continue my reading and understanding of the class, I must understand these methods: /** * Adds all intersecting collision boxes to a list. (Be sure to only add boxes to the list * if they intersect the mask.) Parameters: World, X, Y, Z, mask, list, colliding entity */ public void addCollisionBoxesToList(World world, int x, int y, int z, AxisAlignedBB mask, List list, Entity collidingEntity) { AxisAlignedBB aabb = this.getCollisionBoundingBoxFromPool(world, x, y, z); if (aabb != null && mask.intersectsWith(aabb)) { list.add(aabb); } } @SideOnly(Side.CLIENT) /** * Returns the bounding box of the wired rectangular prism to render. */ public AxisAlignedBB getSelectedBoundingBoxFromPool(World world, int x, int y, int z) { return AxisAlignedBB.getAABBPool().getAABB(x + this.minX, y + this.minY, z + this.minZ, x + this.maxX, y + this.maxY, z + this.maxZ); } /** * Returns a bounding box from the pool of bounding boxes (this means this box can change * after the pool has been cleared to be reused) */ public AxisAlignedBB getCollisionBoundingBoxFromPool(World world, int x, int y, int z) { return AxisAlignedBB.getAABBPool().getAABB(x + this.minX, y + this.minY, z + this.minZ, x + this.maxX, y + this.maxY, z + this.maxZ); } Please, anyone kind enough to explain those methods to me? Pretty please?

Hello. These are my thoughts on that subject. A Java enum is a special type of class the represents a limited set of constant and immutable objects. The best thing to do is probably to edit the original enum if you need one more of these values in your limited set. To "cheat" enums via reflection is not a good idea. Save in cases where you are kind of "hacking" into some code that is expected to remain the same (i.e. some code that you can't change for your own purposes, like minecraft's class files). That's the case of Forge's EnumHelper, which is really helpful. But to go on changing enums at runtime without any REAL need defeats the purpose of a limited well known set of objects. I believe that's included under the concept of type safety? This is my opinion, which is based on what is considered good programming practice by most people, I think.

Yes. I think it is possible. In my sleep I realized I was counting from 2 to 5 instead of 0 to 3 to define the 4 basic directions (probably because they are counted like that in minecraft, 0 and 1 meaning down and up). So I was wasting a "whole bit". We can't afford that! I'll try again after I come back from school today. Jesus, I'm dreaming of Java now. What's wrong with me!?! EDIT: It worked!

That will be awesome! I'm a noob but if there's any way I can help let me know

I thought about those fields but I don't know what they mean. I don't know what's yaw or pitch etc. I don't even know what is the unity used to measure rotation. I got some Vec3 from a method called "getLook" but, again, I don't know what it means. This Vec3 has 3 really small float numbers (like 0,0000283... etc) that change in a seemingly random way as I move. Has anyone already figured out how to determine the general direction an entity is facing (either north, south, east or west) who can explain it, please? Thanks EDIT: I believe I maye have figured it out but for no use. I can't combine both informations (if facing Up, Down or neither and the general direction) in a 4 bit nibble This is probably the reason why minecraft itself doesn't have any block with 6 different textures, one for each face.

oh I know about the names... It just adds up to the problem. It's complex stuff, written in a crazy obscure way (this is the part I blame Mojang for, haha) and without meaninful names (which is unavoidable, I suppose). Anyway, I decided to focus on the parts regarding sides and orientation. I've implemented a multi-textured block (each of it's 6 sides has a texture: front, back, top, bot, left, right). I copy-pasted BlockPistonBase.determineOrientation and found out that it returns an integer from 0 to 5, each meaning a different side from where you placed the block. So, I wrote my own registerIcon and getBlockTextureFromSideAndMetadata because 1) I couldn't understand how their implementation in BlockPistonBase class worked and 2) My block has 6 textures instead of only 3 (i think it's 3?) like pistons. It all works fine when I place the block from any side other than "from above" and "from bellow". Because, the way I did, you always get each texture on a particular side, depending on from where you placed the block (the return of determineOrientation). The problem with this approach is that if I place the block from bellow or from above things like "left", "right", "top" and "bottom" should mean different things, unless you are DIRECTLY above or below the block you placed, you are always kinda at one of the 4 other positions. So, how could I change the implementation of BlockPistonBase.determineOrientation to fix that? Because I don't really have any idea of how the method does what it does, I can't figure out what to change to make it work the way I mean to. EDIT: If I knew of a way to know which direction a given entity is facing (the same info shown when you press f3 and you can read north or south or east or west there) then I think I would be able to do this. Does anyone know how to get the direction an entity is facing?

Oh, first of all, when i wrote this: public static final EnumToolMaterial ZanofiteToolMaterial = EnumHelper.addToolMaterial ( "Zanofite", [harvestLevel (6)],//<error [maxUses (3000)],//<error [eficiency (12)],//<error [damage (6)],//<error [enchantability (21)]//<error ); What I meant by each of those error lines is that you should add your own value to them. I wrote things like that to make it clear what each argument meant. So that method should be invoked as follows: public static final EnumToolMaterial ZanofiteToolMaterial = EnumHelper.addToolMaterial("Zanofite", 6, 3000, 12, 6, 21); Also, notice that you dont need that ItemZanosword class. You can take a look at net.minecraft.item.Item class and check out how minecraft creates all swords (and other tools) by simply calling the proper constructor passing the id and the ToolMaterial as arguments. You can do the same as minecraft does, like this for example: @Mod(modid="Zanofite", name = "Zanofite", version = "0.0.1") @NetworkMod(clientSideRequired = true, serverSideRequired = false) public class Zanofite { /* here are your IDs. But remember not to use those for other purpose than instantiating the items, because they * change internally. If you ever need to reference the ID of any Item use the field Item.itemID like this: * int zanoswordID = ZanofiteSword.itemID.*/ private static final int itemzanofite = 501; private static final int itemzanofitesword = 502; /* Here is your ToolMaterial. You can make ItemSword, ItemAxe, ItemPickaxe, etc by passing this field as the second * argument to the constructor, just like we do it with the ZanofiteSword bellow.*/ public static final EnumToolMaterial ZanofiteToolMaterial = EnumHelper.addToolMaterial("Zanofite", 6, 3000, 12, 6, 21); public static final Item ZanofiteItem = new ItemZanofite(itemzanofite).setUnlocalizedName("Itemzanofite"); /* And here is your ZanofiteSword.*/ public static final Item ZanofiteSword = (new ItemSword(itemzanofitesword, ZanofiteToolMaterial)).setUnlocalizedName(ZanofiteSword, "ZanofiteSword")); @Init public void load(FMLInitializationEvent event){ ZanoItemWork(); SwordWork(); } /* And etc. Go on defining your ZanoItemWork and SwordWork methods for registering as before. Don't forget to use the * same unlocalized names that you gave to your items when instatiating them. */ } Also, notice that whenever you need to access a static field/method of a class from outside that class, you need to prefix the field/method name with the name of the class. For example, addToolMaterial is a static method of the class EnumHelper, and this is why we have to write EnumHelper.addToolMaterial to invoke this method. So, outside your Zanofite class, to access your sword and other static fields you have to write Zanofite.ZanofiteSword, Zanofite.ZanofiteItem and so on. I hope I was clearer this time. Sorry for omiting a few things last time.

It's impossible for me to understand BlockPistonBase :'( Due to it's inherent complexity, minecraft's extremely confusing and labyrinthine coding style (it must be hell inside Notch's head) and the lack of meaningful names on parameters and local variables. I quit trying to understand this class.

Thanks! That's a real good start! I'll resume studying now that I know a little more. If anyone has something more to add, though, it would help even more! Thanks again

Hello everyone. Pardon my English. I was looking at the BlockPistonBase class because I want to understand it's funcionality and there are 2 methods that are real mysteries to me: /** * Adds all intersecting collision boxes to a list. (Be sure to only add boxes to the list if they intersect the * mask.) Parameters: World, X, Y, Z, mask, list, colliding entity */ public void addCollisionBoxesToList(World par1World, int par2, int par3, int par4, AxisAlignedBB par5AxisAlignedBB, List par6List, Entity par7Entity) { this.setBlockBounds(0.0F, 0.0F, 0.0F, 1.0F, 1.0F, 1.0F); super.addCollisionBoxesToList(par1World, par2, par3, par4, par5AxisAlignedBB, par6List, par7Entity); } the other one seems related to the first one: /** * Returns a bounding box from the pool of bounding boxes (this means this box can change after the pool has been * cleared to be reused) */ public AxisAlignedBB getCollisionBoundingBoxFromPool(World par1World, int par2, int par3, int par4) { this.setBlockBoundsBasedOnState(par1World, par2, par3, par4); return super.getCollisionBoundingBoxFromPool(par1World, par2, par3, par4); } They are both about Bounding Boxes. I assume a Bounding Box is a Box of uncrossable space, and that any moving thing will collide with it and halt it's movement. If someone could explain them further and give me an insight on how Bounding Boxes and those 2 methods work I'd very much appreciate it. Thanks!

For someone who has no idea what you're talking about (that being me), his signature is magic!! *-*