coolAlias

Keep in mind that many mods may add extended properties even to your custom entities; my Zelda mod, for example, adds some extended properties to all entities that extend EntityLivingBase, which obviously also includes any modded entities that extend that class. Same goes for any other mods that do something similar, or to the innumerable mods (including my own) that add extended properties to EntityPlayer. I wouldn't ever assume that my properties are the only ones being added, unless you are sure that people will not be playing with any other mods installed

I did that to prevent possible conflicts; imagine if everyone is adding custom properties, chances are probably pretty good that there will be some overlap in the NBT tags people want to use, especially if people are not careful to use fairly unique names. By storing all of my data in a new tag, I only have to add a single new key to the original player NBT data, and I can do so with a pretty much guaranteed to be unique key. Otherwise, no, there is no particular reason to do that

If you need the data on the client, you must handle it yourself.

To proffer an explanation of your "all doors lock/unlock together" dilemma: The reason your doors all lock and unlock together is because Blocks and Items are all declared as "static", so there is only technically ONE single block (or item!) of any type in all of existence; what this means is that any class variables you use, such as "locked", even if you don't declare it as static, it is still, in a way, static, in that there is only one block instance to use that variable with. In short, NEVER use your Block or Item classes to store any data that needs to change on a unique basis; instead, use metadata (stored individually per block in the world), TileEntity (much more versatile), or, for Items, the NBT tag of the containing ItemStack.

I added it and it wasn't working.. I should have specified, that code is for harvesting blocks, as in blocks you break with your sword will not drop items (except for webs). If your item is not an ItemSword, it will still be able to break blocks in Creative Mode, but even the vanilla swords can break some blocks in survival. Why don't you just extend ItemSword and make your life easier?

Dude, just because I don't know where this is supposed to go doesn't mean I don't know simple java. This has nothing to do with basic java. I deals with minecraft which is why I'm here. However, having a good grasp of fundamental Java would allow you to quickly solve this Minecraft-related problem, because all you need is the enchantment level (an integer), which you now know how to retrieve thanks to diesieben07, and basic Java to relate that level to the potion duration or amplifier (both also integers). I think most people on these forums are more than happy to give advice about Minecraft-related questions, such as "how do I get the level of an enchantment?", but how you use that level is entirely up to you and your skills with Java.

If your Item extends ItemSword, it should not harvest blocks anyway (except for webs), but if it doesn't extend ItemSword, you need to override canHarvestBlock, which still has the obfuscated name in 1.7.2. From ItemSword: public boolean func_150897_b(Block p_150897_1_) { return p_150897_1_ == Blocks.web; } Just add that to your Item class and bam, done, no need for events.

What they probably meant is that if you intend to cancel the event, you can only do so in Pre, but if you just want to add some extra rendering on top of the normal player rendering, to do it in Post after the rest of the player renders, though there is nothing stopping you from doing that rendering in Pre as well, and, indeed, if you are canceling the Pre then the Post won't get called, meaning in such a case you must render in Pre.

If you can't figure out how to override a class method (e.g. onArmorTick), then I suggest you first learn Java. Once you've got that down and understand how to override class methods, then the following may interest you: In the latest version of Forge (10.12.1.1060), there is a new ItemStack sensitive version of getAttributeModifiers, so you can check for enchantments from there and have it return a multimap with a speed attribute modifier, though if you do it this way the player would also get the speed boost when just holding the boots. If that doesn't fit your idea of what the boots should do, then you should use the onArmorTick method as mentioned above.

If you're not using 10.12.1.1060, try updating and see if that resolves the issue. Found this in the release notes: - Fixed player data being deleted by login/startup race condition May or may not be the issue, but it's worth a try.

Thanks, that's how I've understood it as well. Well, that clears that up, and congrats on reaching 1000!

That was the entire implementation, aside from consuming the bullet and spawning the entity; what more do you need? It's a method in the Item class, just put it in your rifle class and add what you need. 20 ticks is roughly one second.

