The_Wabbit

Forge adds two new ITag (tag) collections to the base set provided by Minecraft: enchantments and potions. There seems to be all the bits necessary to add additional collections. My questions are: Is this something that's ok to do in general? (ya it's modding and I can do whatever but I'm just askin'...) How would I get the registry recognized by Forge (i.e. do I mimic what is being done in GameData for Forge's own custom registries...using tagFolder to specify the new datapack location). Note that I know how to get at the registry using Forge, but I need Forge to know it's there... Background: What are you doing exactly? I'd like to add an effects collection as many many Effects do not have brewable potions and I'd like a way to get at those in a data-driven way (rather than hard-coding for each mod)...for example to have a collection of effects like 'poisons', 'thirst', 'blindness', etc. Also looking into damage sources and armor materials... Code reference: net.minecraftforge.registries.GameData (see the creation of enchantments and potions items)

For 1.16.x custom loot conditions and loot functions require registration of matching LootConditionType and LootFunctionType. There are no hooks via Forge registry events and using the builtin registry directly (sample how below) doesn't work (tried doing before registry events and after...nada). Registry.register(Registry.LOOT_CONDITION_TYPE, <my_name>, new LootConditionType(<my_serializer>)) This is probably staring me right in the eyeball, but I can't see it. Any directions/samples would be appreciated.

Maybe check out code for Quark's shulker tooltips and Silent Chaos's Equipment tooltips (both on CurseForge with github source). Both mods seem to change the tooltips to include textures so they might help you narrow down the render code searching.

Try changing the ForgeFlowingFluid.Properties as well. In particular, the tickRate which affects how fast the fluid appears to flow. See how LavaFluid is setup to match.

Perhaps you can try looking at how the Culinary Construct Mod does its dynamic sandwich itemstack rendering: https://github.com/TheIllusiveC4/CulinaryConstruct.git. HTH

DeferredWorkQueue is flagged as deprecated. Is it still the best way to do this?

You might want to check the VillagerTradesEvent event and the BasicTrade class it refers to. Seems to be Forge devs indicating how you can do what you seem to want to do. There is even a WandererTradesEvent for the wandering trader as that is distinct from regular trading.

Check your TAN config files. Most likely it's referring to a modded item or block that you're not loading or you have a typo somewhere.

Hmm..so I can just check for instanceof BucketItem instead of UniversalBucket and use getFluid...but From the vanilla code, BucketItem requires an item instance per fluid (the fluid is tracked by the item as an instance field). This is not quite the same as the old UniversalBucket which was a single item that changed itemstack NBT data to reflect different fluids...Does your reply mean modded fluids need a unique BucketItem instance too?

Maybe I'm just really blind, but as far as I can tell there is no replacement for the UniversalBucket item with the new Forge Fluid system (as of 1.14.4-28.0.83). So how does one identify a "bucket of some other mod's fluidy stuff" from say a custom recipe? Is the new (and only) way to test for capabilities on ItemStack now (so every mod has it's own version of a universal bucket)? Just checking if UniversalBucket is a delayed feature or has been removed permanently.

My mods.toml looks similar to yours. Best I can tell from the Forge debug logging: the initial construction of mods is done in parallel, independent of that particular mods.toml setting. For example some real IDE outputs (extendedfoodpantry wants to be loaded AFTER vanillafoodpantry per its mods.toml file). [09Aug2019 08:48:11.748] [Client thread/DEBUG] [net.minecraftforge.fml.ModList/LOADING]: Dispatching parallel event LifecycleEvent:CONSTRUCT [09Aug2019 08:48:11.752] [Client thread/TRACE] [net.minecraftforge.fml.loading.ModJarURLHandler/CORE]: Loading modjar...SNIPPED [09Aug2019 08:48:12.047] [modloading-worker-3/DEBUG] [net.minecraftforge.fml.javafmlmod.FMLModContainer/LOADING]: Loading mod instance extendedfoodpantry of type...SNIPPED [09Aug2019 08:48:12.049] [modloading-worker-3/TRACE] [net.minecraftforge.fml.loading.ModJarURLHandler/CORE]: Loading modjar...SNIPPED [09Aug2019 08:48:12.074] [modloading-worker-1/DEBUG] [net.minecraftforge.fml.javafmlmod.FMLModContainer/LOADING]: Loading mod instance vanillafoodpantry of type...SNIPPED [09Aug2019 08:48:12.077] [modloading-worker-1/TRACE] [net.minecraftforge.fml.loading.ModJarURLHandler/CORE]: Loading modjar...SNIPPED [09Aug2019 08:48:12.080] [modloading-worker-2/DEBUG] [net.minecraftforge.fml.javafmlmod.FMLModContainer/LOADING]: Loading mod instance upsizer of type...SNIPPED [09Aug2019 08:48:12.080] [modloading-worker-2/TRACE] [net.minecraftforge.fml.loading.ModJarURLHandler/CORE]: Loading modjar...SNIPPED Notice the separate modloading-worker-xxx threads. The mods.toml ordering may only apply to event notification ordering after the mod's instance has been constructed (the ordering of which is undefined). The lesson here might be to put any ordering-dependent referential code into an event callback, not your constructor. Will close this thread once I've tried that...

I'm trying to understand all the bits that you can declare in your mods.toml file and can't seem to get the ordering option for a dependency to have any meaning. I have a mod "B" that depends on mod "A" so I assumed (uh-oh) that if I put "A" as a required dependency for "B" that it would be loaded after; I made the BMod.Amod 'ordering' field equal 'AFTER' as shown below. However, after some testing it seems that things get loaded in any which way as "B" would be created before "A" (I put a hard dependency in B's constructor to use an object created in A's constructor as a test; also logging). I see no reference to the IModInfo.getOrdering method in the Forge code either. I have tried changing the order in the dependency (BMod.AMod) to 'BEFORE' and that didn't seem to have any effect. Has anyone tried using dependencies/ordering=AFTER (like for libraries or mod extensions where you really need the first mod created first)? # Find more information on toml format here: https://github.com/toml-lang/toml modLoader="javafml" loaderVersion="[25,)" #(25 is current forge version) updateJSONURL="http://blabla.org/files/mcmods/versions/b.json" issueTrackerURL="https://github.com/muserid/bproject/issues" displayURL="https://minecraft.curseforge.com/projects/b-mod" credits="Forge, Donald Trump's Hair" authors="The_Wabbit" # Mod List (usually just the one) [[mods]] modId="b" version="1.0b1" displayName="Bestest Mod Ever" # Mod description (multi line!) description=''' Something witty said here ''' # Dependency: BMod.Forge [[dependencies.BMod]] modId="forge" mandatory=true versionRange="[25,)" ordering="NONE" side="BOTH" # Dependency: BMod.Minecraft [[dependencies.BMod]] modId="minecraft" mandatory=true versionRange="[1.14.3,1.15)" ordering="NONE" side="BOTH" # Dependency: BMod.AMod [[dependencies.BMod]] modId="a" mandatory=true versionRange="[1.0.0b5,2.0)" ordering="AFTER" side="BOTH"

I had this "No blocks of any kind drop anything" happen to me a few times -- turned out to be a bad tag file that just caused the entire datapack loading (including loottables) init to abort...no warning that this had occured until i noticed that error in log file. Perhaps check for similar occurance

If you only need to use addMix there is also a non-reflection alternative that uses a brewing recipe via BrewingRecipeRegistry.addRecipe(...). Note there is a bug (1.14.3) in the Forge default BrewingRecipe so you should roll your own fixing the following in the isInput method like: public class ModBrewingRecipe extends BrewingRecipe { public ModBrewingRecipe(ItemStack input, Ingredient ingredient, ItemStack output) { super(input,ingredient,output); } @Override public boolean isInput(ItemStack stack) { return ItemStack.areItemsEqual(super.getInput(),stack); //THIS IS BROKEN in super 1.14.3 } } Pass in filled in potion itemstacks (see PotionUtils.addPotionToItemStack) for the input and outputs (eg Awkward potion -> Your potion)

This was registered as an issue. Probably pretty low on the devs priority list for 1.14 just yet though. https://github.com/MinecraftForge/MinecraftForge/issues/5814

Has anyone successfully changed the model .json file location for items from the top level of the models/item/registryname.json location to something else? In particular, I'm interested in keeping models in subdirectories and multi-mapping a set of items to a single model file. Example #1: Keeping a set of items in a subdirectory of models/item like 'models/item/packs' to hold a subset of 50+ items related to a packs feature. Example #2: Mapping items that look the same except for a color change to a single file like 'models/item/juice.json' instead of duplicating the same file dozens of times. Example #3: Keeping the item models in a subdirectory that matches its block model locations like 'models/item/darkstone' to match the subdirectory for that block

I think your block needs to mimic the HopperBlock's onReplaced method. The loot information in the hopper's tile entity is for items that can have loot tables associated with them which is not what you're asking for (you just want to drop current inventory sounds like). Also check out the ChestBlock or BarrelBlock code.

@Laike_Endaril So you don't think there's a way to get at the SRG values for 1.13.2? I'm trying to find the mappings for a field that no longer has a public setter (this is just early dirty testing for migrating old mods that used setMaxStackSize which is gone now). For 1.12 there was the -srgBin.jar files...I don't see those anymore...

UPDATE: Ok, so I seem to have stumbled on something that was discussed to death by the devs back in Nov-2017. For reader reference see: https://github.com/MinecraftForge/MinecraftForge/issues/4516. I'll be investigating a custom recipe for my case, but am leaving this topic open for now in case there is a better solution someone can propose (I can't tell where the discussion ended up honestly...) Hullo all, Sometime between 1.12 and 1.12.2 (latest recommended build 2655), json shapeless ore recipes seem to have begun comparing NBT data. So what was a simple "item": "modid:itemname" for an ingredient regardless of nbt, seems to need something else now to mean "ignore nbt". However, I still only see the 1.12 "minecraft:item" and "minecraft:item_nbt" ingredient types which seems to indicate "minecraft:item" should match any nbt (and you use 'item_nbt' otherwise). Am I missing something for 1.12.2? Here is a simple test recipe file 'i_shall_call_you_squishy.json'. Works for 1.12 & 1.12.1 recommended builds. Is broken for 1.12.2 though: { "result": { "item": "minecraft:egg", "nbt": { "display": { "Name": "Squishy"} } }, "type": "forge:ore_shapeless", "ingredients": [ { "item": "minecraft:name_tag" }, { "item": "minecraft:egg" } ] } Test cases: 1) an egg + default name tag --> OK for all versions! 2) an egg + name tag with custom name --> no recipe match in 1.12.2 but OK for 1.12 and 1.12.1 3) egg with custom name + default name tag --> no recipe match in 1.12.2 but OK for 1.12 and 1.12.1 So for 1.12.2 how do I change "minecraft:name_tag" to mean "any name tag regardless of NBT data"? i_shall_call_you_squishy.json

Choonster also has a nice set of simple test classes that demonstrate various solutions to common questions about custom recipes: https://github.com/Choonster-Minecraft-Mods/TestMod3/tree/1.12.2/src/main/java/choonster/testmod3/crafting. See the assets folder for json files like _factories.json ...

Just a stab (2nd question)...but I can imagine a complex fluid handler being like the controller of many tanks (or they can be one and the same for single-fluid containers). The handlers delegates to the tanks when needed. For instance, I have seen huge modded fluid processors (the handlers) that control dozens of tanks of different fluids from different mods. The tanks are essentially an implementation detail in this scenario. Also Forge fluid handlers exist for non-tanks use cases such as fluid blocks, portable ItemStacks like universal buckets, custom tile entities, etc.

Check this test from choonster. Might be just what you need (should work for 1.10/1.11 but it's 1.12 branch): https://github.com/Choonster-Minecraft-Mods/TestMod3/blob/1.12.2/src/main/java/choonster/testmod3/item/ItemArmourPotionEffect.java. Also check the Forge LivingEquipmentChangeEvent for 1.12 (I don't know if it exists for 1.10). HTH.

Use the grow method instead...yea this name switch walloped me something good as well when I migrated.

No "Tool modifier" won't work (I actually have not tried)? Or no because of the method he's trying (from the code, I'm assuming the deprecated method is being called via the newer forge method for now...)?

Maybe try using "Tool modifier" instead of "Weapon modifier" (a hoe is not a weapon...)