Need Help with Modifying Loot Tables

[OnlyMobster]

Hey everyone, so I'm currently working a new mod that adds custom enchantments and enchanting tables to the game. I have this item called a "locked_tome" which I want to spawn naturally in vanilla chests. For example, when a player opens a desert pyramid or dungeon chests, they might find that item there. 

I have been researching and trying things for days now, but there seems to be lots of options and some of them are deprecated.

The one that is brought up often is the use of a Global Loot Modifier. However, because all the documentation and examples are for mob loot with a certain type of tool, instead of chest loot generation, its hard to understand how I would construct my own classes for that situation. 

 

Does anyone know how I would edit the dungeon/pyramid chests to include locked_tomes into the mix? Can you use simple loot_table jsons? Would I use CraftTweaker/LootTweaker? Would I use LootTableOnLoad? Or should I use Global Loot Modifiers? If any of these, how?

 

Version I'm using is 1.15.2 Forge and using IntelliJ

Edited September 13, 2020 by OnlyMobster

[Draco18s]

The chest entity might also be available directly from the context (the ENTITY parameter), but I haven't looked at it in a while, nor at the chest-generation specifically.

What diesieben07 said will definitely work though.

[OnlyMobster]

3 minutes ago, diesieben07 said:

Yes. In your global loot modifier you can detect certain chests by getting the POSITION loot parameter from the LootContext. Then get the tile entity at that position (LootContext#getWorld gives you the world).

Then check if that TileEntity is a LockableLootTileEntity and if so, check it's loot table.

Thanks so much!

Ok, do I still use the same Registry classes and functions as per https://mcforge.readthedocs.io/en/latest/items/globallootmodifiers/?

Also, when you say "certain chests", could I detect every dungeon chest in my world? Not just a few right?

Lastly, once I've checked the lootTable, how do I add to it?

[Draco18s]

3 hours ago, diesieben07 said:

Nope. Chests only provide the position.

👍

[OnlyMobster]

4 hours ago, diesieben07 said:

Nope. Chests only provide the position.

 

Yes.

 

Yes, what I meant was distinguishing e.g. dungeon chests from desert temple chests. Which you can do by checking the loot table of the chest.

 

This is shown in the loot modifier documentation, which you already linked above.

So Ive been digging around with LootParameter, and I still have some more questions

So, my code recognizes LootParamter.POSITION, but what does that represent? The documentation doesnt really exist for it: does it represent the position of the generated loot? If so, which loot? How would I get the LootParamter.POSITION of a jungle temple chest let's say?

 

Also, I had a question about the doApply() method. What is the generatedLoot parameter? Is it all the Items from a certain loot_table? If so, which one?

 

Anyways, thanks for all the help

[Draco18s]

13 minutes ago, OnlyMobster said:

The documentation doesnt really exist for it: does it represent the position of the generated loot? If so, which loot?

The one being generated RIGHT NOW. Each chest will call the function with different context.

13 minutes ago, OnlyMobster said:

Also, I had a question about the doApply() method. What is the generatedLoot parameter? Is it all the Items from a certain loot_table? If so, which one?

Everything previously generated. All of it. Every last item, its a list. That including any stacks created by previously run modifiers.

 

And for whatever loot table is being processed. You seem to have a bit of confusion over what loot modifiers do. Loot modifiers are the replacement system and are a 1:1 translation of what the HarvestDropsEvent did, and more, and does it better.

 

Break a block? apply() is called for all modifiers.

Kill an entity? apply() is called for all modifiers.

ALL loot table generation should call apply().

 

(Minor caveat, if your loot modifier does not need to be called, due to its loot conditions, then it is not actually called, but apply() is called, which checks those conditions, and if those conditions are true, then doApply()--the orrideable method you have control of--is called, but all loot modifiers are processed).

 

The only difference is what context those events have. Which is why you're given the context.

Edited September 14, 2020 by Draco18s

[OnlyMobster]

For some reason, answer posted twice, so this is a filler reply
 

Edited September 14, 2020 by OnlyMobster

[OnlyMobster]

7 hours ago, diesieben07 said:

Yes. In your global loot modifier you can detect certain chests by getting the POSITION loot parameter from the LootContext. Then get the tile entity at that position (LootContext#getWorld gives you the world).

Then check if that TileEntity is a LockableLootTileEntity and if so, check it's loot table.

I'm starting to figure things out  But, i was wondering. When I do context.getWorld().getTitleEntity(), getTitleEntity takes a BlockPos. Is there a way to convert LootParameters.POSITION to a BlocksPos object? Or perhaps should I just use

context.getLootTable(LootParameters.POSITION.getId());

Or am I doing this all wrong haha

Of course, if I just did getLootTable() I wouldnt be able to filter through certain lootTable types, unless maybe I used getClass()?

Edited September 14, 2020 by OnlyMobster

[poopoodice]

LootContext.Builder.get(lootparam)

[OnlyMobster]

3 minutes ago, poopoodice said:

LootContext.Builder.get(lootparam)

What do you mean by this? Is this supposed to access the lootTable?

[poopoodice]

It gives you the blockpos so you can access the tileentity in the world.

[OnlyMobster]

39 minutes ago, poopoodice said:

It gives you the blockpos so you can access the tileentity in the world.

Oh, thank you. Would i just put LootParameters.POSITION where lootparam is?

[Draco18s]

6 hours ago, diesieben07 said:

On a side note, this mechanism is almost always useless I have found. You cannot actually apply any of the pre-built loot conditions here, because they will throw exceptions if they do not find the loot parameters they expect. Which will almost certainly happen, as all loot generation passes through your modifier.

That's news to me, nothing like that happened when I built the sucker (and it still appears in the sample files).

The whole point was to be able to use existing the existing Loot Conditions system so that as much as possible was able to be placed into the JSON data without having to design a similar system to do essentially the same thing.

Edited September 14, 2020 by Draco18s

[OnlyMobster]

9 hours ago, diesieben07 said:

Yes. Although it is LootContext#get(LootParameter) that you want, not LootContext.Builder.

Ok, awesome. In regards to the serialized JSON, I actually had a question about formatting. A lot of examples don't include a POOL, so I'm assuming it works a little differently. I get how values are accessed and represented, but in regards to my mod and wanting to place something in a chest loot table, are conditions even something to care about/include in my JSON? The thing is, I removed the "conditions" section and my code throws a NullPointerException because Conditions is null. Why would conditions matter for this? I guess perhaps there's a chest condition? If so, what is it?

Thanks for all the help

[Draco18s]

3 hours ago, diesieben07 said:

I definitely remember some problems like this. Looking at the code now, it should work fine like you said. But I distinctly remember it being a problem multiple times.

That was early on in my attempts to Do Things, and I don't think it was a "throw errors" kind of problem, but I think I had that resolved before I ever made a PR.

[OnlyMobster]

1 hour ago, diesieben07 said:

The idea is to make your global modifier configurable via the data. This way it can be reused and configured by data packs (e.g. for pack or map makers).

 

In your case I'd make your loot modifier very generic: Just add a list of item stacks. Then via the conditions you can configure when to do it and you can also read the stacks to add from the JSON (in GlobalLootModifierSerializer#read).

There is no loot condition for "chest with loot table" though, so you'd have to write your own. This is pretty easy though, look at the vanilla ones. 

That makes a lot of sense, but for some reason my code keeps throwing NullPointerExceptions. This is my locked_tomes.json, which is referenced in my global_loot_modifiers.json.

{
  "type": "bden:locked_tomes",
  "bookItem": "bden:locked_tome",
  "numBooks": 1,
  "pools": [
    {
      "conditions": [
        {
          "condition": "random_chance",
          "chance": 1
        }
      ],
      "rolls": 1,
      "entries": [
        {
          "type": "item",
          "name": "bden:locked_tome",
          "weight": 100
        }
      ]
    }
  ]
}

Im assuming the conditions here aren't enough? Do you know why it would be throwing a NullPointerException at this lootModifiers line?

ILootCondition[] lootConditions = GSON_INSTANCE.fromJson(object.get("conditions"), ILootCondition[].class);

[Draco18s]

16 minutes ago, OnlyMobster said:

Im assuming the conditions here aren't enough? Do you know why it would be throwing a NullPointerException at this lootModifiers line?

ILootCondition[] lootConditions = GSON_INSTANCE.fromJson(object.get("conditions"), ILootCondition[].class);

You shouldn't be calling that yourself, unclear if you are, or if that's the Forge code.

Check for earlier errors, such as if your loot modifier failed to be loaded.

[OnlyMobster]

6 hours ago, Draco18s said:

You shouldn't be calling that yourself, unclear if you are, or if that's the Forge code.

Check for earlier errors, such as if your loot modifier failed to be loaded.

The lootModifier can't be parsed, thats what the error is I assumed that the NullPointerException was causing this, but perhaps its actually the other way around: the parsing error is causing the NullPointerException. What do you think would cause "Could not parse loot modifier bden:locked_tomes"?

Its Forge that is running this, its just where it sent me for the location of the NullPointerException.

[OnlyMobster]

46 minutes ago, OnlyMobster said:

The lootModifier can't be parsed, thats what the error is I assumed that the NullPointerException was causing this, but perhaps its actually the other way around: the parsing error is causing the NullPointerException. What do you think would cause "Could not parse loot modifier bden:locked_tomes"?

Its Forge that is running this, its just where it sent me for the location of the NullPointerException.

I think I figured out why the error was throwing The locked_tomes.json was in the wrong directory, it was in loot_tables, not loot_modifiers

 

I still don't know if my serialized json is correct though

 

Edited September 15, 2020 by OnlyMobster

[OnlyMobster]

7 hours ago, Draco18s said:

You shouldn't be calling that yourself, unclear if you are, or if that's the Forge code.

Check for earlier errors, such as if your loot modifier failed to be loaded.

I think I found the source of the error, since it came back again.

In my previous message, I mentioned the directory change.

Interestingly, later when I try to check for the entity being a Lockable entity, i'm assuming the if statement never ended up being true and so generatedLoot.add() never ran. However, when I run it by default, without an if statement, the same "Could not parse loot modifier bden:locked_tomes" is thrown.

[Draco18s]

There should be a reason included.

[OnlyMobster]

Thanks for all the help you guys. Seems like I got it to work now  The book appears among other chests. Now I just have to narrow it down to certain chests when I feel like doing that.