Jump to content

coolAlias

Members
  • Posts

    2805
  • Joined

  • Last visited

Posts posted by coolAlias

  1. Try using Block.getItemForBlock(Blocks.cake) or something like that. If that doesn't work, then the cake block doesn't have a corresponding ItemBlock (like doors), but a special Item, so you'd use Items.cake or whatever it's called instead.

  2. As you read more vanilla code, you will see cases of when and when not to use !world.isRemote. Generally, you use it to encapsulate code that changes the world or things within the world, such as modifying a block state, giving a player an item, or spawning an entity. You only need to encapsulate the actual changing code, not necessarily everything around it, though sometimes that is useful to avoid wasting processing power on the client.

     

    Anyway, if you model your item after the hoe, then mimic their #onItemUse implementation more closely as I doubt they encapsulate the entire thing in an if (!world.isRemote) statement.

  3. World#playSound plays a sound only when called on the client side (i.e. when the world IS remote). My guess is that your method is only getting called on the server.

     

    Is #tillDirt your own method, or inherited from Item and/or ItemTool? If it's your own method, show the code that calls it. If it's a vanilla method, are you sure it is called on both the client and the server side?

     

    If you haven't already, take a closer look at the hoe to see how and where it plays its sound.

  4. Hm, your entity registration code looks correct, you're not doing anything strange in your Entity class, and you're testing in a new world so the entity name hasn't changed... those are the usual suspects when it comes to tracking entry errors, so it could be that spawn eggs in 1.9 are bugged. If my coding computer wasn't toast, I'd try it out myself to confirm it; if it is indeed a bug, you can open an issue on Forge's issue tracker (GitHub).

  5. In my earlier post, I mentioned this:

    if (!itemstack.hasTagCompound()) { // method name may vary based on version
        itemstack.setTagCompound(new NBTTagCompound());
    }
    

    That is the ONLY way you should ever set an empty tag compound on an ItemStack, and that will guarantee that the ItemStack does in fact have an nbt tag.

     

    You put that code as the first thing in your #onItemRightClick or #onItemUse method so that the first time the item is used, you will create the tag compound if it doesn't already have one. That way you can add / set your custom tag.

     

    You don't need to check if it has the tag or not; integer tags return 0 if they do not exist:

    if (stack.getInteger("abljeilahgahgeiah") == 0) {
        // either the tag didn't exist, or it is actually zero
    }
    

    Really, though, you shouldn't be too concerned with that if you follow my advice about using the world time + interval instead of a traditional cooldown timer. There is no reason to add yet another a ticking counter when you already have a perfectly good one.

  6. You don't need to worry about giving it an NBTTagCompound when summoned - the tag will be created the first time the player uses it. Unless, of course, you need to store other things in the tag, too?

     

    I'm not sure if there are any hooks that allow you to change the outcome of /give and other commands, but I doubt it. If the player has /give permissions, they can set the NBT to whatever they want.

     

    As for damaging it when destroying a block, check out ItemTool. I'm certain there is an Item (or ItemTool) method that does just that.

  7. I don't think there is any sort of color code -> int mapping anywhere in Minecraft. You either map them out yourself, or you ask your users to use the integer value of the color they want rather than a string code.

  8. You should really properly indent your code - it's very hard to read right now and probably not a small part of why you're having trouble. Really, it makes a difference:

    if (itemstack.stackTagCompound.getInteger("word") == 0)
    itemstack.stackTagCompound = new NBTTagCompound();
    itemstack.stackTagCompound.setInteger("word", 60);
    

    Look at that - the only thing you do if the 'word' value is 0 is completely wipe any data that may exist in the stack's current tag compound...

     

    And then, whether the value was 0 or not, you continue on your merry way to heal the entity.

     

    1. ALWAYS use brackets { } with if statements, even if they are one line. Yeah, some cool kids don't do it, but it can save you some facepalms.

     

    2. NEVER overwrite an existing NBTTagCompound on an ItemStack - you have no idea what it contains, and it is probably important (e.g. enchantment info, etc.)

     

    3. The only time you set a new tag compound on an ItemStack is when it doesn't have one, but if it didn't have one, your check will crash anyway:

    if (itemstack.stackTagCompound. // right here, because you're trying to call a method on NULL
         getInteger("word") == 0)
    

    Better to use:

    if (!itemstack.hasTagCompound()) { // method name may vary based on version
        itemstack.setTagCompound(new NBTTagCompound());
    }
    

     

    4. I don't see anywhere where you decrement the cooldown timer on the stack... so I guess it's single-use? It's better to store the world time at which the stack can be used again anyway, as then you only check when the item is used, not every tick:

    public static final int INTERVAL = 60; // cooldown interval
    
    // when your item is used:
    if (world.getTotalWorldTime() > stack.getTagCompound().getInteger("nextUse")) {
        // yay, enough time has passed to use the item again! now set the next time it will be available
       stack.getTagCompound().setInteger("nextUse", world.getTotalWorldTime() + INTERVAL);
    }
    

    Note: null checks not provided.

  9. FontRender#drawString takes an int parameter for the color, which is a single-value representation of the RGB values.

     

    There are color charts available online, or you can search through Minecraft's code for their chat formatting color codes to find their values.

  10. It's not happening with the method you have chosen, no, but there are methods that filter for you, and in 1.9 there are probably even some that accept a Predicate allowing you to custom filter the results. I don't have Forge / MCP on this computer, so I can't tell you any more specifically than that.

  11. If it's your own Block class, all you need do is override #breakBlock and have it replace itself at that time.

     

    If it's not your own block, then you could probably re-place the block from HarvestDropsEvent, though I don't recall if you have access to the BlockPos or state at that point. There are some other events that deal with blocks that you can look into - use your IDE to browse the events at your disposal.

  12. Second question stands: is there a way to get only the nearest entity that intersects without checking the distance of all of them?

    No, that is literally impossible. You can't know which is the nearest without checking all options, though some methods like #findNearestPlayer and such may make it seem like you don't have to check because you are not making the comparisons in your own code.

  13. You're misunderstanding vectors and aabb: the look vector is normalized, so all values are between -1 and 1. If the player is looking straight up or down, x and z coord of look vec are both zero, so:

    pPos.getX() + look.xCoord*range
    
    which equals: pPos.getX() + 0 * range
    which equals: pPos.getX()
    

    So aabb is between pPos.getX() and... pPos.getX(). A horizontal plane of nothing, basically.

     

    That, however, is not the issue. The issue is that you are adding the player's position to itself. Vectors are additive, so (x, y, z).add(x1, y1, z1) becomes (x + x1, y + y1, z + z1).

     

    Now imagine you are standing at 1000, 60, -500, looking straight west so your look vector is (-1, 0.5, 0) or something like that. Even with a range of 20, the look vector becomes irrelevant compared to the position. Let's take the xCoord for example:

    pPos = 1000

    tPos = 1000 + (1000 + (-1 * range)) = 1980, for example

    aabb checks for entities between x=1000 and x=1980, which is EAST of your position (very very far east), even though you are looking WEST.

     

    Now apply that to all 3 directions; see why you are not getting what you expect?

     

    Solution: don't include pPos in the tPos calculations.

×
×
  • Create New...

Important Information

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