Choonster

It's probably easiest to extend CommandHandler and implement ICommand , since CommandHandler provides a lot more functionality for you than CommandBase does (most of the useful methods from CommandBase are static, so you can use them from any implementation of ICommand ). Register this class like a normal command, then register your sub-commands with this class.

You need to create an IResourcePack for that directory (using either FolderResourcePack or your own implementation) and add it to the Minecraft#defaultResourcePacks list. This field is private, so you'll need to use reflection to access it.

The existing command system has no concept of sub-commands, but you should be able to create an ICommand that implements ICommandManager by wrapping your own implementation of CommandHandler . This should allow you to register sub-commands and re-use the existing permissions system.

You need to delay the removal of the block and its TileEntity until after Block#getDrops is called, look at Forge's patch to the BlockFlowerPot class to see how it does this.

The class is definitely in the JAR at the right location, I can view it in a decompiler and run the same mod JAR in a fresh Forge 1.9- 12.16.0.1864-1.9 MDK or release client without crashing.

Your sounds.json file was already valid, you don't want your gun sounds to play as if they records. What you have now should still work, though. Item#onEntitySwing will be called on both the client and server. If the shooting entity is a player, pass it to World#playSound as the first argument. The client-side call will play the sound for the shooting player and the server side call will send a packet to every other nearby player to play the sound for them. If the shooting entity isn't a player, pass null to World#playSound as the first argument. The client-side call will do nothing and the server side call will send a packet to all nearby players to play the sound for them. Either way, all nearby players will hear the sound. You can see a working example of this here.

It's not really that complicated. If the code that plays the sound is only running server side, pass null as the EntityPlayer argument of World#playSound and the sound effect packet will be sent to all nearby players. If the code that plays the sound is running on both sides, pass the appropriate player as the EntityPlayer argument of World#playSound . The server will send the sound effect packet to all nearby players except the specified one and the player's client will play the sound itself.

My mod shadows the Apache HTTP Client Fluent API (buildscript is here) and runs a basic test with it in postInit (see here). This works fine in my mod's development environment and the release client, but for some reason it crashes with a ClassNotFoundException for a Fluent API class in the Forge development environment (where I was testing some stuff in preparation for a PR). The class is definitely present in my mod's JAR. You can see the FML log from the Forge development environment here. Does anyone know why this is happening?

The EAQ has an entry on this particular crash, so I replied with it. The solution is to lower your view distance. I'm not sure what PMs have to do with anything.

You need to create a ResourceLocation (not a ModelResourceLocation , which is client-only and only used for models) with your mod ID as the domain and the JSON sound event's name (the keys of the top-level object in sounds.json) as the path. You then need to create a SoundEvent with this ResourceLocation , set the ResourceLocation as its registry name (with the setRegistryName method inherited from IForgeRegistryEntry ) and register it (with the single-argument GameRegistry.register method). sounds.json is still needed to specify the sound files for each SoundEvent . You can see how I create and register a SoundEvent here and my sounds.json file here. To play a sound, use one of the overloads of World#playSound with an EntityPlayer as the first argument. On the server side, these will send a packet to every nearby player except the first argument (if it's not null ) to play the sound on their clients. On the client side, these will simply play the sound if the first argument is the client player. Edit: The packet is only sent to nearby players, not all players.

Sorry, the new name is TextComponentString , not ChatComponentString .

If the TNT wasn't ignited by an entity, just pass null . If you look at the doc comment or usages of EntityTNTPrimed#getTntPlacedBy (which returns the EntityLivingBase passed to the constructor), you'll see that null is a valid and expected return value.

Every ChatComponentX class was renamed to TextComponentX , ChatComponentText was renamed to TextComponentString . Edit: TextComponentString , not ChatComponentString .

It looks like another mod is sending an IMC (Inter-Mod Comms) message to Thaumcraft with an ItemStack that has a null Item . This could be a message telling Thaumcraft about a crop that can be harvested by Golems or about a crop that shouldn't be affected by the Lamp of Growth. The crash report doesn't say which mod sent the message, so you'll need to figure it out yourself. The most likely culprits are Thaumcraft addons that add crops of some sort.

From the EAQ:

The property should be registered once in preInit, not every time the EntityTerrakon constructor is called. As I said before, you should include your mod ID in your property name ResourceLocation to avoid conflicts with other mods defining similar properties.

You should include your mod ID in your property name ResourceLocation to avoid conflicts with other mods defining similar properties. I already explained how to register your property:

From the doc comment of WorldEvent :

EntityTamed is actually testing whether the entity is burning rather than whether it's tamed. You need to check whether the entity is tameable ( entity instanceof EntityTameable ) and whether it's tamed ( ((EntityTameable) entity).isTamed() ) and then compare that to the expected result. Your ballisticBow model is using pull instead of tetracraft:pull for the ballisticBow_pulling_2 override model's condition. You seem to have two copies of your main class and registration/initialisation classes, one in the novaviper.tetracraft.main package and one in the novaviper.tetracraft.common.inti package (should that be init rather than inti ?). Delete the outdated copy. I'm not too sure why it's not dropping your item.

No. It looks like the current version of the harvest tool system was added in 1.7.2; but there was a slightly different version of the same system in place before that.

This has also been discussed on GitHub.

Did you create and register the Serializer ? Look at the pig loot table to see how it uses the on_fire property to determine whether the meat should be cooked.

You need to implement EntityProperty , look at EntityOnFire for an example.

Then the load time is unrelated to the loading screen. Sky Factory does have approximately 118 mods, whereas Tekkit has approximately 62 mods. It's not that surprising that loading almost twice as many mods will take longer.

It looks like you'll need to create an EntityProperty to test whether the entity has been tamed. You'll also need to create its EntityProperty.Serializer and register an instance of it with EntityPropertyManager.registerProperty . In your loot table, use the entity_properties condition with your property.