• 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.

Orbit notations?

RogerD

SOC-12
What formats or conventions are out there for notating an orbit? All I have typically seen are listing of orbit numbers, sometimes with a decimal. What I'm after is some form of encoding that can more precisely locate a body within a system on the same line as the planetary data. Most of the notation I've seen uses multiple lines to indicate this kind of information.

Example 1: Gagamshir orbits SGG Elazair (at 125 diameters) which orbits Darida (in orbit 2) which orbits Lusor (at 5000AU/Orbit 16) in the Regina system.

I've been thinking along the lines of a code like "G2/P", using extended hex to indicate nested orbit numbers and a separator to let you know it is a satellite. That doesn't account for fractional orbits though.

Another case is to identify a close companion star, which would need a symbol (I thought of a - sign) or possibly just combine it in the original star listing like F7V+DM

Does anything like this exist already?

I'm also interested to know if there is existing work to more fully define orbits and how to record that. I know about the eccentricity rules but have never seen any notation to record it. There are real formats out there that more fully describe orbits with 6 or 7 parameters, but that's likely overkill here.
 
A more complete example.
Code:
1910      Lusor     F7V
1910-#    Speck     DM
1910-4/L  Regina    (...rest of UWP)
1910-G    Darida    M6V
1910-G2   Elazair   SGG
1910-G2/P Gagamshir F534328-A M

Pros:
- sorts well
Cons:
- Each line does not stand on its own. From that last line you know there is a star at G2 but not which one.

I also played with identifying the stars by letter in the order listed in the Stellar data of the Second Survey Format
Code:
1910-A      Lusor     F7V
1910-B-#    Speck     DM
1910-A-4/L  Regina    (...rest of UWP)
1910-C-G    Darida    M6V
1910-C-G2   Elazair   SGG
1910-C-G2/P Gagamshir F534328-A M

Pros:
- if you have the list of stars, you know which star is being orbited.
- each line stands on its own with Second Survey Format.
Cons:
- will not sort well - Speck will show up in the list after Regina.

You could fix the sorting issue by adding a column for the nearest star.
Code:
1910      A Lusor     F7V
1910-#    B Speck     DM
1910-4/L  A Regina    (...rest of UWP)
1910-G    C Darida    M6V
1910-G2   C Elazair   SGG
1910-G2/P C Gagamshir F534328-A M

Pros:
- if you have the list of stars, you know which star is being orbited.
- each line stands on its own with Second Survey Format.
Cons:
- extra column may be overly finicky.
 
Non-intuitive, I don't get what the G stands for and the '/' is unnecessary.

In a multiple star system you need:
Which star?
Which orbit?
Which sub-orbit (moon orbit)?

With a letter or number for each, we get an UWP like structure. I would (as per tradition) use different alphabets to make it obvious which letter is which. Since moon orbits can have very large numbers, I would break it out into a separate column.

Code:
                           Code                              Travelleresque
1 Which star?              Greek miniscule (α,β,γ,δ,...)     EHex (0,1,2,3,...)
2 Which orbit?             EHex (' ',0,1,2,3,...)            EHex (0,1,2,3,...)
3 Which moon number?       ELetter (' ',a,b,c,d,e,...)       EHex (0,1,2,3,...)

Moon orbit number?         Three column number               Three column number


Example (Data from LBB6):
Code:
Orbi Name        UWP          Sub-orbit
α    Lusor       F7V        
α0   Clement     Y100000-0
α1   Ausun       Y300169-9
α2   Burgund     Small GG
α2a  Cent        Y400367-9    003
α2b  Thermidor   Y560000-0    007
...
α4   Assiniboia  Large GG
α4a  Redes       F595269-9    003
...
α4e  Regina      A788899-A    055
...
β    Speck       DM
γ    Darida      M6V
γ0   Augur
γ1   Kirunda
γ1a  Irkirka                  008
...
γ2   Elazair     Small GG
γ2a  Lashir      YS00000-0    003
...
γ2e  Edaku       Y210000-0    050
γ2f  Gagamshir   F534328-A    125


Or, if you must:
Code:
Orbi Name        UWP          Sub-orbit
1    Lusor       F7V        
10   Clement     Y100000-0
11   Ausun       Y300169-9
12   Burgund     Small GG
121  Cent        Y400367-9    003
122  Thermidor   Y560000-0    007
...
14   Assiniboia  Large GG
141  Redes       F595269-9    003
...
145  Regina      A788899-A    055
...
2    Speck       DM
3    Darida      M6V
30   Augur
31   Kirunda
311  Irkirka                  008
 
