Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by MrCaracal

  1. The "minor" trees are handled by the WorldGenTrees class. This does the 1x1 trunk oak, birch, and jungle trees. Did you mean you already had the custom leaf block and log block implemented, or that you had the generation method itself implemented?
  2. Could I ask for a clarification of your issue? By "vanilla minecraft installation" do you mean "Forge modded without other mods installed", which would indicate the problem is that your villager trades are getting "crowded out" by villager trades added by other mods?
  3. I looked through your posts and nobody told you to run 1.7.2, ever. If there were any incompatibilities with Intel Integrated graphics, they have been fixed since the thread you seem to be referring to... as was mentioned in that very thread. Have you tried updating to the latest version of: - Minecraft Forge - Your graphics drivers ?
  4. Code is always more informative than a crash report alone, even if you remember what the exception was. You said you're trying to generate a "simple" tree, but I assume you're trying to accomplish something beyond what the vanilla tree generation methods provide, as in, a different shape, or different blocks than vanilla leaves and logs? Even if not, it might be worth a while to poke around in the vanilla methods, all in net.minecraft.world.gen.feature, to see how they're doing things. Spoiler: it's just huge mess of if statements and loops.
  5. I was curious about this myself so I did a quick search. The bow rendering stuff you care about is in two different places I could find. *.renderer.ItemRenderer (lines 459-488), handles the first person view entity renders, deals with the EnumAction.bow animations, and *renderer.entity.RenderPlayer (lines 345-353), which looks like it sets the position, rotation, and scaling of the bow item in the hands of the third person player entity. You said you looked at the ItemBow class so you know about how the draw animation is handled no doubt. The ItemRenderer bit involves checking the getMaxItemUseDuration on the held ItemStack, which is something you'd be able to influence. Unfortunately it looks like the bit in RenderPlayer tests whether the held ItemStack == Items.bow, which obviously won't work for your mod item.
  6. How much of a performance improvement would that be, and what kind of performance are we talking about? Is it better to have a bunch of textures stitched by the CPU/GPU into a big one than just have a big texture fetched from memory? Asking because I genuinely don't know. Seems like one way would be more CPU friendly and the other way would be more RAM friendly. Also the stitched texture method, while clever, isn't particularly texture-pack friendly, is it?
  7. I assume you're asking about the vanilla client, since the Forge install downloads are at the top of the page. You can find any version of (vanilla) Minecraft through the launcher. Edit Profile -> Use Version -> [select Version] For clients: once Forge is installed, just select the "Forge" profile. For servers: The script for installing the server jar will download everything you need to the folder you indicate.
  8. Is your inventory ArrayList ever empty for any reason? If so, then it will crash on that line since you're checking the index position of Counter-1, which will be -1 if the counter is not incremented. Now, the counter is only incremented within your augmented for-loop, which won't execute if there are no elements in the inventory ArrayList.
  9. Ahh, I misunderstood. Thank you diesieben!
  10. Is this considered bad practice? I ask because I have set up my mod the exact way you just described.
  11. The pink and black box is the "texture missing" texture. Check the logs, they should be spammed with something like: [Client thread/ERROR]: Using missing texture, unable to load <blah>.png java.io.FileNotFoundException: <blah> This will tell you where your mod is looking for the textures, versus where they are actually placed.
  12. He answered that question already, actually. You need to use the command gradlew build This post has all the information you will ever need (for basic stuff) on ForgeGradle: http://www.minecraftforge.net/forum/index.php?topic=14048.0#post_compiling
  13. It's caused by a typo I think! From TileEntityBlastFurnace.java, lines 240 - 242: if(this.furnaceItemStacks[0].stackSize >= 0){ // If the ItemStack contains zero or more items this.furnaceItemStacks[0] = null; // Set the ItemStack to null } Now I know you might not know where the source of any given error in your project is, but linking to your entire project kind of comes off as "Here's my project, now fix it for me!" I doubt that's the impression you intended to give, but that's the one I got. Just something to consider.
  14. Yes, it is certainly possible! Everything extending from net.minecraft.block has a getHarvestLevel method, so you have all the pieces you need at your disposal already. Once again, I do not recommend continuing down this path, as you will be overriding existing universal methods (blocks have drop lists and drop items on their own) with your own methods (spawn items in world via unusual tool method). My prediction is that doing this will turn out to be more trouble than it's worth. I will assume you have considered all this and a very good reason for doing it this way, so cheers and good luck!
  15. You did in fact merely forget to register your GUI handler. Like diesieben first said, you must not only have a GUI handler, but also register it. I may have missed it but nowhere in your mod files did I see the GUI handler actually being registered with the NetworkRegistry. NetworkRegistry.INSTANCE.registerGuiHandler(modinstance, handler);
  16. WorldGenMinable accepts a "target block" as a parameter, and Air is just another block, no?
  17. Blocks handle their own drops, believe it or not! I notice you are spawning items in the world when onBlockDestroyed is called. If you do this, you will get more than what the block drops normally, as the block you destroyed has its own drop list which it also calls when it is broken. The reason it behaves this way only for things you can break with your fists is because those blocks have a low harvest level, and will drop whether or not the tool used to break them is of an effective harvest level. For blocks with higher harvest level, they won't drop if the tool does not have a sufficient harvest level. Your tool will the block's drops regardless, and so ends up spawning the drops twice for blocks with a low harvest level. If you want to continue using this method, you'll have to make it so that the block doesn't drop its own drops when broken with your tool. I would not recommend this method. Another way might be to set your tool's harvest level, and override the methods that test whether the tool is effective against a given material.
  18. I think there are only a few methods that ItemSword has that you'd need to worry about. One is func_150893_a, which I believe is a break-speed function. In vanilla, this allows swords to slice through cobwebs quickly. Another is getItemUseAction, which in vanilla displays block animation using the sword. I don't know whether you would want to override this since you've got a multitool and you may have other uses for right-click. The one you probably care about the most is setting the damage, and as far as I know this is now done using getItemAttributeModifiers. This is also used to generate the damage tooltip I believe. Check out the code in ItemSword for how these work in vanilla, and good luck! PS: I know this is a WIP, but I noticed your constructor receives a tool material but your tool class doesn't use it anywhere. If I might make a design suggestion, put a field that stores the ToolMaterial you pass to the constructor, and then get the statistics like the enchantability and durability from that. This would let you use a single class for as many tools as you like, rather than having to make new ones so you can return different values for getItemEnchantability or getDamageVsEntity. You can use EnumHelper to set up custom ToolMaterials that will store all this info for you! For example: // Arguments are: Name, Harvest Level, Maximum Durability, Mining Speed, Base Damage and Enchantibility. public static ToolMaterial SPAM = EnumHelper.addToolMaterial("SPAM", 2, 2000, 7.0F, 3F, ; public static ToolMaterial NOTSPAM = EnumHelper.addToolMaterial("NotSpam", 1, 1000, 1.0F, 3.0F, 2); // And now you can just pass your custom material to a tool. You would be able to use the same class for multiple materials, yay! public static Item spamTool = new ModItemTool(SPAM); public static Item notSpamTool = new ModItemTool(NOTSPAM); And in your item class, you would do something like: public int getItemEnchantibility() { return this.toolMaterial.getEnchantibility(); // It's all wrapped up in the material you passed to the tool. Tidy! }
  19. Since you've already made a few tools, you may have noticed that most or all of the tool classes you've extended from extend from one superclass, ItemTool. All vanilla tools except shears, buckets and swords extend ItemTool (these just extend Item), so looking through that class to see how it works and how the classes that inherit from it work seems like a good place to start.
  20. There isn't a method in the ItemBlock superclass (nor in net.minecraft.Block) that matches that method signature, which was where I was looking. A similar method exists in net.minecraft.Item though, as getIconFromDamageForRenderPass, but this method also does not affect the ItemBlock's rendering to any degree, no matter what I put as a return value there. There are no getIcon methods that accept an ItemStack as a parameter. Ignore this, I missed it, my apologies. But the method in net.minecraft.item still does not change the ItemBlock's rendering. So far I have tried: @Override @SideOnly(Side.CLIENT) public IIcon getIconFromDamage(int passedMetadata) { return Blocks.dirt.getBlockTextureFromSide(0); } @Override @SideOnly(Side.CLIENT) public IIcon getIcon(ItemStack stack, int renderPass, EntityPlayer player, ItemStack usingItem, int useRemaining) { return Blocks.dirt.getBlockTextureFromSide(0); } @Override @SideOnly(Side.CLIENT) public IIcon getIconFromDamageForRenderPass(int passedMetadata, int passedRenderPass) { return Blocks.dirt.getBlockTextureFromSide(0); } And none of the three seem to alter my ItemBlock's inventory render at all.
  21. Ahh, gotcha. No worries. I'm going to continue to look into this, since the more I think about it, the more I believe that setting the render type is the "improper" way to go about this. I'm thinking there must be some difference between Forge's RenderBlockFluid and Vanilla's RenderBlocks.renderBlockLiquid that is causing our mutual difficulty. Examining RenderBlocks.renderBlockLiquid will probably yield the answer, as that is what's called by getRenderType returning 4. The method is not pretty, though... EDIT: Eureka! I have discovered the difference. I have learned that Forge's RenderBlockFluid class is just a copy pasta of Vanilla's renderBlockLiquid with cleaned up method and variable names, save for the following: Forge's RenderBlockFluid checks a boolean value called "rises" which itself is based on whether the relevant fluid's density is greater than zero before rendering certain block faces. Vanilla's renderer simply calls the tessellator indiscriminately. I suppose the reason why it's set up this way is because KingLemming wanted to set up some kind of convention for liquids versus gases and so the rendering code is checking what the fluid's density is. I kind of see what KingLemming was going for here: if the fluid has zero or lesser density, it therefore "floats like a gas" and should be rendered such a way, and if the fluid does not float, don't bother rendering interior faces. Perhaps there is some wisdom here I am not seeing because I don't know that this implementation makes the most sense. A fluid set up to be within what the implementation considers "liquid density" will not render interior the interior faces when the player is submerged unless the fluid is considered to be "rising".
  22. Ah... really? Hmm! There must be a bug in my code, then. Now's your chance to help me out! How are you setting up your custom Materials? Whenever I pass a Material that isn't Material.water or Material.lava to my fluid block constructor, it causes an NPE when my fluid is rendered, in getFlowDirection. I think this is because getRenderType (4) calls BlockLiquid's getFlowDirection method in order to render, which is expecting those: public static double getFlowDirection(IBlockAccess p_149802_0_, int p_149802_1_, int p_149802_2_, int p_149802_3_, Material p_149802_4_) { Vec3 vec3 = null; if (p_149802_4_ == Material.water) { vec3 = Blocks.flowing_water.getFlowVector(p_149802_0_, p_149802_1_, p_149802_2_, p_149802_3_); } if (p_149802_4_ == Material.lava) { vec3 = Blocks.flowing_lava.getFlowVector(p_149802_0_, p_149802_1_, p_149802_2_, p_149802_3_); } return vec3.xCoord == 0.0D && vec3.zCoord == 0.0D ? -1000.0D : Math.atan2(vec3.zCoord, vec3.xCoord) - (Math.PI / 2D); } So if the material isn't water or lava, Vec3 is null and so the block can't render, then crash and sadness. My material is set up like so: public static MaterialLiquid chemical = new MaterialLiquid(MapColor.grayColor); And simply inserted into my liquid block implementation's constructor. But I don't the material declaration is the issue, considering the above getFlowDirection code...
  23. Is this necessarily true? Bear with me, I'm a noob, but I thought the server checks for "proper" movement of the player as an anti-cheat measure. If a mod is moving the player entity in ways that the server doesn't know about, couldn't that potentially cause the player to be kicked if the mod moves the player entity too fast or in a way that the server considers "flight"?
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.