T5SS: Parsing the Stellar Data

[fridge]

This is more or less my position, as well. Setting down the orbit numbers especially seems like a Lose.

I think we have to go back to the root reason for the whole project - to have a definitive set of data for future authors to base their work on without contradicting each other.

I think tying down those systems already mentioned in canon (once existing discrepancies are ironed out) is a good thing, but do we need to do it in this fashion? Would a simple extra data element referring to the canon version and later published compatable additions be sufficient? Anyone writing about that system thereafter is advised/warned of the existing material up front, any editors are clued in to what to check "facts" against. This has the benefit of the whole canon for the system being flagged, not just the astrography.

I think tying down the current unpublished systems to specific astrography will unnecessarily restrict those future authors and we could lose stories as a result. Once a system's details are canonized, add to the references data element for those that come after.

 

[dalthor]

With the possibility of 8 stars (!) in a system, I've been using the following, based on my keyboard, and using the asterisk (*) as the center. When you work away from the * on the KB, you get (, {, and [ in that order.

I also add a custom field AFTER the stellar data, which I call the POsH.

P = planet type where 0 is planet, 1 is close satellite, and 2 is far satellite
O is for orbit A-Z
s is the sign, - for HZ-1, blank for HZ, and + for HZ+1
H is the habitable zone, either 0 or 1 (optional)

Technically, you don't really need the H. If it is a satellite or planet, sign is blank and P tells you if it is a planet or not. If the sign is minus, it is HZ -1, and + is HZ+1. IF there is no sign, it is HZ (or satellite). Hmmm, maybe use = for HZ or satellite indicator.

It kinda looks like this:

Primary Companion (close comp) {near comp} [far comp] POsH

Finally, I use an * to tell me which star the MW orbits.

Some examples:

*K6-III (M1-V) {K0-V K6-V} 0G-1 >> 1 companion, the K6-V; planet, orbit G, HZ-1
F7-V {M1-VI} [*F5-VI] 1E 0 >> no companions, close satellite, orbit E, HZ doesn't matter
M0-V *M7-V 2T 0 >> far satellite, orbit T, HZ doesn't matter

M0-V *M7-V 2T= >> far satellite, orbit T, HZ doesn't matter

This probably doesn't help, but I like it.

 

[MichaelSTee]

Just throwing out ideas here.
I like having the orbit locations for stars. I would suggest a slash to separate companions, semicolons between different orbits, and parens for stars orbiting stars. Here's an example system:

G1 V/M3 V; 6-K0 V; 16-K1 V (3-M4 V)
The G1 V is the primary, with the M3 V as a close companion.
The K0 V is in orbit 6.
The K1 V is in orbit 16, and the M4 V orbits that in orbit 3.

If un-marked, the mainworld orbits the primary by default; if it orbited a star other than the primary, that star would have an asterisk behind it. (Personally, I would also like to see the orbit number for the mainworld in the mainworld data.)

If you don't like orbit numbers, but do like Close, Near, Far notations, then perhaps this:
G1 V/M3 V; NE-K0 V; FA-K1 V (CL-M4 V)
where CL = close, NE = near, FA = far
The G1 V is the primary, with the M3 V as a close companion.
The K0 V is Near.
The K1 V is Far, and the M4 V orbits that in Close orbit.

 

[dalthor]

P = planet type where 0 is planet, 1 is close satellite, and 2 is far satellite
O is for orbit A-Z
s is the sign, - for HZ-1, blank for HZ, and + for HZ+1
H is the habitable zone, either 0 or 1 (optional)

After consulting my code, an update to POsH, for those interested. I like the detail for my universe.

P = MW type where 0 is planet, 1 is close satellite, 2 is far satellite, and 3 is asteroid belt
O is for SOLAR orbit A-Z
s is for satellite orbit a-z if it is MW orbiting GG, or blank if P is 0 or 3
H is - for HZ-1, = for HZ, + for HZ+1, and blank for an asteroid belt

This is actually what I use now, my prior post was incorrect, which is what I get when posting from a sickbed. lol

I may update this to use a period (.) instead of a blank, to make it easier on myself.

Examples:

3M.. would be asteroid belt, solar orbit M, and ignore s and H
0C.- would be planet, orbit C, not satellite, and HZ-1

This might also be better for parsers

 

[OjnoTheRed]

There are a few good ideas for formatting here. But I am coming to the position that the only extra detail I really need is which stars are companion stars to each other. I like either the "+", "-", or "=" for these (plus represents "added together", and "-" or "=" represents "bonding" between this pair).

