coolAlias

Hi, You can get the player's position from the player object: player.posX, player.posY, player.posZ; many methods have an EntityPlayer for you to use, and most block methods have int x/y/z coordinates in the parameters. For documentation, I suggest you look at the Minecraft code itself, or perhaps find some beginning tutorials online. Good luck, y lo siento para explicarlo en inglés - but that's all you're going to get here on the forums. Buena suerte, coolAlias

The reason he linked you a flower tutorial is because flower generation is very pertinent to your needs. You can use WorldGenFlowers directly if you want (mushrooms do this), or you can create your own class that extends WorldGenerator. In either case, you can use the DecorateBiomeEvents to generate using your world generator of choice: // EVENT_BUS event @SubscribeEvent public void onDecorate(DecorateBiomeEvent.Post event) { // determine coordinates and generate } You may want to take a look here to see some difficulties you may encounter (the infamous "already decorating!").

I'm not sure I can make it much clearer than that... you need both methods - onUsingTick to fire repeatedly while the item is in use, and onItemRightClick to prevent spamming right click from being faster than your onUsingTick rate of fire. And please don't extend ItemSword for a gun item - that just doesn't make any sense.

World#getCurrentDate() gives you a Calendar object, which you can use to get the actual time.

No, it is in addition to the onUsingTick method. @Chimera ... sorry, but what the heck are you doing in that code?! For one, never use local variables in Item classes; two, 'this' is already the item rifle that is updating, which you already check that it is held by the entity, so there is no reason to get the held item and check it again; and third, why would you need a packet to spawn the entity when the update method is run on both sides? I realize you are trying to help, but that code... no.

Here is a good introduction. You will need to override the onItemRightClick method, verify the ItemStack has a non-null tag compound and add one if necessary, then use that for your variable. // inside the onItemRightClick method with an ItemStack stack parameter // verify tag compound: if (!stack.hasTagCompound()) { // didn't have one, so make a new one: stack.setTagCompound(new NBTTagCompound()); } // now you can check the world time vs. the time stored in the tag // if no time is stored, that's okay - it will return zero if (world.getWorldTime() > stack.getTagCompound().getLong("lastShotTime")) { // set item in use } else { // 'click', you can't fire yet! }

That will cause the item to refresh its icon, giving it a weird visual effect. @OP The best way, in my opinion, is to store the counter / last-time-shot directly in your item's NBT. Check your NBT-based right-click cooldown / shot-time before allowing the player to set the item in use upon right click, and be sure to decrement the cooldown in your item's onUpdate method if that's the route you choose. Using world time would be easier in this case: upon setting the item in use, set a long in the NBT for current world time + number of ticks you want to stall, and you don't have to worry about updating anything, as the world time does the counting for you. You could also do what TGG suggested, but I personally prefer to keep fields and methods compartmentalized within the object that requires them - for one, it makes it much easier for me to debug, since all the code is in one place.

EDIT: Er, you edited your post, but this was my response to your earlier response, which unfortunately I didn't quote :\ I think you may have misunderstood - the whole point is that it IS checking multiple AIs. The "categories" to which you refer ARE the bits, so swimming, which uses bit 4, cannot execute when any of the tasks using bit 5 (which is bits 4 and 1) are executing. It's a means of excluding multiple incompatible activities with a single and simple check, rather than checking for all different possibilities manually. All activities with bit 1 are mutually exclusive with each other, as well as all tasks returning 3, 5, 7, etc. (all containing bit 1), which makes sense because those all involve moving somewhere. It wouldn't make sense for the AI to try and move two different places at once, but it's okay to swim and move, since swimming is just moving up to the surface, and bit 2 is also compatible with any of those, since it's simply looking at some nearby entity. I would argue that this system is actually pretty slick and efficient, as well as highly versatile.

This is an interesting discussion, as always when jabelar asks a question Bitwise AND allows each AI task to have multiple categories, actually, meaning that as long as none of the categories overlap, then the tasks can run simultaneously. Suppose a task returns bits 1+2, another 1+4, and another 4+8. Task one can run concurrently with task three, but task two cannot run when either task one or task three are active - it can only run in complete isolation, in this example. I'm sure you know how bitwise AND works, but to sum up, any bits that are in common between the two variables will be set to 1, whereas bits that differ are set to 0. (3 & 5) equals 1 [bit 1 is common to both], whereas (3 & equals zero [no common bits].

The only time your code says "change texture" is in the onCreated method - it's not going to change the texture ever again unless you tell it to somehow. Also, using "public int kanokaLoc = 6;" as the icon index is going to result in every one of your items having the same texture; every time you change that value, it changes the value for all of your items. Only use the NBT for the index, not a class field.

