Choonster

Basically I want the function to allow only blocks or items within my mod. I know how to allow items in... but I'm completely lost on how you allow blocks to be placed inside of it...Any ideas? When in inventories, Block s are just regular Item s (most of which extend ItemBlock or a subclass). Use Block.getBlockFromItem and Item.getItemFromBlock to convert between the Block and ItemBlock form of a block. Pay attention to the return values, not every Item has a Block and not every Block has an ItemBlock . Some blocks (e.g. Sugar Canes, Cakes, Beds) use a separate Item that doesn't extend ItemBlock and won't work with these methods, other blocks (e.g. Air) don't have any item form at all.

Likely because your field is a Map<String, ModelResourceLocation> (i.e. String keys). Use a Map<Pair<String, String>, ModelResourceLocation> if you have Pair<String, String> keys. Something was null in ModelBakery.registerItemVariants (line 765), I suspect it was one of the ResourceLocation s you passed to it. Set a breakpoint on that line with a condition that any of the values that have a field accessed or method called on them are null (e.g. value1 == null || value2 == null ) and run Minecraft in debug mode. When it hits the breakpoint, look at what's null . It means you can't create an instance of Pair , you need to create an instance of a concrete (non-abstract) class that extends it, i.e. ImmutablePair or MutablePair . You don't need to modify these pair keys, so use an immutable pair (either call Pair.of or manually instantiate ImmutablePair ).

Upload the FML log (logs/fml-client-latest.log) to Gist and link it here. This will tell us what's going wrong. Don't put your models and other assets in the minecraft resource domain, use dbound:modelname in your blockstates file so it loads models from your resource domain.

When asking for help with a crash, always include the crash report. Don't use the toString output as the key, use the Pair itself; though make sure the Pair class you're using overrides Object#hashCode so two Pair objects with the same contents are treated as the same key for hash maps. org.apache.commons.lang3.tuple.Pair supports this, but I'm not sure which class you're using.

The game would look for the other pulling models (they're not just textures) if you called ModelLoader.registerItemVariants (or Registers.registerItemVariants if that's correctly coded) with the model locations directly. Your caching of model locations in ModelJsonReference.getBowPullingTextures is broken because it ignores the state argument after the first call and always returns the location of the first state for the specified type . If you want to cache the locations, you need to use a data structure that includes the type and state in the key. This could be something like a map with tuple/pair keys ( cache.put(new Pair(type, state), location) ) or nested maps ( cache.get(type).put(state, location) ), you'll have to figure out which works best for your situation.

ISmartItemModel is probably what you want. There are lots of threads here that mention it.

