Jump to content

Choonster

Moderators
  • Posts

    5117
  • Joined

  • Last visited

  • Days Won

    75

Everything posted by Choonster

  1. You're using the 1.7.10 method signatures, but they were changed in 1.8. If you look at the WorldGenMinable class, you'll see the new signatures for the constructor and the generate method. In 1.8, most Block and metadata method parameters were replaced with an IBlockState parameter and individual coordinate parameters were replaced with a BlockPos parameter.
  2. Explicitly comparing booleans won't cause any problems, it just makes your code look messy (and needlessly verbose).
  3. When the player uses the item, store the current total world time (World#getTotalWorldTime) in the NBT. When they use it again, subtract the stored time from the current time and check if it's been at least X ticks since the last use (where X is the cooldown). If it has been, store the current time again and perform the effect; otherwise do nothing. I have an example of this for 1.8 here, I've tried to document it fairly well.
  4. Yes, but there's no need to explicitly compare a boolean to true or false. Just use if (someMethod()) or if (!someMethod()) .
  5. A NullPointerException is being thrown because either itemstack or itemstack.stackTagCompound is null , I suspect it's itemstack.stackCompound . Always check if an ItemStack has a stack tag compound before trying to read from or write to it.
  6. Use IWorldGenerator and GameRegistry.registerWorldGenerator to generate something in the world. You can use World#getTopSolidOrLiquidBlock to get the y coordinate of the highest solid block (excluding leaves) at the specified x and z coordinates (which is usually the ground).
  7. this is what i would do: (remember, you can design your own system to fit your needs, this is just what i would do) have a private final field in your item class containing the cooldown time in ticks. (in this example i'll call it cooldown). timer is the value of the timer (don't know if you want to save it to the nbt or as the dmgValue) in opUpdate(): if(timer > 0){ >>> decrement the timer } in onItemUse(): if(timer <= 0){ >>> use spell >>> reset timer to cooldown } you can use this to get an idea of a possible implementation, but you'll have to implement the actual system yourself, so you can make sure it fits your needs Storing any data in a field of your Item class is a Bad Idea. Item s are singletons, so that cooldown will be shared between all occurrences of that Item . If you need a cooldown, use NBT.
  8. When you set an item as "in use" (like the bow does), you specify the maximum duration of the use (how long the player can hold right click to continue using the item). The useRemaining parameter of getIcon is how many ticks of that maximum duration remain. Subtracting the remaining duration from the maximum duration gives you the current use duration (how long the player has been using the item).
  9. FluidStack has an NBT compound tag like ItemStack does. Most Fluid getter methods supply a FluidStack parameter, which you can use to determine the returned value. Fluid s only exist as FluidStack s when in a tank or container (e.g. buckets) of some sort; when they're in the world as a Block , only the Fluid is known (so you don't have anywhere to store NBT data unless you make a TileEntity for the Block ).
  10. World#getBlock(int,int,int) was replaced by World#getBlockState(BlockPos) in 1.8, which returns an IBlockState . IBlockState#getBlock will return the Block of the IBlockState . You can use Entity#getPosition to get an Entity 's position as a BlockPos and BlockPos#down(int) to subtract an amount from the y coordinate.
  11. It's hard to help you without seeing your latest code and the error. Post them on Gist or Pastebin and link them here.
  12. Ah, I didn't get that from your last post. If it's rendering with colour in the world but grey in your inventory, you need to create a custom ItemBlock class that overrides Item#getColorFromItemStack like ItemColored does. You'll want to extend ItemSlab (to inherit the slab placement logic) and have a constructor that takes your actual single/double slab classes for the singleSlab and doubleSlab parameters instead of BlockSlab (so FML can find the constructor via reflection when you register your Block s).
  13. Like the error says, a model can only specify a parent or elements; but not both. Since you need to specify the tintindex in the elements, you need to define the elements yourself instead of inheriting from the default slab models. You'll need to copy the grass.json model, adjust the height (the y dimension of the from and to coordinates) of each element to 8 instead of 16 and remove the cullface from the up or down face (like the slab models). You can then inherit from this model for each variant of grass you want to support like the default grass models.
  14. Blocks are only rendered with a colour multiplier if the model defines a tint index for the face. Look at the grass.json and grass_normal.json models.
  15. The field with the @Instance annotation needs to be the same type as your main mod class (the one with the @Mod annotation), since it holds the instance of that class. Why are you doing this in ClientProxy ? Entities need to be registered on both sides. There's no reason to use global entity IDs ( EntityRegistry.registerGlobalEntityID ) or manually add spawn eggs in 1.8, if you need a spawn egg just call the EntityRegistry.registerModEntity overload with the two extra int parameters (the background and foreground colours of the egg).
  16. Add acceptableRemoteVersions = "*" to your @Mod annotation, like this.
  17. That's the actual grass texture, but BlockGrass overrides getBlockColor , getRenderColor and colorMultiplier to colour it depending on the position in the world. You should override these methods in MimicBlock to call the corresponding methods of the mimicked Block .
  18. The original code had FMLPreInitializationEvent as the parameter for all three methods instead of each method having the appropriate event parameter.
  19. Block IDs were phased out in 1.7, so the method was replaced by World#getBlock . This was then replaced by World#getBlockState in 1.8.
  20. Because that doesn't exist maybe? Removing from the Iterator changes the underlying List, so this should work just fine. I'm talking about the removeRecipe method in the code the OP posted, not the vanilla CraftingManager class.
  21. It doesn't look like you're calling craftingmanager.removeRecipe anywhere.
  22. It looks like you've tried to add your grenade as a naturally spawning entity with EntityRegistry.addSpawn (like a mob or animal), but this doesn't work because it doesn't extend EntityLiving . You shouldn't have added it as a naturally spawning entity in the first place.
  23. Yes, that will work. The doc comment of the @Mod annotation does show a brief example using required-after, but doesn't specify the exact format of the dependencies string (the field's doc comment references ModLoader's "priorities" string, so it probably hasn't been updated in a few years).
  24. In the dependencies field of your @Mod annotation, you can list dependencies as before / after (optional dependency) or required-before / required-after (required dependency).
×
×
  • Create New...

Important Information

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