Bug: Usage fees for applying more unpaid candles are multiplied by amount once more.

[觉]

I encountered this in one of my games on hardfought. I picked up 17 candles, which cost 300+ dollars around, I wanted to apply bags but accidentally applied candles. Then I owe Izchak 5k+ dollars, while I have only 2k in my wallet. Then I did something wrong and lost that game :P. I find it interesting :).

I checked it locally, though my local build is a version a year ago, so here's the screenshot, buying 18 candles needs 234 zorkmids, applying them, then owing Izchak 4263 zorkmids, about 18 times.

I then tried other amounts and found that the amount of candles is multiplied twice when counting the usage fee.
1 candle costs 7 zorkmids, and applying 1 candle makes me owe the shopkeeper 7 zorkmids.
2 candles cost 14 zorkmids, but applying 2 candles makes me owe the shopkeeper 28 zorkmids :P, i.e. 2 * 2 * 7
And applying 3 candles makes me owe 63 etc.

Applying 100 unpaid candles would cost 70000 zorkmids lol.

[Michael Meyer]

The problem is that bill_dummy_object attempts to take into account any pricing differences between the original and dummy object by adjusting the price based on unpaid_cost(otmp, FALSE), but unpaid_cost takes quan into account while the actual entry in ESHK->bill doesn't (it records individual cost and quan separately). So it ends up inserting the cumulative price into the slot where the individual price goes, and it's then remultiplied by obj->quan. So one simple fix might be:

diff --git a/src/mkobj.c b/src/mkobj.c
index 337b08126..fc621ba48 100644
--- a/src/mkobj.c
+++ b/src/mkobj.c
@@ -711,6 +711,7 @@ bill_dummy_object(struct obj *otmp)
 
     if (otmp->unpaid) {
         cost = unpaid_cost(otmp, FALSE);
+        cost /= otmp->quan;
         subfrombill(otmp, shop_keeper(*u.ushops));
     }
     dummy = newobj();

(Or to be totally 100% sure this is safe and doesn't produce the wrong result, you could add a param to unpaid_cost to request the cost of an individual item/not multiply by quan)

[Michael Meyer]

#1237 is an attempt at the obviously much more complicated, but maybe more future-proof way to fix it. The one-liner doesn't really need to be submitted as a PR of its own I think :-)

[觉]

Thank you for your quick and great fix👍, and I understand the bug code now.