Last edited:
Code:
Orbi Name        UWP          Sub-orbit
α    Sol         G2V        
α1   Mercury     G30046A-E
α2   Venus       G8B0168-E
α3   Terra       A867A69-F
α3a  Luna        F20076C-F    060

I actually find that fairly easy to read. The damage must be irreversible...
 
Makes me wonder if you can use a quad parameter system of some kind.

Primary StarPlanet orbitMoon orbit{null}
{null}Companion Star orbitCompanion Planet orbitMoon orbit

Although "moons of moons" are theoretically possible, LBB6 never included formulation for such.
 
Non-intuitive, I don't get what the G stands for and the '/' is unnecessary.
G stands for 16 in extended hex - at 5000au, Darida is in orbit 16.

The slash was intended to disambiguate an orbit like GA - is that a moon around a planet in orbit 16, suborbit 10 or a planet in orbit 10 around a star in orbit 16? I suppose that position could indicate this, as I think Spinward Flow is suggesting.

Traveller 5 moon orbits use A-Z to mean particular distances rather than having the moons be listed sequentially. Having an extra column could give more precise information though!

FWIW, the IAU now uses roman alphabet for stars rather than greek letters.

The example formats don't actually give an orbit for the stars (Speck and Darida need them).

Perhaps augmenting the Stellar column if the Second Survey Format will help. Something like:
Code:
Location Name      UWP       B  Stellar
1910-A4R Regina    A788899-C NS F7V+DM G:M3V
1910-C2P Gagamshir F534328-A M  F7V+DM G:M3V

Here I'm trying out using "+" for close companion orbit (it sort of just adds a little luminosity to the star it directly orbits). I put in the colon separator to keep the stars looking like stars. You could also just directly give the orbit number rather than using ehex.

A really full system in T5 might have stellar data that look like
Code:
A5Ia+A5III 5:A5III+A5III B:A5III+A5III H:A5III+A5III
(That set of stars appears to be generated when you roll minimum results on all dice using chart 2 BBB3 p.28. I suspect I misunderstand or there may be some errata needed.)

One of the things I'm going for here is a format where one line out of context gives you enough info to place the world in a system.
 
G stands for 16 in extended hex - at 5000au, Darida is in orbit 16.
OK, sorry, I was looking at LBB6 and the Regina system list.

Perhaps augmenting the Stellar column if the Second Survey Format will help. Something like:
Code:
Location Name      UWP       B  Stellar
1910-A4R Regina    A788899-C NS F7V+DM G:M3V
1910-C2P Gagamshir F534328-A M  F7V+DM G:M3V
This looks like a reasonable level of detail. The stellar data might need to contain complex cases.

Perhaps something like:
Code:
Location Name      UWP       B  Stellar
1910-A4R Regina    A788899-C NS A:F7V B:DM:A0 C:M3V:AG
1910-C2P Gagamshir F534328-A M  A:F7V B:DM:A0 C:M3V:AG

C:M3V:AG = Star no. C : StarType : Orbit no.G around star A

That way we can define complex multiple stellar systems. With this information we can calculate the approximate distance between Regina and Gagamshir
 
C:M3V:AG = Star no. C : StarType : Orbit no.G around star A
Nice! I see how this covers cases like the quaternary systems that LBB6 can generate, and it could even handle some exotic cases. It's also readable. Thanks for the help with this.

One small tweak:
- a close companion orbit is not in orbit 0 so we need a symbol that can't be confused with an orbit . I've tried "+", "-" and "#" so far and leaning towards +.

Code:
Location Name      UWP       B  Stellar
1910-A4R Regina    A788899-C NS A:F7V B:DM:A+ C:M3V:AG
1910-C2P Gagamshir F534328-A M  A:F7V B:DM:A+ C:M3V:AG
 
One small tweak:
- a close companion orbit is not in orbit 0 so we need a symbol that can't be confused with an orbit . I've tried "+", "-" and "#" so far and leaning towards +.

Code:
Location Name      UWP       B  Stellar
1910-A4R Regina    A788899-C NS A:F7V B:DM:A+ C:M3V:AG
1910-C2P Gagamshir F534328-A M  A:F7V B:DM:A+ C:M3V:AG
Yes, as long as it sorts before '0', it would work. I might prefer '#', '*', or '!' (signalling "special") over '+' or '-' (signalling more or less), but that is a minor detail.
 