Specifying which star has the mainworld is too restrictive, and in some cases I disagree with the choice - why put the mainworld around a cold secondary when it's going to be tidally locked and covered in ice / melted stone when it's an "Ag Ri Ga" world. Won't be much of a garden nor grow many crops!

Which brings me to my second bug bear. In detailing Natoko I realised this seemingly terran-like world is in fact quite strange because its star is a ubiquitous red dwarf with HZ=0 and so the world is tidally locked.

How many Ag, Ri and Ga worlds turn out to be tidally locked? I did some analysis. There are 114 worlds that are Ag, Ri and Ga (or more than one).

31 of these are tidally locked to their parent star. If it is an intended feature of the OTU that around one quarter of our food-bowls / most fit for human worlds are in fact half-baked half-frozen, then this is no problem. But here is the list of worlds that are tidally locked (M0 V-K9 V parent star):

0103 Errere B563664-B Ni Ri
0133 Emape B564500-B Ag Ni
0301 Rio C686648-8 Ag Ni Ga Ri
0425 Engrange C554769-8 Ag
0538 Wonstar B555741-7 Ag
0605 Algebaster C665658-9 Ag Ni Ga Ri
0618 Dekalb EA8A799-6 Oc Ri Wa
0710 Stave E7667A8-2 Ag Ga Ri
0904 Chwistyoch B766766-A Ag Ga Ri
0921 Hrunting B563747-9 Ri
1006 Emerald B766555-B Ag Ni Ga
1123 Joyeuse B564778-A Ag Ri
1138 Tarsus B584620-A Ag Ni Ri
1204 Mongo A568685-A Ag Ni Ri
1340 Motmos B68468B-5 Ag Ni Ri
1434 Tarkine C566662-7 Ag Ni Ri
1523 Durendal B687734-B Ag Ga Ri
1525 Sting B645796-A Ag
1706 Alell B56789C-A Ri
1924 Ianic E560697-5 De Ni Ri
2112 Rech D9957AA-6 Ag
2402 Heya B687745-5 Ag Ga Ri
2414 Tureded C565540-9 Ag Ni
2419 Cogri CA6A643-9 Ni Oc Ri Wa
2602 Corfu C895674-8 Ag Ni
2701 Lablon B646589-A Ag Ni
2715 POROZLO A867A74-B Hi Ga
2833 Pepernium D567530-3 Ag Ni
2933 Raydrad E99467A-6 Ag Ni
3118 Cipatwe B55879A-6 Ag
1529 Steel E655000-0 Ba Ga
1531 Dawnworld E885000-0 Ba Ga

Just one last thing. I notice Barren worlds have HASS of [0000]. This is common sense; but the rules probably need to remark under HASS that Barren and Dieback worlds have HASS of [0000].

 

[inexorabletash]

From Ojno's post above, your Capella would be:

"G8 III+2=G1 III 17=M1 V+M5 V@"

If I'm understanding his suggestion and your proposal correctly.

I'm not a fan of the combined close-companion-and-orbit-number syntax - I'd pick one or the other and defer to the rules.

It does hint that (at least within this syntax family) close companions could be prefixed rather than joined with the primary, for consistency.

 

[tjoneslo]

Which brings me to my second bug bear. In detailing Natoko I realised this seemingly terran-like world is in fact quite strange because its star is a ubiquitous red dwarf with HZ=0 and so the world is tidally locked.

How many Ag, Ri and Ga worlds turn out to be tidally locked? I did some analysis. There are 114 worlds that are Ag, Ri and Ga (or more than one).

On a partly unrelated note, I got this article on the affect of planetary rotation on habitability. Turns out the planetary atmosphere makes the worlds, even tide locked ones, much more habitable than originally thought. So having rich, garden worlds tide locked to a small primary is still very possible.

 

[inexorabletash]

And what TL is a mirror at L3? Should only be 10 or so, which could vastly increase the usable surface.

 

[BillDowns]

Honestly, this is starting to look like regular expressions or APL.

First, I would note that a space is a natural delimiter, so I suggest removing from the notation for a single star.

Second, as pointed out in several posts, you need a way to designate companion, close, near and far stars.

Third, you still need to designate which star holds the home world.

Fourth, the Orbit Number would be nice to add in.

So, my suggestions:

1. Use a space between each star.
2. Companions are enclosed by parentheses.
3. Close, near and far stars are denoted by a prefix thus: "c-", n-", f-".
4. If used, Orbit Numbers shold be enclosed by square brackets and replace the close-near-far indicators.
5. The Homeworld's star is suffixed by an asterisk unless there is only 1 star.
6. If desired, the numbers of planets can be further suffixed by using a colon and the number of planets

