josephcsible

If hasCapability would return false for a given capability and facing, must getCapability return null for the same capability and facing, or may it throw an exception? Conversely, may you call getCapability and test for null instead of calling hasCapability?

Ah, conditions for recipes were exactly what I was looking for. Thanks! (For anyone else who reads this, note that it's minecraft:item_exists, not forge:item_exists).

I still feel like I'm missing something. How can I make a JSON recipe either work or not work depending on a configuration setting?

I just thought of something: even if I do still register the items, how would I then go about disabling the crafting recipe? Would I have to basically hardcode what CraftTweaker does, or is there an easier way?

Doesn't registering the item mean that I have to register a model for it too?

The reason I wanted disabling them to not register them is to make the mod more RAM-friendly. If I register them and just hide them, there's no real point.

I want some of my mod's items to be disableable in the config file, so that if the player or pack maker doesn't want them, they don't have to be loaded into memory. When I disable items this way, I get this error for recipes for the disabled items: com.google.gson.JsonSyntaxException: Unknown item 'mymod:myitem' at net.minecraftforge.common.crafting.CraftingHelper.getItemStack(CraftingHelper.java:211) ~[CraftingHelper.class:?] at net.minecraftforge.common.crafting.CraftingHelper.lambda$init$14(CraftingHelper.java:516) ~[CraftingHelper.class:?] at net.minecraftforge.common.crafting.CraftingHelper.getRecipe(CraftingHelper.java:408) ~[CraftingHelper.class:?] at net.minecraftforge.common.crafting.CraftingHelper.lambda$loadRecipes$22(CraftingHelper.java:711) ~[CraftingHelper.class:?] The game still works fine, and all of the recipes are there except for the ones that make/use the disabled item, so the only problem that this is causing is the log spam. Is there a way to not load crafting recipes for some items in 1.12? In 1.11 and prior versions, I'm used to being able to conditionally add the recipe via Java, but I don't know of an equivalent for that in JSON.

This doesn't sound right to me. Isn't the whole point of virtual methods that you don't have to worry about this?

Done, https://github.com/MinecraftForge/MinecraftForge/issues/4397

Given a mod that adds a new type of wood, what's the best way to let its planks be used to repair wooden tools in an anvil? Looking at the code, I see it's calling getIsRepairable on the tool, which in turn calls OreDictionary.itemMatches with Blocks.PLANKS. (IMO, this is somewhat misleadingly named since it does a straight item/metadata comparison and not an ore dictionary comparison. If it did an ore dictionary comparison, this would be trivial.) The only solution I see is to subscribe to AnvilUpdateEvent, and then reimplement almost all of updateRepairOutput() in it. Is this what I have to do, or is there a better way to do this?

While testing one of my mods alongside some others, I got this crash that I can't figure out: Important part: java.lang.ClassCastException: java.lang.reflect.Field cannot be cast to java.lang.Byte at net.minecraft.entity.EntityLivingBase.func_184587_cr(EntityLivingBase.java:2641) Here's what I figured out myself: First, here's net.minecraft.entity.EntityLivingBase.func_184587_cr(EntityLivingBase.java:2641): public boolean isHandActive() { return (((Byte)this.dataManager.get(HAND_STATES)).byteValue() & 1) > 0; } HAND_STATES is declared as a DataParameter<Byte>, so all through this next part, T is Byte. Next, here's this.dataManager.get: public <T> T get(DataParameter<T> key) { return (T)this.getEntry(key).getValue(); } And here's getValue: public T getValue() { return this.value; } And finally, here's value: private T value; I don't get how a Field could have gotten as far as it did. "value" is declared as type T, as are the return values of getValue() and get(). Even get() itself has an explicit cast to T. Where did the Field come from here, and why didn't it crash anywhere prior to isHandActive where it must have been shoehorned into an inappropriate variable?

1.7.10 is more than three years old now. Why can't you just write mods for newer versions?

That seems to be the default location for it in the MDK, though. (And when you download a fresh one and do ./gradlew setupDecompWorkspace eclipse, it will work fine there. It just stops working if you try to rebuild the stuff that .gitignore excludes.)

Realms only supports the latest release of Minecraft, and Forge doesn't support 1.12 yet. Until it does (which will be soon, but please don't bug for an ETA), you can't use Forge and Realms together.

Here's the important part of your error: java.lang.IllegalArgumentException: Malformed \uxxxx encoding. at java.util.Properties.loadConvert(Properties.java:574) at java.util.Properties.load0(Properties.java:390) at java.util.Properties.load(Properties.java:341) at batty.ui.BattyUI.retrieveRuntimeOptions(BattyUI.java:576) Batty's Coordinates PLUS Mod is crashing your game due to a syntax error in your BatMod.runtime file, specifically an invalid Unicode escape sequence (supposed to be "\u" followed by 4 hexadecimal digits). If you don't know what that means or can't find it, upload the contents of that entire file.