Did you register your packet in the PacketPipeline? public void initialise() { this.channels = NetworkRegistry.INSTANCE.newChannel(ModInfo.CHANNEL, this); registerPacket(YourPacket.class); // register all packets here }

Or better yet, don't extend ItemSword. You're making a rifle, not a sword, it doesn't make any sense to extend ItemSword. You should be extending Item.

Now that you've done all that work, have you seen the wiki Netty Packet Handling code? It's quite nice and easy to use. I'm impressed you coded your own, though

The held position is caused because you set your EnumAction to .block; change it to .none and your gun position will not change.

If you remove "super.onUpdate()", you must replace it with "super.onEntityUpdate()" so you still get the benefit of the Entity#onEntityUpdate() code; luckily, this is possible because Entity#onUpdate() just calls #onEntityUpdate(), meaning you can bypass EntityArrow's onUpdate() method in this way while still calling a super method. "shootingEntity", "canBePickedUp", and "arrowShake" are all public fields of EntityArrow - you do not need to add them again to your class, and doing so actually deprives you of the benefits of inheritance, since you now have to do all the work on those three fields yourself, rather than letting EntityArrow do it for you, not to mention giving them the exact same name is a potential cause of confusion (e.g. this.shootingEntity and super.shootingEntity are NOT the same!).

Are you sure? I'm pretty certain that ItemStack NBT is automatically synced to the client, as I've used NBT to determine item icon before without doing any such thing. Never even heard of that method, to be honest... You can do it however you like, whether individual IIcon fields for each icon or together in an array, but however you do it, you need to register all of them. It's just like metadata in that way, the only difference is you are now using NBT instead of metadata to determine which icon to return.

You can still do quite a lot to change the fields of vanilla blocks without reassigning them: // change texture name: Blocks.acacia_stairs.setBlockTextureName("modid:new_texture_name"); // set new hardness: block.setHardness(10.0F); // etc. lots of public setter methods are available

Ok. Well, the Block list no longer exists as it was, but it's much easier since you can access the blocks directly using "Blocks.{block_name}". I suppose you could say that "Blocks" IS "blocksList", just not in array form.

If you simply want to change the textures, why not create a Resource Pack like all other texture pack makers?

1. Always start your own topic, especially if the one you reply to is old like this one. 2. I would only remove the super.onUpdate() if you really know what you are doing 3. Use 'player.getCommandSenderName()' 4. Start your own topic if you still need help

Rendering is client side, so Minecraft.getMinecraft().thePlayer is an acceptable way to get the player, though you may need to check if it's not null (see if you crash or not ) Rather than getting Minecraft every render tick, you can set it during your render tick listener class constructor (though you should only listen to client-side events in this class)

In 1.7.2, you don't add sounds or register them, you use a sounds.json file located next to your 'sounds' folder in your assets directory. It should look something like this: The first " " is the String you will use to refer to your sound in the mod, so when you play the sound, it would be "yourmodid:sound_name". The category "player", "ambient", etc., is the volume control option that affects the volume of your sound in game. You can place your sounds in subdirectories like I did ("sword", "special", etc.), or just have them all in the base sounds directory.

Yes. First, use the RenderTick so that your player can change direction smoothly, then use the player.rotationYaw/Pitch, NOT the camera yaw/pitch. The trick here is you don't actually need to change the camera, you merely need to change the player's rotation - change the direction the player faces, and the camera will be where you want it Finally, I would suggest calculating the difference from the player's current yaw/pitch to the new yaw/pitch, and only adding part of that at a time to avoid the player's view changing suddenly - it can be quite a jarring experience.

^^ Exactly what Sequituri said. The method I posted is the 1.7.2 version; since I have not seen anywhere that you specify for which version you are coding, I assume you are coding for 1.7.2. If that's not the case, you should either say so in your topic title or first post, and learn to use your IDE and Java to find what the method might be called in whatever version you happen to be using.

Not sure what you meant by that, but he had "armor.getItem()" in the condition, which was correct... @OP The problem is you are checking for the enchantment level on the wrong ItemStack - you want to check the level on the ItemStack that is actually worn, not on a new ItemStack. // this will always return zero, because a new ItemStack will not have any enchantments! // not to mention the new stack has absolutely nothing to do with the stack you want to check... int j = EnchantmentHelper.getEnchantmentLevel(MainClass.speedBoost.effectId, new ItemStack(PupletItems.bootsPuplet)); // this will get the enchantment level of the armor (boots) worn: int j = EnchantmentHelper.getEnchantmentLevel(MainClass.speedBoost.effectId, armor);