Choonster

Block#isOpaqueCube is called on both the client and server, but you're referencing the client-only class Minecraft in your override of this method. This class doesn't exist on the dedicated server, so it crashes. Instead of calling BlockLeaves#setGraphicsLevel yourself, I recommend you use the graphics level from Blocks.leaves in your override of Block#isOpaqueCube . Either call the same method on Blocks.leaves and return the result or get the value of BlockLeavesBase#field_150121_P (a.k.a. graphicsLevel ) from Blocks.leaves , invert it and then return that.

Forge supports models in JSON, OBJ or B3D format in the baked model system. This is mainly designed to be used for blocks/items, but it can be used for entities as well. JSON models (a format specific to Minecraft) can either be written by hand or created in a program like MrCrayfish's Model Creator. OBJ and B3D models can be created in mainstream 3D modelling programs. Baked models can be animated using the Model Animation System (the net.minecraftforge.client.model.animation package). This page explains the grammar of the Animation State Machine files.

You need to specify every value of every property in the Forge blockstates format, even if that value has no effect on the model. Alternatively, register an IStateMapper for the Block to ignore any properties that don't have an effect on the model. You can create the IStateMapper by creating a StateMap.Builder object, calling StateMap.Builder#ignore for every property you want to ignore and then calling StateMap.Builder#build . You can then register this by calling ModelLoader.setCustomStateMapper in preInit. Ignored properties don't need to be specified in the blockstates JSON (in either format).

Remove the trailing (kotlin from the OP's link and it works: https://github.com/Raven6101/Raven-API/blob/master/src/main/kotlin/raven/api/opengl/vbo/VBO.kt

To change the header, you'll need to override CommandHelp#execute to do exactly the same thing as the super method but use your translation keys instead of the vanilla ones. To get tab completion working for the sub-commands of the admin sub-command, pass the possible command names as the second argument of getListOfStringsMatchingLastWord instead of an empty array when there's a single argument. CommandBase.getListOfStringsMatchingLastWord(String[], String...) is a vararg method, you don't need to explicitly create the String array for the second argument.

I've actually implemented this myself now, I did it slightly differently than I originally suggested (which was mostly off the top of my head). The command itself extends CommandBase and has a field storing an instance of a nested class that extends CommandHandler to manage the sub-commands. It overrides ICommand#execute to call ICommandManager#executeCommand and ICommand#getTabCompletionOptions to call ICommandManager#getTabCompletionOptions , both on the sub-command manager. It overrides ICommand#isUsernameIndex to check if the index is greater than 0 and the first argument is a valid sub-command. It then creates a copy of the arguments array without the first argument and calls ICommand#isUsernameIndex on the sub-command with this new array and the index minus 1. When the sub-command manager is created, it calls ModCommands.registerSubCommands to register the sub-commands. These are just regular commands that return usage text starting with /testmod3 command instead of /command . You can see my implementation here.

Use EntityLivingBase#getItemStackFromSlot .

You need to create an instance of this class to register it as a command, so don't make it abstract. You don't need to override CommandHandler#executeCommand , it should only ever be called from within the same class. Implement ICommand#execute to join the arguments array into a single string and call executeCommand with it. /tetracraft foo bar will execute the /tetracraft command, which will pass foo bar to executeCommand . This will execute the foo sub-command with bar as its argument.

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: