Setting a min-max for item rewards doesn't seem to work properly (Or is this unimplemented?)
Icebelly opened this issue ยท 5 comments
Attempting to set a min-max value for the rewarded items does not seem to work, this can result in epic level bounties giving far far more of lower tier item than intended.
Using the following in the rewards.json
{
"content": "dungeontactics:bag_quiver",
"amount": {
"min": 1,
"max": 16
},
"unitWorth": 400
},
You can't set a min-max for rewards, which is why it doesn't show up as an option (it is unimplemented, although that is on purpose).
There is one new feature that will be in the next update which will attempt to alleviate the problem that you are having: Weighted rewards. As you can see, as the value of the bounty goes up, the bounty will give you greater rewards (And the number of possible rewards goes up because you have enough "value" for more expensive items to be picked). However, that means that you can sometimes get an exorbitant amount of a cheap item because there is no min/max value. I agree that this is a problem.
The reasoning why I haven't implemented this yet is because otherwise you might not be able to find the necessary rewards to accommodate for the value of the bounties.
Example:
Bounties: (Stick [worth 10, amt: 1..16], Cobblestone [worth 25, amt: 1..16])
Rewards: (Iron Ore [worth: 200, amt: 4..16])
Imagine the algorithm creates a bounty that makes you go out and find 5 sticks and 3 cobblestone. That's a total worth of 50+75=125. Suddenly you are stuck in a situation where the lowest possible reward that you could get is 4 iron ore, with a value of 800. Therefore, suddenly the algorithm would give you a reward that is 6.4x higher than expected.
This could be easily avoided by adding another reward that is cheaper, and in practice may not be so bad, but this will only work well if the pack maker makes enough cheap rewards, so that you don't suddenly get a reward that's outrageously expensive.
Of course, there should be other rewards that could give you something with a lower value (maybe a gold nugget, anything cheaper, so that you aren't forced to give iron ingots), so if this occurs with the min/max system it becomes the fault of pack makers, because they set the min/max value incorrectly. Unfortunately, I see this problem being hard to easily diagnose for pack makers which is why I haven't implemented it. (They see that their rewards are much higher in worth than the objectives, not realizing that they've set incorrect min/max values so at minimum it might give higher rewards).
TL;DR: As the bounty and reward system gets more complicated, it does benefit pack makers more but more specificity makes it more difficult for the algorithm to find a balanced bounty.
@Icebelly What are your thoughts on this? I would be willing to add this, I'm just a little concerned about pack makers balancing the system (Although I do suppose it is in their hands if something goes wrong).
In general, I'd imagine bad math would just be the fault of the pack maker if they didn't double check everything. (In my case I'm making sure that there are certain bounties that are always worth more than the lowest tier reward.)
Also on the topic of weighted rewards, perhaps an additional system where certain rewards, or even wanted items, are only locked to specific tiers of bounties along with adding weights to items?
@Icebelly Currently, different tiers equate to more lucrative bounties (Higher tier = more money) to incentivize having some bounties be better than others. If bounties were restricted to tiers, and some tiers are more rare than others, then it's the exact same as adding a weight system.
In this case, I'll be adding a weight system so some rewards/bounties are more rare than others (Currently done, will be in next update) and GameStages support, so some bounties can be locked behind certain game stages, as defined by the pack maker. Hopefully that covers all of your use cases.
As for min/max values for rewards, you do have a point. I'll look into including that in either this next update, or the one after that ๐ฌ