We don't use computers with 64k memory, ya know. We really don't need to compress data to any extent.
Used to write COBOL programs. Implied decimals to save even just that much. A lot of this thread is not really about saving space per se I think, but rather, what's the smallest yet concise way of handling systems. Which is a fun exercise by itself I think.

(okay, it was only 4 COBOL programs that I did eventually migrate to another language. But I still wrote COBOL for a little bit!)
 
I had a TRS80 hand computer with 1400 step/character programming space. That was some terse programming. I had a 3x3 matrix solution program memorized and could type it into the computer during a test (the need never came up).

The whole idea of orbit numbers being predefined distances is entirely unnecessary, even back in the day. Now we know that almost anything is possible. M8V TRAPPIST-1 with 7 planets in tight orbits where we would think maybe two planets could fit; those planets not being in harmonic orbits; possibly 4 planets in the liquid water zone. Yes, that is one of a kind (so far). Gas giants orbiting so close their period is less than 1 day have been found around 4 stars (so far). One hot jupiter is 2700K, hotter TRAPPIST-1.

It's weird out there, so weird that we'd have a hard time saying anything is "impossible." We haven't begun to figure out the "rules" of system formation and orbital migration.
 
As far as I understand, it's not about making the computers life easier, but the humans.

It's about presenting lots of complex data at a glance. The way described above, we can make an expanded subsector view with a few important worlds per system, it sorts easily, and we can see their relative positions in the systems.

With a full presentation of each system it's a page or so per system, and nobody will bother looking.
 
Chances are that in about ten years someone will write a fan project artificial intelligence programme that will fully fill out the details of each star system in Traveller, and as the Travellers start visiting rural and urban areas dirtside, those too.
 
As far as I understand, it's not about making the computers life easier, but the humans.
Uhhh, nobody is making it "easier" for the computer. It's that the computers way back were so limited they couldn't efficiently store and retrieve and display large quantities of data. Plain text files without embedded formatting were the norm. Early kit computers had tape drives at 110 baud: a 1 hour cassette tape couldn't hold a 64k file, and would take an hour to read in. If you were using a university mini or mainframe account you might use a stack of cards (heaven help you if you drop them) and take them to the card reader so your program could generate sorted lists for reference.

On a hand-drawn map you could write in the UWP, sure. And then using the map months later have to remind yourself, "wait, it's size-hydro-atmo, or size-atmo-hydro?"
It's about presenting lots of complex data at a glance. The way described above, we can make an expanded subsector view with a few important worlds per system, it sorts easily, and we can see their relative positions in the systems.
No, it doesn't present complex data. It presents very simplified data. That readability comes at a loss of useful or even necessary detail. The UWP only works if you aren't really doing anything except rolling for cargo and passengers. Granted, I've done trade-centered games in which most worlds were just whistle stops. But not always.

"Hey, this planet is size 8. Can my 1G ship land? Wait, what do you mean there isn't a number in the UWP for density? Mars is only 0.7 of Earth density, so that size 8 might only have 0.7G surface gravity."

It isn't exactly 8000 miles (Earth isn't either). Is the size number truncated, or rounded? So it could be 7600 miles, or 8400 with normal rounding (you'd have to be more specific about rounding convention for 7500 or 8500). We should really be using 3 significant digits on that kind of data.

The UWP is a lossy compression method. If you want lossless data compression you lose readability.
With a full presentation of each system it's a page or so per system, and nobody will bother looking.
Weren't you just writing about LBB6 system data?
???
 
The UWP is a lossy compression method. If you want lossless data compression you lose readability.
Precisely. The UWP is a data visualization method. It can be looked at as a summary of more detailed data. It is also a first order approximation. One significant digit is not enough to tell you the whole story, but it does give a rough idea.

Also remember that there is a difference between precision and accuracy. If I said the average human has a temperature of 40.5732458C that is very precise but inaccurate. 40C is accurate for the one significant figure, but 37C is a more accurate figure.

I’ve been looking at more full representations of the orbits with 7 parameters and even those are imprecise when you have more than two bodies.

My goal here was to easily record and visualize the orbit information generated by the various Traveller worldgen systems. Adding a few characters to the existing T5 extended UWP does what I want.
 
given the math weve bean for the past half century A 25-40Km long O'Neal Cylinder can potentially host up to 20 million residents, that's as many as you will find in some modern G20 Nations, heck even the proposed russian replasment as a G8 Nation.
 
Back
Top