Deneb (Dene 1925) becomes "A2Ia"
Terra (Solo 1827) becomes "G2V"
Antares (Anta 2421) becomes "M1Ib* f-B3V" or "M1Ib* [13]-B3V"
Regina (Spin 1910) becomes "(F7V BD)* f-M3V" or "(F7V BD)* [16]-M3V"
Marhaban (Empt 0426) becomes "G4V* n-M0V f-(M2V M6V)" or "G4V* [8]-M0V [15]-(M2V M6V)"
Castor (Solo 2339) becomes "(A1V M5V) n-(A2V M2V) f-(M1V M1V)*", or "(A1V M5V) [10]-(A2V M2V) [14]-(M1V M1V)*"
Capella (Solo 1440) becomes "(G8III G1III) f-(M1V M5V)*" or "(G8III G1III) [17]-(M1V M5V)*"

 

[aramis]

Honestly, this is starting to look like regular expressions or APL.

First, I would note that a space is a natural delimiter, so I suggest removing from the notation for a single star.

The space is part of the standard stellar data formats, which is set by the IAU.

This seems to be changing in current datasets, however.

 

[BillDowns]

I won't dispute your point, Aramis, but it really points out how certain scientific communities get stuck on some obscure point which re-inforces their feelings of superiority.

English readers, well really everybody that uses an alphabet, are trained from the beginning to parse blocks of "code" (i.e. words) on white space. Trying to overcome that is a major obstacle.

Instead, embrace and incorporate that training.

 

[inexorabletash]

First, I would note that a space is a natural delimiter, so I suggest removing from the notation for a single star.

I'd prefer that anything we come up with is a superset of "legacy" data, so we're stuck with spaces.

1. If used, Orbit Numbers shold be enclosed by square brackets and replace the close-near-far indicators.

Enclosing the additional data in brackets is a nice idea.

Let me riff on that and suggest that we make location a suffix on the plain stellar data:

• * = mainworld - can go on either the first or second star in a companion pair
• [ number ] = orbit number
• [ number / number ] = subsidiary orbit
• [ 'companion'] [ 'close' ] [ 'near' ] [ 'far' ] if the specific orbit isn't known
• space between the star and suffix is optional, but preferred w/ brackets
• the same orbit listed twice indicates the stars are paired (i.e. companions)

Deneb (Dene 1925) becomes "A2 Ia"
Terra (Solo 1827) becomes "G2 V"
Antares (Anta 2421) becomes "M1 Ib* B3 V [13]"
Regina (Spin 1910) becomes "F7 V* BD [companion] M3 V [16]"
Marhaban (Empt 0426) becomes "G4 V* M0 V [8] M2 V [15] M6 V [15]"
Castor (Solo 2339) becomes "A1 V M5 V [companion] A2 V [10] M2 V [10] M1 V [14] M1 V [14]*"
Capella (Solo 1440) becomes "G8 III G1 III [companion] M1 V [17] M5 V [17]*"

This has the advantage that if you strip out * plus anything in [] you get the legacy format.

 

[EDG]

First, yes, it is actually that EDG. Before you all pull out your guns and shoot me in the face, I am actually allowed to be here again!

First, as far as I am aware, there is no longer any obstacle (from me) preventing T5 from using the bracketed Stellar Format that I came up with and that was used in Bearers of the Flame. So is there still any reason to come up with an alternative?

Honestly, from what I've seen here, I would really recommend sticking with the bracketed format I came up with. All these 'ats', slashes, plusses, minuses, orbit numbers, ampersands or whatever else you've come up with are just turning it into an unreadable number/symbol salad which is not going to be readable or accessible to most people.You really don't need to condense every single bit of information into the UWP or stellar data!

Also, I understand that you've got another orbit category in T5 now, which as someone pointed out earlier you can just use {curly brackets} for.

 

[OjnoTheRed]

I like your thinking, inexorabletash - most readable format with the desired detail so far; we could come up with an agreed abbreviation for "companion" that's readable ("cmp"? "cmpn"?).

I'm still not convinced that we need to specify which star has the main world; referees detailing a system can make this choice based on the rules and campaign needs.

 

[OjnoTheRed]

On a partly unrelated note, I got this article on the affect of planetary rotation on habitability. Turns out the planetary atmosphere makes the worlds, even tide locked ones, much more habitable than originally thought. So having rich, garden worlds tide locked to a small primary is still very possible.

