aw_wolfe

Thanks. I get that I can put static loot tables in json. I have a set of loot conditions that need to be checked dynamically. So in 1.12, I have my own LootConditions, LootEntry. Therefore, I could easily say "if 'unique item' is not already dropped ever in game, zombies can drop 'unique ite'm on Tuesdays after dark with 60%". My other mods could also add a new item and use this mod as utility to quickly add complex loot conditions. The problem is that in 13.2. LootTableLoadEvent is not being called for vanilla loot tables. It has them as "custom=true" and in 1.12, "custom=false"...so forgehook is NOT called in 13.2, whereas it was in 1.12. If I copy all vanilla loot tables into data/mymod/loot_tables , not all of them are triggering LootTableLoadEvent either...haven't investigated why. I am hoping I am doing something dumb or not seeing an obvious solution.

Anyone point me in the right direction? The vanilla loot tables are coming in as "custom" and final. So, not able to catch them in LootTableLoadEvent and unable to modify them by getting LootTableManager and modify them after load. In 1.12, vanilla would fire the LootTableLoadEvent and you could modify the pools. In 1.13.2, vanilla is not firing the LootTableLoadEvent because it thinks they are "custom".

prior to 13.2, LootTableLoadEvent would fire for vanilla loot tables. ForgeHooks#loadLootTable received a (false) for "custom" parameter. This led to ForgeEventFactory.loadLootTable(name, ret, lootTableManager); being executed. Which in turn led to the LootTableLoadEvent firing. However, in 13.2 : (ForgeHooks) if (!custom) ret = ForgeEventFactory.loadLootTable(name, ret, lootTableManager); Is never called for me (except on my own mod's loot tables) because ForgeHooks#loadLootTable is always passed a true for "custom" parameter for any minecraft loot table. Is this a design change? Is something off with my mod/install? A bug? Is there another way to catch and edit vanilla loot tables (need to do dynamically -- do not want to simply add new json that overwrites)?

I think it is the issue with you item dye minecraft:pink_dye doesn't exist you need: { "item":"minecraft:dye", "data":9 } each dye has it's own data.

in your fire block class, override public void onEntityCollidedWithBlock(World worldIn, BlockPos pos, IBlockState state, Entity entityIn) do any fire resistance checks and set entity on fire. for extinquishing the fire, I don't know exacting where mc code is, but guessing it is using the Blocks.Fire as well. So, you'll probably need to override onBlockClicked in your block to extinquish itself(set itself to an air block)

look at... world#public boolean isFlammableWithin(AxisAlignedBB bb) This is what entity uses during update to determine if should set on fire. It uses Blocks.FIRE (which is an id and not checking for instanceof BlockFire). so your derived class won't match. you will have to do your own collision detection or maybe setting block to isburning state will work (see above function)

I think you are going to need to implement your own IRecipe. Follow choonsters example of ShapedArmourUpgradeRecipe (from your example you are looking at). Yes, you'll need to add a couple classes, but then you can override the matches and getCraftingResult to match and damage. Choonsters example is nice, because it still allows you to read from the json file....and he gives you all the code you need. To simplify you could hard code it in the IRecipe, but why ?

Think it has to do with the recipe json. Crafting will do a check on the item and if not the "same", it won't find it. if the meta or damage are not the same, it will not think it is the same item. Metas are small enough you can add mutliple metas into a recipe json, but if you want damaged items to work, think you'll need to create your own IRecipe to handle the item matching. I'm working on 0 sleep, so if I'm not following your problem, sorry. If you are trying to make your item repairable, then that is different solution

I know. Love to greyghost.

https://github.com/TheGreyGhost/MinecraftByExample

I think your issue was the time of use of the item was too short and the animation sound didn't play. These 3 overrides from ItemPotion work for me in a new Item. @Override public int getMaxItemUseDuration(ItemStack stack) { return 32; } @Override public EnumAction getItemUseAction(ItemStack stack) { return EnumAction.DRINK; } @Override public ActionResult<ItemStack> onItemRightClick(World worldIn, EntityPlayer playerIn, EnumHand handIn) { playerIn.setActiveHand(handIn); return new ActionResult<ItemStack>(EnumActionResult.SUCCESS, playerIn.getHeldItem(handIn)); }

If you use the lemonade as a potion, the built in system will add others... I think extended lemonade, splash lemonade, etc. Would it be better to make the lemonade a "normal" item? Override public EnumAction getItemUseAction(ItemStack stack) { return EnumAction.DRINK; } This will also deal with the shimmer issue. Then you can simply set up a brewing recipe to produce your lemonade.

you can set the damage directly to the stack stack.setItemDamage(); Are you getting an item in inventory, or just not a damaged item?

Probably better answers out there. But, different blocks could handle direction or facing differently, so I'd say there is no for sure way. You can iterate through the properties of the blockstate and see if any have a "facing" as most directional block will implement similar to vanilla. Problem is they may convert to and from meta differently. You'd have to implement a switch for each type of block to strip of facing...but if using other mods, you may not know how they convert to meta and back. I guess, I'd question your problem and see if there is a different solution. Or if you can ignore blocks with facing, What are you trying to find with meta?

for 11.2, here is a good tutorial... https://shadowfacts.net/tutorials/forge-modding-1112/crafting-smelting-recipes/