Keg "sell excess" calculations does not account crop quality

[jaimeiturriaga]

There are cases where adding kegs as an option results in less profit than just selling the crops outright


This is because the keg calculations are not considering crop quality and are instead using the base price of the crop.

My suggestion is to replace

var cropPrice = 0;
if (options.sellExcess)
    cropPrice = options.skills.till ? crop.produce.price * 1.1 : crop.produce.price;
netIncome += cropsLeft * cropPrice;

with

if (options.sellExcess) {
  var rawIncome = 0
  rawIncome += crop.produce.price * crops_left * ratioN;
  rawIncome += Math.trunc(crop.produce.price * 1.25) * crops_left * ratioS;
  rawIncome += Math.trunc(crop.produce.price * 1.5) * crops_left * ratioG;
  rawIncome += crop.produce.price * 2 * crops_left * ratioI;
  if (options.skills.till) {
      rawIncome *= 1.1;
  }
  netIncome += rawIncome 
}

Fyi this is a hacky solution. A DRYer one would be splitting out the crop selling logic so it can be reused.

[doodlebunnyhops]

I've actually been taking a harder look at how quality is distributed - it's also why I didn't include the math for selling excess by quality and defaulted excess to normal quality when I worked on this with @Thorinair.

Backing up for a moment on the original ask here - @Thorinair I'd be happy to re-work the logic on quality outcome. The issue is it uses probability and not event driven conditional probability. Then apply quality to all produce results. Any thoughts takeaways?

[Thorinair]

@doodlebunnyhops it is indeed quite a messy problem. Making it event driven would be messy as it would require simulation day-by-day, and would also result in random results each time, and not a proper average. I think the cleanest solution would be to keep it as averages, and implement the existing code into the remaining crops calculation.

Complication here is that we cannot just put the excess into the formula. Most players would first process the normal value crop, and sell the higher valuable ones, as that makes most sense for profit. This means we first need to calculate the amounts of crops (maybe whole numbers?) and then "spend them" on making the artisan goods. Essentially, the whole code would have to be reworked...

The only solution I see here is to either keep the excess sold to just normal, or do a compromise and process it with the existing code anyway.

[doodlebunnyhops]

I dabbled with this and while it certainly muddied up the sections for dehydrator specifically byHarvest - it's doable. It also looks like byHarvest could easily extend to other artisan goods down the road (more so if they are limited by equipment) but for this take I stuck with what is current.

So #80 adds a new button if you want to see a predictive like result and can recalculate it to see how the results change.

More importantly to the original ask - it properly sells excess by crop quality, regardless if using predictive model or not.