coolAlias

Looks like the Forge documentation needs to be updated, then.

You should be able to attach your Capabilities to any ItemStack, including vanilla, using Forge's `AttachCapabilityEvent<Item>` event.

You need to use Forge's Capabilities system to attach extra data to the Item/ItemStack. For generating random items, take a look at Loot Tables - they are super flexible and can do everything you will need them to do for your system, though they are somewhat complicated to work with.

No, the Capability is for storing which skills the player has and what skill level they are. The actual skill system can be totally separate and simply query the player's Capability when they interact with it. If your skills need to store any information on a per player basis, that should be stored in the player's Capability.

Huh, never thought of doing something like that. Nice. Cheers!

Thanks! I do find it a little odd that the modid needs to be specified in the sounds.json file now - are there any cases where one would want to specify something else? Because you can always fetch sounds from Minecraft or other mods using the registry.

public static SoundEvent SOUND_LEVELUP; // Called from main class during FMLPreInitializationEvent public static void registerSounds() { SOUND_LEVELUP = registerSound(new ResourceLocation(ModInfo.ID, "levelup")); // etc. } private static SoundEvent registerSound(ResourceLocation location) { final SoundEvent sound = new SoundEvent(location).setRegistryName(location); return GameRegistry.register(sound); } During the loading process just before the SoundSystem starts, I receive an error message like the following for every single sound listed in my sounds.json file: File minecraft:sounds/special/levelup.ogg does not exist, cannot add it to event dynamicswordskills:levelup Note how it appears to be searching for the file with the 'minecraft' domain rather than my mod id, even though it shows the correct resource location just after that. I'm using Forge 1.9.4-12.17.0.1976. What am I doing wrong?

One thing I've noticed is you are doing all of your initialization during the FMLInitializationEvent instead of the FMLPreInitializationEvent - in my experience, you should always register your blocks, items, etc. during pre-init.

If I recall correctly, the Container should have a reference to the Inventory, which should have a reference to the TileEntity in use, which should have a reference to the BlockPos. But if that's not the case, then yes, you'd have to resort to a raytrace to fetch the current block, but that's not totally reliable in this case - what if another player or mob interposes itself between the player and the open chest while they are perusing, for example? Container will still be open, but now the MovingObjectPosition will probably contain the mob. Or a player might place blocks between them. Rare, certainly, but it may happen.

java.lang.IllegalArgumentException: Attribute is already registered! [16:00:35] [server thread/INFO] [sTDERR]: [java.lang.Throwable:printStackTrace:-1]: at net.minecraft.entity.ai.attributes.AbstractAttributeMap.registerAttribute(AbstractAttributeMap.java:34) // your code: this.getAttributeMap().registerAttribute(SharedMonsterAttributes.ATTACK_DAMAGE).setBaseValue(0.5D); EntityMob already registers the ATTACK_DAMAGE attribute - you can set the value like you do the others, but you cannot re-register it.

No worries - that's the reason they finally consolidated the event buses, it was a mess keeping track of them. @OP As we've said, you have to check if the DamageSource#getEntity is an EntityPlayer, then cast that entity to EntityPlayer so you can call I believe #addChatMessage to send them a chat - it's been a long time since I've looked at 1.6.4 and the chat methods have changed a lot since then, so you may have to look for it yourself.

The first version you posted should be printing to the console each time a zombie dies. To test if your event handler is working at all, you can put a println at the very beginning of it: @ForgeSubscribe public void onEntityDeath(LivingDeathEvent event) { System.out.println("Entity died: " + event.entity); } If you're not getting any output at all, make sure you actually call that random static init1 method you posted... it'd be simpler just to register directly during one of the FML events. Edit: No, don't use FMLCommonHandler event bus - that's the wrong bus for this event. Here's a tutorial - please read it so we don't have to repeat the same information over and over again.

// during pretty much any of the mod init phases: MinecraftForge.EVENT_BUS.register(new YourEventClass()); A quick Google search will bring up a lot of information on using Forge events that would be cumbersome to reproduce in forum posts.

If you registered the class containing that method to the Forge event bus, yeah, that's the basic premise and should be printing 'Hello!' every time a zombie dies.

LivingDeathEvent, check if entity killed is instanceof EntityZombie and if the source of damage was caused by a player. This works in pretty much every version of Minecraft/Forge since at least 1.6.4.

You need to create and use your own TileEntity class as opposed to using vanilla's TileEntityFurnace in your custom block class.

Don't have an IDE to check, but isn't GameProfile only available on the client side?

It should be @SubscribeEvent, not @EventHandler. Might help you to check out a tutorial on using Forge Events.

Congratulations, you got a java.lang.StackOverflowError! That means something in your code is causing the stack heap to overflow, i.e. you have allocated more memory than your program has available. See StackOverflow on StackOverflow. Show your event code.

No. ITileEntityProvider sucks, maybe not as much as BlockContainer , but it still sucks. Simply override hasTileEntity and createTileEntity from the Block class. Ah, my mistake - for some reason I thought ITileEntityProvider was responsible for those two methods. What's the point of that interface, then?

Implementing ITileEntityProvider instead of extending BlockContainer is the recommended method of adding a TileEntity to your block. Having the block teleport any entity that walks on it sounds like a very griefer-friendly mechanic... click block above lava, destroy block, set teleporter block coordinates, and sit back and watch everyone and everything to fall into the lava... You may want to consider requiring players at least to activate the teleporter themselves, rather than automatically when touching it.

How are you specifying which texture to use? Block metadata, TileEntity field, something else?

What is the Item going to do with the Block coordinates? Is the Block going to be responsible for doing anything? The answers to those two questions will determine whether you need a TileEntity or not, at least with respect to this particular interaction. Note that Blocks by themselves are incapable of storing NBT data - additional data is typically stored in a TileEntity, though NBT data such as vanilla lockable containers are probably stored somewhere else.

I'm pretty sure #onBlockClicked is only for left click and #onBlockActivated is only for right click. Easiest way to find out for sure is to put a System.out in each of those methods and test it Note also that some types of Items may not pass the click on to the block under certain circumstances.

The block IS updated, but the client doesn't know it yet, so you need to notify the client(s). The way that is done in 1.7.10 is via World#markBlockForUpdate(x, y, z).