/ OpenTTD Public

Closed

# Change: Distribute left over cargo to stations according to the highest remainder #8398

## Conversation

This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters

### SamuXarick commented Dec 19, 2020

Instead of distributing the cargo among the best rated stations, distribute it according to the highest remainder.

### SamuXarick commented Dec 20, 2020 • edited

My idea here was to change the logic on what to do about the missing cargo that can originate from "a / b" division.

The original code rewards an extra cargo unit to stations that have the highest rating for that cargo type, but this approach disregards what I'm calling of "remainder". The highest rated station could, for example, be receiving 361/2=180 units with a rating of 200, and the second highest could be receiving 482/3=160 with a rating of 190. The remainder is, however, not tracked.

My code adds the ability to track the remainder of the a / b division. But since this value can't be simply a % b due to the multitude of values that b could have in different instances, I had to come up with a solution to make different remainders equiparable. That's when (a % b) / b came up. This would result in a value in the range [0,1[, which resembles the fractional part of a decimal number. However, due to how interger division works, the result is always 0. Scaling (a % b) / b by 100 would result in getting a fractional part of two decimals, but this didn't look like it had the precision it needed, so I went up scaling it up further to a maximum of a 16-bit value, hence the 65535 * (a % b) / b.

With equiparable remainders, going back to the 2 stations mentioned above, we have:

Rating Units moved (a % b) / b with 2 decimals Normalized remainder
200 361 / 2 = 180 0,50 32767
190 482 / 3 = 160 0,66 43690

Now, even though the 2nd station has less rating (190) than the 1st (200), and less cargo moved (160+0,66 = 160,66) than the first station (180+0,50 = 180,5), 0,66 is closer to 1 than 0,50. And that's the basis of the logic of how the extra unit of cargo is added.

### SamuXarick commented Dec 25, 2020 • edited

 Worst case station scenario file for testing: single house.zip 1 house covered by 124 stations

force-pushed the distribute-rounding-cargo-bits-alternative branch from `95d314f` to `35f4a85` Dec 25, 2020
force-pushed the distribute-rounding-cargo-bits-alternative branch 3 times, most recently from `2ade8c3` to `6747912` Jan 11, 2021
force-pushed the distribute-rounding-cargo-bits-alternative branch from `6747912` to `abc258a` Jun 6, 2021
force-pushed the distribute-rounding-cargo-bits-alternative branch from `abc258a` to `de7d37a` Aug 3, 2021

### ldpl commented Nov 26, 2021

 Matt Parker just made a video on station cargo distribution: https://www.youtube.com/watch?v=GVhFBujPlVo TLDR Distributing by remainders is not "fair" either, it still favors higher ratings just in a more roundabout and random way.

``` Change: Distribute left over cargo to stations according to the highe… ```
``` 904aa5e ```
```…st remainder

Instead of distributing the cargo among the best rated stations, distribute it according to the highest remainder.```
force-pushed the distribute-rounding-cargo-bits-alternative branch from `de7d37a` to `904aa5e` Jun 12, 2022

### 2TallTyler commented Nov 7, 2022

 I don't see a need for this change. It's not fixing a bug, just changing how something works. The change only makes a tiny difference and only in edge cases. With no real interest in two years, I'm going to close this PR. As always, if someone disagrees, feel free to reopen. 🙂

closed this Nov 7, 2022