Yeah, ever since I (finally!) got clued into what the CT mainworld POP stat *actually* applies to (a planet & NOT the system), I've had a gripe.

ISTR that it was while playing CT Trav that I first heard the comment, "It is what it is"!   ;-)


On Tuesday, September 29, 2020, 12:47:43 PM MST, xxxxxx@gmail.com <xxxxxx@gmail.com> wrote:

On Tue, Sep 29, 2020 at 3:05 AM Phil Pugliese - philpugliese at yahoo.com (via tml list) <xxxxxx@simplelists.com> wrote:
These are yet more of the 'weirdness' that originates w/ the TU rule that the POP stat only applies to the "mainworld".

That system in the Trojan Reaches could just be one where gazillions of people live on one planet while (& who knows why?) the (highly automated?) starport for the system is located on another.
No hordes of transient contract labor from outsystem is actually necessary in this case. The insystem POP provides number of workers who rotate to & fro (maybe even on a daily/weekly/monthly basis? go figure!), in order to insure the smooth op of the starport.

Sure, they might be from somewhere in the system, or not, either way, they're not considered resident. It might well be a highport only setup too and do those count as living on the planet?

The text that went with it gave the impression that it was there to facilitate trade traffic *through* the system more than *to* the system (transient trade vs. trade destined or originating there). The millions of cargo handlers/port maintaners of the robotic sort was probably just a sci fi touch. This system seems at most to be a transhipment point and otherwise just a gas stop or resupply stop vs. an unloading destination.

The issue though is still that the Mainworld Pop digit does a lot of work (as it feeds into Government type.... which I get in a way, but if, as you say, there are large polities on other worlds in the system, THAT may well be more important for governance modelling).

Ultimately, the only thing that will give you much of an idea of what is going on in the system is at least a modest amount of text to tell you what the scoop is.

 
In any case, no more than ten folks live there permanently.
Must be a real 'hellhole' as, apparently, no one wants to live there permanently!    ;-)

A bunch of rich introverts who prefer the company of shipping robots? Maybe it's a cult or a fetish group.

 

-------------------------------------------------------------------------------------------------------------------------------------------------------

On Monday, September 28, 2020, 08:29:36 PM MST, xxxxxx@gmail.com <xxxxxx@gmail.com> wrote:


Well, I don't disagree that it will, but the original author seems to think that the table should look (in this instance) linear. 

(IMO: 10 landing pads is not even close to enough for a class A starport for a tens of billions of population planet. Maybe it should that number squared (100)). 

When I recall looking at the Highport in Dragon #59 (Exonidas Starport), it has a lot of pads. And it fit my idea of a large port. 10 reminds me of what I'd expect at a C Class. 

But the authors of this supplement seem to think a Starport upgrade are only worth 1 extra pad per level. 

B->A is worth one extra landing pad over B just like B is over C, etc. all the way down according to the authors. I'm just trying for the fix that fits their progression. 

The odd part is what if I have a type D port on a pop 2 planet. That's pop digit - 3. Does that mean you have -1 landing pads? (I'm assuming minimum one). 

If we look at the one crazy setup in the Trojan Reaches where it's a type A on a pop 1 world, it'd only have 1 pad. The logic folks on the list suggested was 'lots of transient contract labourers plus millions of cargo handling bots'. 

I can understand why they coupled population digit and landing pad count, but I think they're way out to lunch generally about the size and scope of larger population planets as far as the landing capacity they need. If you go with the 'heavy trade' model (vs. the 'bring in some antiquities, curiosities, and high value, low bulk goods only'), then you need a lot of pads. 

So if I were fixing this inconsistency while maintaining the out of whack numbers the whole scheme generates, I'd still preserve their table and edit the max pad count, but that's totally a subjective thing. 



-----
The Traveller Mailing List
Archives at http://archives.simplelists.com/tml
Report problems to xxxxxx@simplelists.com
To unsubscribe from this list please go to
http://archives.simplelists.com

-----
The Traveller Mailing List
Archives at http://archives.simplelists.com/tml
Report problems to xxxxxx@simplelists.com
To unsubscribe from this list please go to
http://www.simplelists.com/confirm.php?u=ckeZ4SpMkTqj0RuowdhoVbpeCyPfxFia