Passenger BTN calcs look wrong

[CyberiaResurrection]

Source material (GT: Far Trader, p17):

"The Bilateral Trade Number (p. 15) is also used to determine the volume of passenger traffic between worlds. Since passenger traffic is influenced by different factors than freight traffic, we use an Effective BTN for passenger volume. Effective BTN equals regular BTN with these modifiers: Each world that is a Rich (Ri) world: +0.5* Each world that is a subsector capital: +0.5 _Each world that is a sector capital_: +1

• Rich worlds are attractive tourist destinations due to their Earthlike environments. ** Capital worlds attract tourists and, more importantly, a steady flow of industry and government travelers doing the Imperium's business"

(Italics in original, I've added the bolding for emphasis. GitHub formatting has mangled the asterisk explanations)

Code in question:

    @staticmethod
    def get_passenger_btn(btn, star, neighbor):
        rich = 1 if star.tradeCode.rich or neighbor.tradeCode.rich else 0
        subsector_capital = 1 if star.tradeCode.subsector_capital or neighbor.tradeCode.subsector_capital else 0
        sector_capital = 2 if star.tradeCode.sector_capital or neighbor.tradeCode.sector_capital else 0
        other_capital = 2 if star.tradeCode.other_capital or neighbor.tradeCode.other_capital else 0

        passBTN = btn + rich + subsector_capital + sector_capital + other_capital
        return passBTN

As I understand the source passage:

• Two rich worlds should have 10x the passenger traffic between them (+1 BTN, +2 in PyRoute internals) that they would otherwise have if neither was rich.
• Similarly for two subsector capitals, mutatis mutandis.
• Two sector capitals should have 100x the passenger traffic between them (+2 BTN, +4 in PyRoute internals) that they would otherwise have if neither was a capital.
• By consistency with the previous arguments (is not addressed in the source material), two polity (ie, other) capitals should also have 100x the passenger traffic between them that they would otherwise have.

Going back to the trade codes, am I correct in understanding that other_capital subsumes sector_capital, and sector_capital in turn subsumes subsector_capital? Namely, only the highest grade of capital applies?

For instance, assume that Ex Parrot (Python 1128) is, for whatever reason, marked as both a sector and a subsector capital. All else equal, Ex Parrot and Randomworld would have only 10x the passenger traffic (+1 BTN) they would otherwise have, instead of 30x (+1.5 BTN) that a face-value reading of get_passenger_btn() would indicate?

To take things further up to stupid, drop in Fnordia (Woop Woop 3201) which is marked as all three (subsector, sector and other). As at current code above, passenger BTN between Ex Parrot and Fnordia would be calculated as +2.5 BTN (+5 in PyRoute internals) higher than otherwise. It should be +2.0 BTN (+4 in PyRoute internals) higher than otherwise.

[CyberiaResurrection]

Now to apply my understanding above to a bunch more cases.

I treated the input space as 8 independently-varying binary variables (is rich, is subsector capital, is sector capital, is other capital, across each of two stars, A and B). In the current setup, no more than two trade codes interact, and in my proposal above, no more than three do (the capital-related codes for a given star).

Because no more than three trade codes interact, I went for 3-way coverage (16 tests, covering all combinations of any 3 input variables) instead of exhaustive coverage (256 tests), using PICT to generate the test cases. I've also manually added the all-true and all-false cases.

Passenger BTN mods are in PyRoute's doubled format, to facilitate direct comparison with PyRoute code.

A - rich	A - subsec.	A - sector	A - other	B - rich	B - subsec.	B - sector	B - other	Rich	A - capital	B - capital	Total
false	false	true	false	true	false	true	true	+1	+2	+2	+5
true	false	false	true	false	true	false	false	+1	+2	+1	+4
false	true	false	true	true	false	true	false	+1	+2	+2	+5
true	true	true	true	true	true	false	true	+2	+2	+2	+6
true	true	false	false	false	false	false	true	+1	+1	+2	+4
false	false	true	false	true	true	false	false	+1	+2	+1	+4
false	true	false	false	false	true	true	true	0	+1	+2	+3
true	true	true	false	true	true	true	false	+2	+2	+2	+6
true	false	false	true	true	true	true	true	+2	+2	+2	+6
true	false	true	true	false	false	true	false	+1	+2	+2	+5
false	true	true	false	false	false	false	false	0	+2	0	+2
false	true	true	true	false	false	false	true	0	+2	+2	+4
true	false	false	false	true	false	false	true	+2	0	+2	+4
false	false	false	true	false	true	false	true	0	+2	+2	+4
false	false	false	false	false	true	false	false	0	0	+1	+1
true	false	true	true	false	true	true	false	+1	+2	+2	+5
true	true	true	true	true	true	true	true	+2	+2	+2	+6
false	false	false	false	false	false	false	false	0	0	0	0

[CyberiaResurrection]

@tjoneslo , any comment on this, or am I waay off in the bush?

[tjoneslo]

Your notes are correct, and the code is missing the "both" case.

In practice a world can only be marked as one kind of capital (subsector, sector, or other). Checking for the combinations isn't required. The code gets the connecting the two types correct, that is A (Cp) to B (Cs) should be +1.5 BTN (+3 internal).

[CyberiaResurrection]

It may be so in current practice, but it didn't seem like an overly good idea to rely solely on said practice remaining unchanged.

Frinstance, some wombat spinning up their own sectors and, since a sector capital almost always functions as the capital for its subsector as well, marking such worlds with both codes (and likewise for domain/province/polity capitals). But not always - there's at least an in-principle chance that the subsector capital might be a different world than the sector capital.

Before, that might have been problematic - now, it doesn't matter.