Great blog! Has exactly the kinds of things I was looking for. I was wondering, in particular, about convection in a tidally locked world because surely high temperatures on one side would circulate to the other side? And what might weather patterns look like on such a world? Thanks heaps!

 

[OjnoTheRed]

OK, these aren't "clangers" but are interesting results that need looking at.

tjoneslo has pointed me towards convincing reasons that a world being Tz on the one hand and Ag, Ri or Ga on the other is not necessarily a problem.

But the picture of Ag, Ri or Ga worlds was still worth checking out for possible star-related reasons this worlds might really be cinders.

There are three results that are interesting:

0425 Engrange C554769-8 Ag { 0 }(A68+1)[8769] M1 V 1@/M3 V
The HZ of the M3 V is Orbit 0, which in turn orbits another red dwarf just outside the HZ; how might this work out? It might be OK, but needs another look. I would recommend moving the M3 V with the main world out another orbit or 2 which makes the world interesting rather than possibly not able to be an agricultural world because of temperature or tidal forces.

0605 Algebaster C665658-9 Ag Ni Ga Ri { 1 }(955+1)[6759] @/M0 V 2/M1 V
In a similar vein, this "Garden" world is huddled up close to a colder star, with another red dwarf orbiting a fairly close distance out. How does this work in terms of tidal forces and temperature? This is less problematic that Engrange and so is more likely to be OK.

2735 Conway D894586-7 Ag Ni { -2 }(742-3)[4346] @/F0 V 5/M0 V
This last world is just interesting. The HZ of the primary is orbit 6, but there's a red dwarf at orbit 5 which would possibly create interesting seasonal variations although the distance between orbits 5 and 6 is pretty big.

One last thing that I'll put here in lieu of another obvious forum. I have attached the spreadsheet I've used to do some of this analysis. There's an analysis of the status of native intelligent life in it. The Spinward Marches, on current data, has 118 Sophont species, 10 Exotic Sophont species and 12 Transplant Sophont species. That's at least 128 Sophonts to generate - this makes the Spinward Marches a hugely diverse place; does this challenge the overall notion in T5 that chartered space is diverse but human-dominated?

 

[tjoneslo]

M1 V 1@/M3 V
The HZ of the M3 V is Orbit 0, which in turn orbits another red dwarf just outside the HZ; how might this work out? It might be OK, but needs another look. I would recommend moving the M3 V with the main world out another orbit or 2 which makes the world interesting rather than possibly not able to be an agricultural world because of temperature or tidal forces.

0605 Algebaster C665658-9 Ag Ni Ga Ri { 1 }(955+1)[6759] @/M0 V 2/M1 V
In a similar vein, this "Garden" world is huddled up close to a colder star, with another red dwarf orbiting a fairly close distance out. How does this work in terms of tidal forces and temperature? This is less problematic that Engrange and so is more likely to be OK.

2735 Conway D894586-7 Ag Ni { -2 }(742-3)[4346] @/F0 V 5/M0 V
This last world is just interesting. The HZ of the primary is orbit 6, but there's a red dwarf at orbit 5 which would possibly create interesting seasonal variations although the distance between orbits 5 and 6 is pretty big.

These are all interesting cases. If you have access to GT:First In, it contains some rules for calculating the effect of the luminosity of the companion star. The temperature calculations are on P. 74-75, and you will need to reference the stellar characteristics table on P. 50. Do the calculation twice, once for just the primary, once for the companion at closest approach.

Calculate the climate for each of these inputs separately.

So when the companion star is on the far side of the system, the planet's climate will be the what you calculate from the primary alone.

If the companion climate is two less than the primary, there won't be much of an affect on the climate (star is too weak/far to have much of an effect). If the climate is one less than the primary, it boost the climate by one level on closest approach. If the climate is equal, it will boost the climate by two levels.

If the companions climate is greater than the primary's (unlikely but possible), reverse the above calculation.

 

[whulorigan]

TNE:1248 Parsing Format - modifications?

First, as far as I am aware, there is no longer any obstacle (from me) preventing T5 from using the bracketed Stellar Format that I came up with and that was used in Bearers of the Flame. So is there still any reason to come up with an alternative?

Honestly, from what I've seen here, I would really recommend sticking with the bracketed format I came up with.
.
.
.
Also, I understand that you've got another orbit category in T5 now, which as someone pointed out earlier you can just use {curly brackets} for.

