some type of bug with the amount of wares being purchased by supply mule
Closed this issue · 6 comments
there were a lot of recent changes to supply mule for defining the amount of wares to purchase. Something is happening where what's printed to the log book is vastly different from what the mule actually purchases when it gets to the station. Need to figure out why.
I hammered this today and I cannot figure out what's going on. Everything looks fine until the trader gets to a station to make the first trade, then the next trade in the list has it's amount modified to something lower. But the demand on the original station is fine and the supply station has plenty of stock to fill the order. Something in a vanilla script seems to be the culprit IMO, trying to figure out what I can do about it.
So after a ton more hammering I found a couple of issues. One was that we really were not accounting for reservations properly. Another is that the desiredamount and offeramount are always different by one, with offeramount being 1 larger. It seems to be that case that when you use offeramount, you bring more wares than the buyer actually wants. However, in build storage, there is no off by one issue. So the only good way to deal with the combination of these issues is to use desiredamount and subtract off the amount of reservations. I'm also playing around with adding clamping to basically every trade.
I think it's now likely that I have some redundant logic in picking a trade, but I'm afraid to touch it with how finicky ego's system seems to be.
so currently you use something like:
[desiredamount, offeramount].min
then reduce by reservations
then clamp_trade to account for finances and by maximum cargo space?
today in my testing desiredamount seems to be accounting for reservations properly and it's always the same as offeramount - reservations. So I don't know what the hell I was seeing this weekend.
I'm thinking the code is getting into a state where there's a lot of redundant information that needs cleaned up, and I don't know that it makes sense to do that until your refactor has progressed. I just want to get a stable version into public before taking the ~days to deal with the refactor.
basically everything I was seeing this weekend is gone w.r.t desiredamount not accounting for reservations and not lining up with offeramount. So it appears that the change to $targetOfferedAmount can be undone.
closing for now