Do you actually have a model at tetracraft:models/item/ballistic_bow_standby.json? ModeLoader only tries to load the variant from the blockstates JSON when it can't find the item model. Your pulling textures aren't working because the map used by ModelJsonReference.getBowPullingTextures ignores the state argument, only using type as the key. Side note: Hashtable is very old and shouldn't be used (see its doc comment for more details). Use a HashMap if you don't need thread safety (Minecraft is mostly single-threaded, so thread safety isn't required except for IMessageHandler s).

I didn't ask for a crash report and that crash report doesn't have Forge in it, so we can't help you with it. Talk to the person who repackaged everything as "fuckYouSkid". I asked for the FML log, which you can find in the logs folder of Minecraft's game directory (.minecraft by default). It will be named fml-client-latest.log. Upload that log to Gist and link it here.

You installed a coremod built for 1.7.10 or earlier (TooManyItems) but you're running Minecraft 1.8.9. Mods (especially coremods) only work with specific versions of Minecraft.

ModelBakery.registerItemVariants expects ResourceLocation s/ ModelResourceLocation s with the domain, model name and variant specified. It doesn't expect the whole model path. If you use a ResourceLocation , the variant will default to inventory . Instead of passing tetracraft:models/item/ballistic_bow_pulling_0#inventory , just pass tetracraft:ballistic_bow_pulling_0#inventory .

Have you tried opening a copy of your world in 1.8.9 to see if anything breaks? Some 1.8 mods may work in 1.8.9.

Check if the hurt entity is a player. If it is, cast it to EntityPlayer and then check if it's wearing your armour. If you want the effect to apply to any living entity wearing the armour rather than just players, skip the player check and use EntityLivingBase#getEquipmentInSlot to check the armour.

Where are you getting player from? You must get all data from the event itself. LivingHurtEvent#entityLiving is the entity that was hurt. LivingHurtEvent#source is the DamageSource that caused the damage. DamageSource#getEntity will get the Entity that caused the damage, if any (this will be null if the damage wasn't caused by an entity).

Read the tutorial properly, event handler methods can only have a single argument (the event that they handle).

I'm trying to test the new capability system by adding a pig spawner capability that allows items to spawn a pig when right clicked on a block. There are two types of spawner: finite (has charges that are used up when spawning pigs, pigs can't be spawned if there aren't any charges left) and infinite (can always spawn pigs). I've got the actual spawning of pigs working without issue, but now I'm trying to sync the remaining charges of finite pig spawners to the client so that they can be used in rendering (e.g. use the durability/damage bar to display the remaining charge percentage). On the integrated server, the charges seem to be synced to the client thread automatically (even though the client and server have their own ItemStack s and IPigSpawner instances). On the dedicated server, the charges aren't synced to the client. Even when I send a packet to update the value from PlayerInteractEvent (where I handle the spawning), it seems that the slot is overwritten by S2FPacketSetSlot afterwards. Has anyone managed to get something like this working? Logs (everything marked with PIG_SPAWNER is from pig spawner code) Code: Interfaces, Implementations and Capability, Message

Use OreDictionary.WILDCARD_VALUE as the metadata value of a recipe ingredient to ignore metadata.

Loot++ is failing to read its config file and one of your mods has an invalid sounds.json file (the log doesn't say which), but it doesn't look like those are actually stopping the game from working. Can you upload your full FML log (logs/fml-client-latest.log) to Gist and link it here? In future, please use [nobbc]

Specifying the dependency like that only works if the mod is accessible through a Maven/Ivy repository, which you need to add in the repositories block of build.gradle. To my knowledge Baubles isn't hosted in a public Maven repository, but you can access CurseForge downloads through Ivy. Unfortunately it looks like deobfCompile doesn't work with Ivy or local dependencies (the linked issue also shows how to access CurseForge downloads through Ivy). I think your best bet at this point is to download and compile Baubles yourself or deobfuscate it with BON2. Baubles 1.1.3.0 is built for 1.8.9 and may or may not work in 1.8.

For 1.8 and earlier, you can only use deobfuscated/dev builds of mods in the development environment. ForgeGradle can deobfuscate a mod if you add it as a deobfCompile or deobfProvided dependency (see the MDK's build.gradle for examples). In 1.8.9, FML can deobfuscate mods at runtime; allowing you to use regular mods in the development environment.

Look at the various blocks that use PropertyDirection or extend BlockDirectional . Most of them override Block#onBlockPlaced to set their facing property to the opposite of the player's facing (so it faces the player).

FML only calls @EventHandler methods in your @Mod class. Remove the annotation and argument from Recipes.init (neither are needed) and call it from your @Mod class. In future, please use Gist or Pastebin to post logs/crash reports (if applicable) and code with syntax highlighting. To get syntax highlighting on Gist, give each file the appropriate extension (.java for Java code). To get syntax highlighting on Pastebin, select the language from the dropdown at the bottom of the page. It's much easier to read code with proper formatting and syntax highlighting.

The src download was renamed to MDK (Mod Development Kit) because it hasn't actually included any source code for a while. This tutorial explains how to set up a development workspace for modern versions of Forge. Once you've set up your workspace and IDE project, you can view the source of Minecraft and Forge classes in your IDE.

You need to refresh your project from IDEA's Gradle window after running setupDecompWorkspace for a new version.

Add it as a dependency through Gradle instead of your IDE, ForgeGradle will add it as a referenced library in your IDE project. These links in the MDK's build.gradle script explain Gradle's dependency system.

Container#inventoryItemStacks is just a cache that stores a copy of the container's contents. To modify the inventory itself you need to iterate through the container's slots ( Container#inventorySlots ), copy the stack in each slot ( Slot#getStack , ItemStack#copy ), modify the copy and then replace the slot's stack with the copy ( Slot#putStack ). Don't directly modify the stack returned from Slot#getStack as the slot may be backed by an IItemHandler , which specifically forbids modifying the stack returned from IItemHandler#getStackInSlot . I don't think that documentation is accurate, since the vanilla Skull item uses NBT to store the skull owner (for player skulls) and can be stacked. If you're modifying the NBT of items not added by your mod, make sure you include your mod ID in the tag names so you don't overwrite other people's data. Storing the infusion count could be a potential use-case for the new capability system.