If I have a mod with an ID that isn't all lowercase, when I port it to 1.11 (and have to change its mod ID to be all lowercase), how do I keep old worlds from losing all existed modded blocks? At https://github.com/MinecraftForge/MinecraftForge/pull/3122#issuecomment-239571965, Lex mentioned that you should write migration handlers for this, but I'm not sure what these are and Google isn't particularly helpful.

Yes, I'd say that definitely aids me in my problem, considering I'm the one who wrote it

Okay. How should I work around that if I need to do stuff on the client when a mob attacks?

When I subscribe to receive LivingAttackEvents, I don't get any events on the client end when a mob attacks the player. I get the events on the server in that case, though, and I get events on both ends when the player attacks a mob. Why is this happening? Here's a minimal test mod to demonstrate this problem: package com.example.examplemod; import net.minecraftforge.common.MinecraftForge; import net.minecraftforge.event.entity.living.LivingAttackEvent; import net.minecraftforge.fml.common.Mod; import net.minecraftforge.fml.common.Mod.EventHandler; import net.minecraftforge.fml.common.event.FMLInitializationEvent; import net.minecraftforge.fml.common.eventhandler.SubscribeEvent; @Mod(modid = ExampleMod.MODID, version = ExampleMod.VERSION) public class ExampleMod { public static final String MODID = "examplemod"; public static final String VERSION = "1.0"; @EventHandler public void init(FMLInitializationEvent event) { MinecraftForge.EVENT_BUS.register(this); } @SubscribeEvent public void onLivingAttack(LivingAttackEvent event) { String victimName = event.getEntity().getDisplayName().getUnformattedText(); if(!event.getEntity().worldObj.isRemote) { System.out.println("local - victim is " + victimName); } else { System.out.println("remote - victim is " + victimName); } } } And here's the output of the player fighting a zombie: [22:52:43] [server thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:32]: local - victim is Player231 [22:52:43] [server thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:32]: local - victim is Player231 [22:52:43] [Client thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:34]: remote - victim is Zombie [22:52:43] [server thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:32]: local - victim is Zombie [22:52:43] [Client thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:34]: remote - victim is Zombie [22:52:44] [server thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:32]: local - victim is Player231 [22:52:44] [server thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:32]: local - victim is Player231 [22:52:44] [Client thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:34]: remote - victim is Zombie [22:52:44] [server thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:32]: local - victim is Zombie [22:52:44] [Client thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:34]: remote - victim is Zombie [22:52:45] [server thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:32]: local - victim is Player231 [22:52:45] [server thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:32]: local - victim is Player231 [22:52:46] [Client thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:34]: remote - victim is Zombie [22:52:46] [server thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:32]: local - victim is Zombie [22:52:46] [Client thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:34]: remote - victim is Zombie [22:52:47] [server thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:32]: local - victim is Player231 [22:52:47] [server thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:32]: local - victim is Player231 [22:52:48] [Client thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:34]: remote - victim is Zombie [22:52:48] [server thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:32]: local - victim is Zombie [22:52:48] [Client thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:34]: remote - victim is Zombie [22:52:49] [server thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:32]: local - victim is Player231 [22:52:49] [server thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:32]: local - victim is Player231 [22:52:49] [Client thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:34]: remote - victim is Zombie [22:52:49] [server thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:32]: local - victim is Zombie [22:52:49] [Client thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:34]: remote - victim is Zombie [22:52:50] [server thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:32]: local - victim is Player231 [22:52:50] [server thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:32]: local - victim is Player231 [22:52:50] [Client thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:34]: remote - victim is Zombie [22:52:50] [server thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:32]: local - victim is Zombie [22:52:50] [Client thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:34]: remote - victim is Zombie [22:52:51] [server thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:32]: local - victim is Player231 [22:52:51] [server thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:32]: local - victim is Player231 [22:52:52] [Client thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:34]: remote - victim is Zombie [22:52:52] [server thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:32]: local - victim is Zombie [22:52:52] [Client thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:34]: remote - victim is Zombie [22:52:53] [server thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:32]: local - victim is Player231 [22:52:53] [server thread/INFO] [sTDOUT]: [com.example.examplemod.ExampleMod:onLivingAttack:32]: local - victim is Player231 Note that there are no lines that say "remote - victim is Player231".

For this mod, I followed the one at and .

I ended up doing this as a coremod. Since I'm new to coremodding, can someone take a look at https://github.com/josephcsible/InfiniteFluids/blob/1.10.2/src/main/java/josephcsible/infinitefluids/InfiniteFluidsClassTransformer.java to make sure I didn't do anything too stupid?

I want to change which liquids are "infinite" (like water is in vanilla). I see that in net.minecraft.block.BlockDynamicLiquid, the updateTick method includes the line "if (this.adjacentSourceBlocks >= 2 && this.blockMaterial == Material.WATER)", which seems to be how this is controlled. My question is the best way to change this behavior. Should I subclass BlockDynamicLiquid and try to replace all uses of it? Should I use coremod/ASM to change that to do something like "if (this.adjacentSourceBlocks >= 2 && someFunctionInMyMod(this, worldIn, pos, state))"?