Jump to content

The_Wabbit

Members
  • Posts

    36
  • Joined

  • Last visited

Posts posted by The_Wabbit

  1. 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)

  2. 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.

     

  3. 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?

  4. 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.

  5. 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...

  6. 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"
    

     

  7. 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

  8. 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)

  9. 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

  10. @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...

  11. 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

  12. 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.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.