• Welcome to the new COTI server. We've moved the Citizens to a new server. Please let us know in the COTI Website issue forum if you find any problems.

Suggestion for T5SS and stellar data

Regardless, the Dalthor notation doesn't require symbols to indicate companion stars. Position alone is sufficient.

The appeal is a simple, clean, elegant format easy for humans and machines to parse.
 
Several different attempts at system/sector mapping have been XML native file formats, with ability to import/export flat text files.
Yes, and I am one of the people who made that attempt. I also know my attempt is no longer in a working state. So I'm wondering if you knew of anyone with a working example.

Robject's webapps often use YAML, which is a subset of XML

YAML is not a subset of XML. It is a superset of JSON, the Javascript Object Notation. Neither of which look anything like XML.
 
Out of curiosity, I wanted to see what the odds were of rolling different stellar configurations in T5. There are 54 different types of possible systems:

The is no example of a primary and Far companion with a close companion like: P [F (C)]

Is this a limitation of the T5 stellar generation process or overlooked by your generation?
 
Yes, and I am one of the people who made that attempt. I also know my attempt is no longer in a working state. So I'm wondering if you knew of anyone with a working example.
Rob Prior's Metator, from about 1998. OSX 8/9. (I hacked a datafile.)
 
The is no example of a primary and Far companion with a close companion like: P [F (C)]

Is this a limitation of the T5 stellar generation process or overlooked by your generation?

As far as I know, in T5 stars outside the primary -- that is, close, near, and far stars -- can only have stars in the companion orbit. (The terminology here is pretty confusing.)

So although the notation could handle something like P [F (C)] or P [ F {N}] or P {N (C)}, and I think those are possible in the real world, I don't think you can generate one with the T5 rules. I think you could have using GURPS Traveller: First In.

I'm really trying to dig down into T5 stellar generation, and was curious if someone can point me toward past discussions here or elsewhere on this subject.
 
Last edited:
Based on the last illustration, I came up with

P c (C) {N c}

since the dashed "orbit" seems to indicate primary and companion, with the 3rd star orbiting that pair as a close star, and then a Near with companion.

T5 doesn't really have an option for far stars to have anything other than a companion. Makes it easy on the referee, but something like

P [*F c {N}]

could be done using Dalthor Notation, indicating a primary, and a Far star with a companion, and a Near star orbiting that far pair. The MW orbits the Far/companion combination. (IMTU I decided to place the * in front of the relevant star)

Complex, cool, and considering the new discovery, possible. I don't see T5 adding that level of detail to a far system, but IYTU anything goes.

Happy Travelling!
 
Update to Posh field used IMTU

FWIW, I've added a character to the POSH originally described above...the original needed to add one more orbital position. I didn't account for a world orbiting a Close/Near/Far star.

Here is the updated version I'll be using, which will be handy once I start generating full systems:

Code:
Call it the PoSsh for extended generation
  - P: planet or orbital body type
   * = star
   m = mainworld
   p = planetoid
   i = iceworld
   r = radworld
   f = inferno
   b = bigworld
   w = worldlet
   n = inner world
   g = gas giant
   s = stormworld
   o = ring  
   a = asteroid belt
 - o: orbital position around the primary star (eHex value)
 - S: stellar orbit around a close, near, or far star (eHex value or "-")
 - s: satellite orbit, may be close or far (eHex value)
 - h: position related to the habitable zone
   i for inner
   - for HZ-1
   = for HZ
   + for HZ+1
   o for outer

There are no changes to my stellar notation at this time.
 
I noticed that using CODE tags around text can cause issues - apparently you cannot scroll and see the entire text. I'd have thought that it would size based on either the browser window width, or the width of the text.

I would like to post some additional things here, but if we cannot see everything in the block it isn't helpful.

Am I missing a better method? I thought about PRE and HTML tags, or even QUOTE, but thought I'd ask first.
 
I noticed that using CODE tags around text can cause issues - apparently you cannot scroll and see the entire text. I'd have thought that it would size based on either the browser window width, or the width of the text.

I would like to post some additional things here, but if we cannot see everything in the block it isn't helpful.

Am I missing a better method? I thought about PRE and HTML tags, or even QUOTE, but thought I'd ask first.

The ability to scroll within is governed by your browser, not the codebase here. I've always been able to scroll them in the past, but few use them.
 
IMTU change: POSH to PSsht

After thinking about my POSH field, and the updated version posted above, I've changed field names and order again.

The new one makes more logical sense, and allows me to sort on the field and properly list items in orbit around the primary.

Here is the latest iteration:

Call it the PSsht, used IMTU for extended system generation

Code:
- P: orbital position around the primary star (eHex value)
- S: Secondary orbit around a close, near, or far star (eHex value or ".")
- s: satellite orbit, may be close or far (eHex value)
- h: position related to the habitable zone
   i for inner
   - for HZ-1
   = for HZ
   + for HZ+1
   o for outer
   . for asteroid belt
- t: planet or orbital body type
   * = star
   m = mainworld
   p = planetoid
   i = iceworld
   r = radworld
   f = inferno
   b = bigworld
   w = worldlet
   n = inner world
   g = gas giant
   s = stormworld
   o = ring  
   a = asteroid belt

and some examples:

Code:
Bighex Hex  PSsht Name   UWP       Remarks                 {IX} (EX)    [CX]   N    B  Z PBG Wo Alle Orbits    Stellar                         
------ ---- ----- ------ --------- ----------------------- ---- ------- ------ ---- -- - --- -- ---- --------- -------------------------------
641801 0101 0..=0 A-0101 B6657B8-A Ga Ag Ri Tz             {4}  (C6B+0) [9B67] BCf  S    910 14 NaXX P... .... D
641802 0102 7...3 A-0102 D000BA8-7 As Hi Na In             {0}  (6A7-2) [CB65] BE        512 10 NaXX P... .... M9 V
641803 0103 0..=0 A-0103 B687CB8-5 Ga Hi Tz                {1}  (BB7+1) [9D17] BE   N    100 10 NaXX P... ..H. M1 V [M7 V]
641809 0109 3..+0 A-0109 C100889-7 Va Ph Na Pi Ho          {-1} (476-1) [4766] BDe  S    300  8 NaXX Pc.. ..H. K7 V M2 V [M0 V]
641813 0113 1.F+1 E-0113 E876565-2 Ni Ag Lk Tr Tz          {-2} (944-1) [3352] BC        703  7 NaXX P... .... M4 V
641814 0114 0..=0 E-0114 A6A1B74-A Fl He Hi In Tz          {4}  (4A8+0) [BF89] BEf  N    502  7 NaXX P... .... M4 V
641815 0115 3..=0 E-0115 B300CAE-B Va Hi Na In             {4}  (CB9-3) [CG5E] BEf  S  R 231 12 NaXX P.0. .... G5 V (M6 V)

I have NOT started my extended generation as yet. Still cogitating on exactly what and how I want the process to show. Bighex is specific to MTU -- it is my "superhex" number, correspond to 3-digit column and row in the sector grid I use.

I do plan to use the BIGHEX value as a seed to the random number generator; it'll allow me to generate consistent extended systems during the testing process.

More to follow as I get time to work on this.

I am still using my "dalthor notation" for stellar locations. It has been working pretty well for MTU, and does make things easier on players, too.

C u!
 
Last edited:
Back
Top