Interesting. I always add the at client-side-only in my render classes and such, and occasionally use it for methods that I only need on the client - such as ones that are interacting with keyboard or mouse - as a way to make sure I'm not accidentally calling it on the wrong side (by crashing the game, which I suppose would happen anyway in some cases ). Even if it's not intended for use by modders, I find it useful in these situations... but it sounds like you are saying there is absolutely no time that it should ever be used. I haven't noticed any problems resulting from its judicious use, so I'm curious what sorts of trouble it could cause that I should be aware of, aside from the obvious crashing on the server when incorrectly accessing such a method / field.

Never use @SideOnly(Side.SERVER). !world.isRemote is exactly what you need, and if you are only calling your method after checking that the world is not remote, it will only be called on the server. If you use @SideOnly(Side.SERVER), your method will not work.

Don't use "EntityRegistry.findGlobalUniqueEntityId()" with registerModEntity - that's completely different. What I do is create a local "int entityIndex = 0" and use that as "entityIndex++" for the id of each mod entity. int entityIndex = 0; EntityRegistry.registerModEntity(EntityMyItem.class, "MyItem", entityIndex++, this, 64, 10, true); EntityRegistry.registerModEntity(EntityMySecondItem.class, "MySecondItem", entityIndex++, this, 64, 10, true);

As TGG mentioned, you need to subscribe to the SoundLoadEvent to add your custom sounds to the sound manager. Sounds are loaded only on the client side, so make sure you register the event in your client proxy so you don't crash on the server with class not found exception. If you don't know how to use / register events, TGG gave you the code already, or you could look up Forge Events on the wiki or Minecraft Forums. Create an .ogg file for your sound (preferably not too long) and place it in your assets/modid/sound/ directory. Follow previous advice to play it. If that doesn't help you figure out to start, then I recommend starting with Java

Did you not find any in the github repository? There are lots of examples in there. Or look at the RenderSnowball code, or any of the other vanilla Minecraft projectile rendering classes. Are those not enough examples?

It's 10.12.1.1060, and you have to change the ForgeGradle:1.1-SNAPSHOT from 1.1 to 1.2

Hi, If you are not relying on metadata for explosion resistance, then that is pretty strange. Perhaps put a println in the onBlockExploded method to see if it is actually getting blown up, or perhaps it is trying to place itself on a block that gets destroyed, and is affected (for example if you require it to be on a solid block and not on air). Tough to say without seeing the block and event code, and tile entity, too, if it has anything to do with the explosion resistance. If you ARE using metadata for explosion resistance, read on:

Are you sure you can cast your currentAttackId to a byte without overflowing the stack? If your id is an int with a possible value greater than 255, then you should leave it as an int. ByteBuf can write integers just as well as bytes, as you did with the entityId.

You will have to use the Tessellator to draw it, like vanilla does when rendering an IIcon texture. Another option is to use a model and let the model renderer do the work for you. While the 1.7.2 code for my mod isn't up yet (dang GitHub), the rendering code hasn't changed all that much from 1.6.4, and I've got plenty of projectile entities that you could look at for inspiration: https://github.com/coolAlias/ZeldaSwordSkills Make sure you're not using "static" for things in your render or entity. That's the best advice I can give without seeing any code.

You'll have to be more specific; do you mean adding new types of enchantments, adding enchantments to items during crafting, or in recipes, or what?

Description packets are only sent when the block is scheduled for an update, which happens each time the chunk containing the block loads, and then never again unless you schedule a tick, which, as has been mentioned, is not the best method if you need to do so every tick. If you just need to keep the energy stored in sync, use the ICrafting from your container, as was mentioned earlier. That's exactly what it is for.

Indeed, I highly recommend NOT to ever use Minecraft.getMinecraft(). The way to play sounds is either through the World object, or with the EntityPlayer#playSound. When using world.playSoundAtEntity, for example, you must do so on the server side and it will play a sound for all to hear; using player.playSound, however, will only play a sound for that player and must be used on the client side - it will not crash on the server, but it won't play a sound, either. EDIT: Actually, it looks like EntityPlayer.playSound plays a sound for everyone else, but not for the player... I could swear I've used it before and had it play sounds for me, but maybe not. Anyway, use the World methods

Use RenderSnowball. See here for more information.