LootTablePredicate for the number of times a chest has already been opened
LTCatt opened this issue ยท 9 comments
Structures such as dungeons, mines, etc. The more players have explored them, the safer the place has become. This allows later players to collect large amounts of loot without doing anything, and makes the pioneers feel unfair.
I hope to add a configuration so that after several players open the chest, it will not generate loots for other new players.
Or maybe another configuration: The more players who have opened this box, the less loots there will be in the box. For example, the first drop is 100%, the second 70%, the third 49%, and so on. You could randomly select each slot once to see if the item of this slot should be cleared.
Thank you very much!
Could you tell me how soon this feature is scheduled to be added?
My modpack is about to be released. I'm still waiting for it so long...
Thanks! :D
While I appreciate the concept, this is specifically what Lootr was designed for: preventing people from having to perform extraneous world generation in order to access loot chests for mods that gated progress behind loot found in aforementioned chests.
Difficulty scaling/safety was never really a consideration from the start.
I'm not really sure the best way to handle this. I feel like an external add-on would be a better option, perhaps a forge event that fires when loot is about to be generated...
I added some huge dungeons to my modpack, and now the situation is that the first player will deal with most mob spawners and traps, and light up torches... After many challenges, he will get some loot. But later players only need to walk from the first floor to the last floor in three minutes, and they get exactly the same loot.
It's going to make those who deal with the greatest danger feel frustrated and unfair. Other players will also lose their incentive to explore new dungeons: they just have to wait for a poor guy to solve all the dangers, and then they can spend two or three minutes opening all the chests.
The above description may be exaggerated, but this problem does exist, so I'm considering how to modify the mechanism of Lootr to solve this.
Adding loots may be difficult for a mod, so perhaps a better way is to provide options to reduce loots. If necessary, modpack makers can also modify the LootTable to increase loots.
However, I think about it carefully... It may be too complicated to add a series of configuration options to control a series of parameters such as decrement method and minimum value. Maybe a better way is to provide a list in the config, and determine the ratio of loot each player gets according to the value in the list.
For example, [1.00, 0.50, 0.35, 0.20] means that the first player can get 100% of the items, the third player can get 35%, and from the fourth player, everyone can only get 20% of the minimum.
(It would be better if a new texture could be added to make a certain distinction between chestes that have never been opened and chestes that have been opened by other players...)
On the problem of algorithm... Maybe you can modify the generated items after the loot is actually generated?
And... I've come up with a more reasonable algorithm to reduce the drop by a certain proportion.
For example, there are 20 iron ingots and 2 gold ingots in a chest. If each slot has a 60% chance to be retained, it means that the player has a 60% chance to get 20 ingots and a 40% chance to have no ingots. In the worst case, they have a 36% chance of getting nothing. It seems a little strange.
A better way might be to multiply the number of items in each slot by 60%, and then round the decimal parts randomly. In the above example, this algorithm allows players to get 12 iron ingots and 1.2 gold ingots. And "1.2 gold ingots" means that there is a 20% probability to obtain 2 gold ingots and 80% to obtain 1.
This will be slightly more complex in algorithm, but it will significantly reduce the variance of the number of items and prevent players from returning empty handed.
Well, it's a bit too much... And thank you for listening to me :D
While I appreciate the intent, this is well beyond the scope of the mod. About all I could do would be to fire a few events whenever a loot table is about to be fired (so that modifications can be made to the loot context), and another for when the loot is actually about to be inserted into the container (so that modifications can be made directly). Those events would include information about how many people have opened the container before, etc.
That would allow someone to create an add-on mod that hooks into the Lootr API and then perform the modifications that they want.
Beyond that, that's a level of complexity that I'm not willing to dip my toes into. I accept that your problem exists, but Lootr is the solution to a different problem (one of expanding server sizes/lag/chunk generation).
The point of giving you events would mean you don't need to make a fork.
EDIT: And also keep in mind that you won't be able to redistribute a fork on CurseForge/include it in your modpack easily -- not to say you can't, just that it does become painful. Hence why I was suggesting an add-on mod.
So, you will need someone to write a mod for this, however I'm hopeful that I've made everything clean enough that it can be reasonably configured. I can't release it, but I'll try to get the API jar up on Maven.
The reason I wanted to make a new mod was because we didn't have much experience in mod development... In other words, if we want to make an Addon mod, we need to figure out how to create new projects, how to call the API, etc., which is quite difficult for us. However, if you are modifying existing mod code, it will be much easier.
But since you don't recommend it, I won't make a new one. Sorry!
Developing a new mod from scratch is still hard for me... Perhaps add a Loot Table Predicate so that modpack authors can directly check the number of people who opened the chest in the Loot Table and modify the output? This should be an easier option for modpack authors to use.
https://minecraft.fandom.com/wiki/Predicate
Thanks :D