My understanding of the published TNE:1248 Format is as follows:
(Note: I am going to use the term "companion" (in all lowercase letters with close/near/far designator) to denote any non-primary star in the system. I will use "Companion" (Capital "C" - Underlined) for a proper "within Orbit-0, almost touching" Companion Star.)

[FONT=arial,helvetica]TNE:1248 Format:

[/FONT] 1) In multi-star systems, the asterisk (*) notes the star that the Mainworld orbits.

2) Parentheses "()" around two stars denote Companion stars of one-another. They are in such close proximity that the planetary systems orbits the combination.

3) Square brackets "[]" denotes a Far-companion to the primary star. Each Far-companion can have its own planetary system, and they are too far away from each other to directly influence one another. They are effectively independent star systems in the same hex. It usually takes a micro-jump to travel between them.

4) Stars simply listed in order (i.e. without parentheses, braces, brackets, etc) denote what are called Close-companions (Orbit 0-5) & Near-companions (Orbit 6-11) in T5. The smaller stars can have their own planetary systems, but they have hard limits on their system-sizes. It is always at least theoretically possible to travel between the stars using normal space drives.

Brackets and Parentheses can also be nested as necessary to denote more complicated configurations.

Some people have expressed a preference for Orbit# to be designated in the stellar-parsing information. Is there an optional modifier we can add to the above system elements that would detail this information as well (i.e. optional because not everyone always wants to have this level of granularity - and also because this will allow FFE and/or publishers to leave the data somewhat more "generic", pending later more extensive system development)?

If I use "O" to denote Orbit #, what if we add a "O/" or "O-" before a star, or "-O" after a star? (Which can be omitted if desired).

Are there better ways to do this for those who want the added info?

Should we add braces "{}" to designate either Close-companions (Orbit 0-5) or Near-companions (Orbit 6-11)? Is it necessary?

What are people's thoughts?

 

[tjoneslo]

Honestly, from what I've seen here, I would really recommend sticking with the bracketed format I came up with. All these 'ats', slashes, plusses, minuses, orbit numbers, ampersands or whatever else you've come up with are just turning it into an unreadable number/symbol salad which is not going to be readable or accessible to most people.You really don't need to condense every single bit of information into the UWP or stellar data!

I completely support this point of view. There are too many obscure code references scatted throughout the T5 book as it is. Every time you add a encoding system to data, you loose one more user of the system.

Second. This is the 21st century. Data storage is cheap. Why are we trying to come up with a data encoding scheme designed for computer system 50 years old?

Third, If you are going to do enough data generation to place the stars in the system, why not take the extra 30ms and put the rest of the planets too.

So write them out as
<primary> O1 O2 O3 O4 O5 O6 ... O19 O20 --- <Far companion> O1 O2 O3 ...

and encode each orbit as 3 character code:

asb- Asteroid belt - Main world
ptb - Planetoid belt - non main world
Nwd - World of diameter N where N is 1 to A in size
Nhw - Huge world where N is B to K in size
sgg - small gas giant
lgg - large gas giant
BD - Brown Dwarf star
M2 V - M2 V star (space or no space optional)

So Terra (Solomani rim 1827) would be:

G2 V 1wd 8wd 8wd 3wd ptb lgg sgg sgg sgg

 

[OjnoTheRed]

These are all interesting cases. If you have access to GT:First In, it contains some rules for calculating the effect of the luminosity of the companion star. The temperature calculations are on P. 74-75, and you will need to reference the stellar characteristics table on P. 50. Do the calculation twice, once for just the primary, once for the companion at closest approach.

Calculate the climate for each of these inputs separately.

So when the companion star is on the far side of the system, the planet's climate will be the what you calculate from the primary alone.

If the companion climate is two less than the primary, there won't be much of an affect on the climate (star is too weak/far to have much of an effect). If the climate is one less than the primary, it boost the climate by one level on closest approach. If the climate is equal, it will boost the climate by two levels.

If the companions climate is greater than the primary's (unlikely but possible), reverse the above calculation.

I don't have GT, but the MegaTraveller World Builders' Handbook (my very battered copy!) has a similar process; I might do these calcs if I have time. The proviso is that the science behind the MT WBH is now very out of date and it was an approximation to begin with.

In relation to formats, it's not that 21st century computers can't cope with a bit of complexity, but I'd like to keep formats such that someone can do it with pencil and paper without too much of a headache. My position is still that only showing which are the "capital-C" Companions of the Primary, Close, Near and Far stars is the only thing that is necessary, and updating "Dwarfs" (DM etc.) to Brown Dwarfs or a proper spectral classification.