[Forge 1.20.1] FD loot modifiers isn't compatible with other GLM

[TheRealVoin]

Farmer's delight version: latest (1.2.11)

I noticed this issue while developing my mod. I couldn't change FD loot modifiers in any way.

The problem is in AddLootTableModifier class. It uses getRandomItemsRaw() method, which is deprecated. And there is commetary: "/ Use a non-'Raw' version of 'getRandomItems', so that the Forge Global Loot Modifiers will be applied"

@Deprecated // Use a non-'Raw' version of 'getRandomItems', so that the Forge Global Loot Modifiers will be applied
   public void getRandomItemsRaw(LootContext pContext, Consumer<ItemStack> pOutput) {
      LootContext.VisitedEntry<?> visitedentry = LootContext.createVisitedEntry(this);
      if (pContext.pushVisitedElement(visitedentry)) {
         Consumer<ItemStack> consumer = LootItemFunction.decorate(this.compositeFunction, pOutput, pContext);

         for(LootPool lootpool : this.pools) {
            lootpool.addRandomItems(consumer, pContext);
         }

         pContext.popVisitedElement(visitedentry);
      } else {
         LOGGER.warn("Detected infinite loop in loot tables");
      }

   }

[vectorwing]

I don't recall exactly why I resorted to the raw method, but I think it was failing or bugging out when using the intended one.

I can take a look at it again later.

[vectorwing]

Checked the method, and the raw version was used to fix a recursive crash: 0660006

This seems to be the way NeoForge implements their own loot table modifier as well, to prevent modifiers from recursively changing a subtable. Seems to be a design limit.

Just to clarify, as I'm not fully sure what you're attempting here: are you trying to modify the subtables that FD is adding, or the vanilla loot table itself?

[TheRealVoin]

Both. We will take, for example, an abandoned mineshaft chest loot. My mod adds food spoilage mechanic. I also need to handle food that is generated by loot tables (in our case it is rice). My mod simply checks if the item has food capability, and if has, makes it spoiled:

@Override
    protected @NotNull ObjectArrayList<ItemStack> doApply(ObjectArrayList<ItemStack> generatedLoot, LootContext context) {
        for (ItemStack itemStack : generatedLoot) {
            itemStack.getCapability(FoodSpoilageProvider.FOOD_SPOILAGE).ifPresent(foodSpoilage -> {
                foodSpoilage.setEnvironment(FoodEnvironment.STORAGE);
                foodSpoilage.setFoodLifetime(FoodCategory.getFoodCategory(itemStack).getSpoilageTime());
                foodSpoilage.setLastUpdateTime(context.getLevel().getGameTime());
            });
        }

        return generatedLoot;
    }

set_spoiled_status.json:

{
  "type": "notjustspoiled:set_spoiled_status",
  "conditions": [
    {
      "condition": "minecraft:any_of",
      "terms": [
        {
          "condition": "forge:loot_table_id",
          "loot_table_id": "minecraft:chests/abandoned_mineshaft"
        },
        {
          "condition": "forge:loot_table_id",
          "loot_table_id": "farmersdelight:chests/fd_abandoned_mineshaft"
        }
      ]
    }
  ]
}

This loot modifier successfully applies to vanilla abandoned mineshaft loot table, but not to Farmer's Delight's.
Here is my mod repository, if needed: Not Just Spoiled

[KnightMiner]

This sounds like an issue with GLM load order to me. Seems like your GLM applies before FD's GLM, so your changes do not apply to the new items they add. While in theory FD could fix it so you can modify their nested loot table, that might cause your GLM to run twice on the chance your stuff ends up running second instead of first (and more importantly, other people's GLMs which do not produce the same result when run twice). It also would not support the other solution to adding new items to a loot table - using loot entries/loot pools directly which some other mods do.

The simplest solution is to run "Not Just Spoiled" after, but there is not a good way to enforce that on 1.20 as it relies on datapack load order (Neo added a GLM priority system on later versions). I think you might be able to use a mods.toml after to make your mod load after FD, but thats not always reliable.

At a pack maker level, they can fix it by overriding the GLM order file. Bit of a pain to do manually, but my mod Mantle has a command to help.

---

The only real fix that could be done on FD's side on 1.20 to my knowledge would be not using GLMs at all and instead using the loot table load event, but that is natively way less configurable for pack makers so its less ideal.

[TheRealVoin]

@KnightMiner Yeah, thanks! The problem was in the GML load order. The trick with mods.toml didn't work, but the one with custom datapack and reordering GMLs in global_loot_modifiers.json worked. So if we found cause, we need right solution. The problem is that my GML should be registered last from all other GMLs without using datapacks. And seems that I find it.

global_loot_modifiers entires can be overriden by datapacks so the final file should be like following:

{
  "replace": false,
  "entries": [
    "notjustspoiled:set_fresh_status",
    "notjustspoiled:set_spoiled_status",
    "notjustspoiled:set_random_status"
  ]
}

and it will be automatically overriden and placed in the end of the list. Then I will use AddPackFindersEvent to bundle this datapack in mod. This is the best way to do this, right?

This solution works in my case, but if somebody wanna change FD's loot modifier directly?