[Feature Request] Allow Affix Loot Entries to specify by item tag instead of just resource name
BigJMoney opened this issue ยท 11 comments
I tried this and it didn't work (I didn't expect it would):
{
"type": "apotheosis:affix_loot_entry",
"stack": {
"count": 1,
"id": "#mypack:epicknight_armors"
},
"weights": {
"haven": {
"weight": 1024
}
}
}
This request would allow for diferent weights by class, which would be much more manageable than currently.
It would make organizing by weight much easier for modpacks (or just private users like me) when there are lots of affixable items coming in from mods. Currently, every item competes with each other item for weight. This creates the problem that if one class of items is more prevalent than another, the weights are not balanced. If I have 50 weapons from mods and only 10 tools, then I will rarely see tools appear in loot unless I give each tool a very high weight. But even so, this weight would need to be updated when more items are added. Once I have 100 weapons, I must then go in and modify the weights again.
In any case, users do not necessarily want loot weight to be based on raw number of items, but rather something controllable that suits gameplay. Item tags already exist as a feature in MC to manage something like this.
There is substantial difficulty in making it accept a HolderSet (one or more items, or a tag), simply because it needs to support NBT, and supporting something like a HolderSet gives no way to pin NBT data to an individual item (only all of them).
List<ItemStack> is more amenable, but at that point you would be better off creating multiple Affix Loot Entries anyway.
I have a question. I recently noticed this comment in Weight.md:
"weight": integer, // [Mandatory] || The weight of this object. This value is relative to other objects of the same kind.
If this comment is still current, what are the categories of 'kind'? Armor vs Tool? This functionality might make some of this request moot, anyway. It could also be useful to add the list of kinds in that .md file, for reference.
The "kind" is the whole group of things, in this case, affix loot entries. i.e. the weight of an affix loot entry is relative to all others (After pruning). The /apoth debug weights command is useful here.
edit: nvm, I was stupid.
there is already TieredWeights implementation for affix item.
As for your loot entry, why don't you just use vanilla style?
{
"type": "minecraft:empty",
"weight": 25
},
{
"type": "minecraft:tag",
"name": "mypack:epicknight_armors"
"weight": 10
}Let me put tiered weights aside for a moment to solve one issue at a time.
For the vanilla loot entry example you give, are you referring to the loot entries that live in data\minecraft\loot_table\chests? Or do you mean use the vanilla style (as per your example) but place it under affix_loot_entries?
In either case, are you saying that such a loot entry will result in affixes being added automatically? i.e. I don't need to use a "proper" apotheosis:affix_loot_entry in order to get affixes on the loot I add this way?
Actually, I tested it out and I understand. Apotheosis does add affixes to items that are added using vanilla loot tables. Just a correction to your example. It must include expand true to make it a composite entry:
{
"type": "minecraft:tag",
"expand": true,
"name": "mypack:epicknight_armors"
"weight": 10
}
However, adding loot this way does not allow for World Tier assignment, which requires a apotheosis:affix_loot_entry, no? I will test adding a world tier weight next, and then address your comment about world tiers anyway, because I don't believe the world tier functionality addresses the other part of my request.
By the way, thanks for the example!
World Tier assignment inside of vanilla loot entries is recognized, but perhaps it's broken. Before I log a separate issue report, I'll ask here if this is actually a bug. This is the data I'm using in village\village_cartographer.json:
{
"type": "minecraft:chest",
"pools": [
{
"bonus_rolls": 0.0,
"entries": [
{
"type": "minecraft:tag",
"expand": true,
"name": "mypack:epicknight_armors",
"weights": {
"haven": {
"weight": 1024
},
"frontier": {
"weight": 1
}
}
},
{
"type": "minecraft:item",
"name": "minecraft:compass",
"weight": 10
}
],
"rolls": {
"type": "minecraft:uniform",
"max": 5.0,
"min": 1.0
}
}
],
"random_sequence": "minecraft:chests/village/village_cartographer"
}
I expect that this should result in lots of epic knight armor in the cartographer chest while I'm at Haven tier, and then start giving me mostly compasses at Frontier tier.
After a fair amount of testing, the results aren't exactly consistent, but I would expect to see more compasses than armor after activating Frontier tier, and this doesn't occur. I've even tried setting frontier weight to 0 and the armor still appears. I'm starting to think that the "weights" key does not compare against the "weight" key. In other words, "weights" is only used to compare affixed items against each other. I would still expect a weight of 0 to mean don't spawn, however.
@rtxyd Are you sure that Apotheosis TieredWeights are supposed to work in vanilla loot tables? I even tried this as my loot table, and it will spawn epic knights armor much more often than a compass:
{
"type": "minecraft:chest",
"pools": [
{
"bonus_rolls": 0.0,
"entries": [
{
"type": "minecraft:tag",
"expand": true,
"name": "mypack:epicknight_armors",
"weights": {
"haven": {
"weight": 0
},
"frontier": {
"weight": 0
},
"ascent": {
"weight": 0
},
"summit": {
"weight": 0
},
"pinnacle": {
"weight": 0
}
}
},
{
"type": "minecraft:item",
"name": "minecraft:compass",
"weight": 10
}
],
"rolls": {
"type": "minecraft:uniform",
"max": 1.0,
"min": 1.0
}
}
],
"random_sequence": "minecraft:chests/village/village_cartographer"
}
The only way I have been able to prevent the epic knights armor items from spawning is to delete the "weights" data table completely, or to replace it with the vanilla style ("weight": 0) instead.
Sorry for wasting your time, but yesterday I immediately edited it with "nvm, I was stupid." It was at the moment that I realized your usecase was not just "getting the equipment like vanilla loot table".
And the "weights" key is not supported in vanilla loot tables for now. I am really sorry.
Well, you at least taught me that items in vanilla loot tables do get affixes, which I had not picked up on. So there is that, lol. I learned a bit more about the mod, so it wasn't a waste of time.
An alternative to the way I initially described this feature request this would be to allow multiple stacks inside one entry. The crucial thing would be that the weight applies to the group, not to each stack in the group. i.e. When this affix entry is rolled while generating loot, it then randomly picks one stack from the group (with equal priority; no interior weights).
This wouldn't be as convenient as simply using a tag for a stack id, but the more I think about this, the more I realize that there probably isn't a snowball's chance in hell you would want placebo stacks to work differently :)