Extended System Data
- Thread starter robject
- Start date
Aramis, I agree that generic pop figures are sophonts.
At the same time, for a Ref trying to set the scene, knowing that the planet has 75% Vargr, 3% Aslan, 20% local non-human minor race, and a few escaped Solomani dissidents is different profoundly than 40% Vilani, 20% Solomani, 20% Zhodani (you can tell by the Turbans and sickened expressions on their faces), 10% Githiasko, 10% Virushi. It would be nice to have a method to report these sorts of breakdowns per planet or at least per subsector.
At the same time, for a Ref trying to set the scene, knowing that the planet has 75% Vargr, 3% Aslan, 20% local non-human minor race, and a few escaped Solomani dissidents is different profoundly than 40% Vilani, 20% Solomani, 20% Zhodani (you can tell by the Turbans and sickened expressions on their faces), 10% Githiasko, 10% Virushi. It would be nice to have a method to report these sorts of breakdowns per planet or at least per subsector.
(Va7 As0 NHM2) vs (Vi4 So2 Zh2 Gi1 Vr1)
in either case, goes in the remarks line...
seriously, tho', it is an issue... for some people.
By not defining it, CT left it up to the Ref to determine. Those CT sources which use it assume human (specific subrace immaterial) as the baseline, with other species being listed, or in the case of the Alien Modules, the sector's predominant race is presumed and the others listed.
Some exceptions: TTA mentions that the Dandies are not included in the population of Lewelloly. Then again, they are more than one order smaller, thus they have no impact upon the pop digit. We also know that the Eiboken are the dominant race of their world (but I'm too lazy to look up which that is...)
One is supposed to assume the dominant humman population of the Zhodani worlds is Zho, the sword worlds are sword worlder and/or Darrian, and the Darrian worlds are of course ethnic darrians. We've got therefore some 4+ human subspecies in the marches (Zhodani, Vilani, Darrian, Sword Worlder, and probably also some solomani) as well as Aslan, Vargr, and (ostensibly) Virushi and Newts, plus the natives to the area, of which we known from canon sources about the Droyne, Chirpers, Eiboken, Dandies (Lewelleloly), Shaggies (a human-symbiosis), and the Jagd-il-jgdi (not native, but close enough).
So that's 14 ethnic codes minimum for just one sector... if you track all at 1% or greater.
in either case, goes in the remarks line...
seriously, tho', it is an issue... for some people.
By not defining it, CT left it up to the Ref to determine. Those CT sources which use it assume human (specific subrace immaterial) as the baseline, with other species being listed, or in the case of the Alien Modules, the sector's predominant race is presumed and the others listed.
Some exceptions: TTA mentions that the Dandies are not included in the population of Lewelloly. Then again, they are more than one order smaller, thus they have no impact upon the pop digit. We also know that the Eiboken are the dominant race of their world (but I'm too lazy to look up which that is...)
One is supposed to assume the dominant humman population of the Zhodani worlds is Zho, the sword worlds are sword worlder and/or Darrian, and the Darrian worlds are of course ethnic darrians. We've got therefore some 4+ human subspecies in the marches (Zhodani, Vilani, Darrian, Sword Worlder, and probably also some solomani) as well as Aslan, Vargr, and (ostensibly) Virushi and Newts, plus the natives to the area, of which we known from canon sources about the Droyne, Chirpers, Eiboken, Dandies (Lewelleloly), Shaggies (a human-symbiosis), and the Jagd-il-jgdi (not native, but close enough).
So that's 14 ethnic codes minimum for just one sector... if you track all at 1% or greater.
An additional though (separate post for clarity)
Perhaps the flat-text-file extended format should include some header lines for sector and subsector.
Perhaps Hex 5555 for sector header
Hex AAAA for SS A header
Hex BBBB for SS B header
Hex CCCC for SS C header
etc.
the remarks entries would then be assumed for anything within that isn't contradicted.
I'm a fan of remarks codes additions.
Sadly, though, the flat-file is looking to be some 160 characters wide, at this rate.
Fundamentally, the Atm Code is broken, too.
Perhaps the flat-text-file extended format should include some header lines for sector and subsector.
Perhaps Hex 5555 for sector header
Hex AAAA for SS A header
Hex BBBB for SS B header
Hex CCCC for SS C header
etc.
the remarks entries would then be assumed for anything within that isn't contradicted.
I'm a fan of remarks codes additions.
Sadly, though, the flat-file is looking to be some 160 characters wide, at this rate.
Fundamentally, the Atm Code is broken, too.
Having a thought on the extended data formatting
Have a 4 space sector code, expressed as +X+Y or -X-Y, etc, using "Traveller" numbering (0-9,A,B,C...).
have a 4 space hex number
have a period for a visual delimiter, can be space instead
have a world number, in Traveller numbering If primary star, leave empty space. If secondary star, use a + sign.
have another period or space delimiter
have a moon number, again traveller numbering. Empty for stars or worlds.
blank space for delimiter, unless mainworld, then + instead
have a 4 space orbital distance, right justified.
separate entries by type after, each being listed indented space by space with - below.
Stars:
- Best StarPort in system
- dash or spacce delimiter
- type, left justified, pad to 6 spaces, note VIII becomes IIX on 1a or 1b types, to keep to six chars.
- dash or space delimiter
- best TL in system
- space delimiter
- Travel Zone (X, R, A, -) X for system interdicted, R if any worlds red, A if any Amber and none red, otherwise dash (-). if blank default to subsector
- PopCode of system (usually highest, but might be +1...)
- Bases in system; most important only.
- space delimiter
- 4 places for Allegiance
- space delimiter
- remarks to 80th place.
Bodies
- StarPort or spaceport
- dash or spacce delimiter
- Size
- atm
- hydro
- pop
- gov't
- ll
- dash or space delimiter
- TL
- space delimiter
- Travel Zone (X, R, A, -) X for world interdicted, R if red world, A if Amber world, otherwise dash (-). If blank, default to subsector
- PopMult
- Bases OnWorld
- space delimiter
- 4 places for Allegiance (Hex Number if gov't type 6 and owned by non-mainworld, or if mainworld).
- space delimiter
- remarks to 80th place.
Sector and Subsector entries
- Best StarPort in region
- dash or space delimiter
- 3 place num worlds with pop's
- PopCode for region
- government type for region
- Naval Enforcement
- dash or space delimiter
- best TL in system
- space delimiter
- Travel Zone usually blank, but some entire subsectors may be amber or even red.
- PopCode of region (usually highest, but might be +1...)
- Bases in Region; most important only.
- space delimiter
- 4 places for Allegiance (default for region) if blank, no default.
- space delimiter
- remarks to 80th place.
by cramming relevant data, one can compress. what do y'all think?
My thoughts: perhaps stars should all be + as the world number; secondary and tertiary stars should have sequence as moons. (Keeps them together in sort sequence.)
Have a 4 space sector code, expressed as +X+Y or -X-Y, etc, using "Traveller" numbering (0-9,A,B,C...).
have a 4 space hex number
have a period for a visual delimiter, can be space instead
have a world number, in Traveller numbering If primary star, leave empty space. If secondary star, use a + sign.
have another period or space delimiter
have a moon number, again traveller numbering. Empty for stars or worlds.
blank space for delimiter, unless mainworld, then + instead
have a 4 space orbital distance, right justified.
separate entries by type after, each being listed indented space by space with - below.
Stars:
- Best StarPort in system
- dash or spacce delimiter
- type, left justified, pad to 6 spaces, note VIII becomes IIX on 1a or 1b types, to keep to six chars.
- dash or space delimiter
- best TL in system
- space delimiter
- Travel Zone (X, R, A, -) X for system interdicted, R if any worlds red, A if any Amber and none red, otherwise dash (-). if blank default to subsector
- PopCode of system (usually highest, but might be +1...)
- Bases in system; most important only.
- space delimiter
- 4 places for Allegiance
- space delimiter
- remarks to 80th place.
Bodies
- StarPort or spaceport
- dash or spacce delimiter
- Size
- atm
- hydro
- pop
- gov't
- ll
- dash or space delimiter
- TL
- space delimiter
- Travel Zone (X, R, A, -) X for world interdicted, R if red world, A if Amber world, otherwise dash (-). If blank, default to subsector
- PopMult
- Bases OnWorld
- space delimiter
- 4 places for Allegiance (Hex Number if gov't type 6 and owned by non-mainworld, or if mainworld).
- space delimiter
- remarks to 80th place.
Sector and Subsector entries
- Best StarPort in region
- dash or space delimiter
- 3 place num worlds with pop's
- PopCode for region
- government type for region
- Naval Enforcement
- dash or space delimiter
- best TL in system
- space delimiter
- Travel Zone usually blank, but some entire subsectors may be amber or even red.
- PopCode of region (usually highest, but might be +1...)
- Bases in Region; most important only.
- space delimiter
- 4 places for Allegiance (default for region) if blank, no default.
- space delimiter
- remarks to 80th place.
by cramming relevant data, one can compress. what do y'all think?
My thoughts: perhaps stars should all be + as the world number; secondary and tertiary stars should have sequence as moons. (Keeps them together in sort sequence.)
There needs to be a way to indicate the presence and contents of at least one Far Companion system, versus a star which is in a Near orbit to the primary. Perhaps there's a subtlety to your system that I don't understand.
Using Malenfant's notation, here's a worst-case nightmare scenario (which will never occur unless the referee intervenes):
(F3 III M4 VI) G5 V M6 V [(K7 II M8 D) M9 IV M0 D]
This tortured star system contains the following eight stars:
Main System:
Primary: An F3 III with a binary companion M4 VI.
In Near orbits, a G5 V and M6 V.
Companion System:
Primary: A K7 II with a binary companion M8 D.
In Near orbits, an M9 IV and M0 D.
So there's a pain in the neck that needs to be representable. Really all that's needed is a way to start a companion system.
Having summary data pre-rolled-up together with the raw data might be a problem. Or not -- I suppose rollup data is purely optional, since it can be calculated. Aside from that, the format looks nice and compact.
Why do you change the order of appearance of bases, travel zone, and pop mult? Ah, are you anchoring the zone and base codes to the ever-present pop mult digit? Hmmmm.
Using Malenfant's notation, here's a worst-case nightmare scenario (which will never occur unless the referee intervenes):
(F3 III M4 VI) G5 V M6 V [(K7 II M8 D) M9 IV M0 D]
This tortured star system contains the following eight stars:
Main System:
Primary: An F3 III with a binary companion M4 VI.
In Near orbits, a G5 V and M6 V.
Companion System:
Primary: A K7 II with a binary companion M8 D.
In Near orbits, an M9 IV and M0 D.
So there's a pain in the neck that needs to be representable. Really all that's needed is a way to start a companion system.
Having summary data pre-rolled-up together with the raw data might be a problem. Or not -- I suppose rollup data is purely optional, since it can be calculated. Aside from that, the format looks nice and compact.
Why do you change the order of appearance of bases, travel zone, and pop mult? Ah, are you anchoring the zone and base codes to the ever-present pop mult digit? Hmmmm.
M
Malenfant
Guest
You just did represent it, didn't you?
Yup, you got me threre... I forgot to account for distant companions and their orbital junk.
OK, rething, that first delimmiter becomes a star letter for multi-secondary stars with subs, Orbital distance 1st space is star orbited... no letter is primary
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">DrZn2113 X-F3V -X A0
DrZn2113A 0 X-M4VI -X -0
DrZn2113B 15 X-G5V -X -0
DrZn2113C 35 X-M6V -0 -0
DrZn2113D 1245 X-K7II -0 A0
DrZn2113E D 2 X-M8D -0 -0
DrZn2113F D 32 X-M9IV -0 A0
DrZn2113G F 1 X-M0D -0 -0
DrZn2113G1 F 2 X-000000-0 A0 As</pre>[/QUOTE]added that asteroid belt to show the flexibility of the scheme
Also, mine provides a way to clearly list distances.
OK, rething, that first delimmiter becomes a star letter for multi-secondary stars with subs, Orbital distance 1st space is star orbited... no letter is primary
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">DrZn2113 X-F3V -X A0
DrZn2113A 0 X-M4VI -X -0
DrZn2113B 15 X-G5V -X -0
DrZn2113C 35 X-M6V -0 -0
DrZn2113D 1245 X-K7II -0 A0
DrZn2113E D 2 X-M8D -0 -0
DrZn2113F D 32 X-M9IV -0 A0
DrZn2113G F 1 X-M0D -0 -0
DrZn2113G1 F 2 X-000000-0 A0 As</pre>[/QUOTE]added that asteroid belt to show the flexibility of the scheme
Also, mine provides a way to clearly list distances.
Good.
The back-reference system seems a little bulky. Instead of listing them A, B, C,... could you simply tag the primaries? It becomes clear that the primary with a large orbital distance begins a far system.
(F3 III M4 VI) G5 V M6 V [(K7 II M8 D) M9 IV M0 D]
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">DrZn2113* X-F3V -X A0
DrZn2113 0 X-M4VI -X -0
DrZn2113 15 X-G5V -X -0
DrZn2113 35 X-M6V -0 -0
DrZn2113* 1245 X-K7II -0 A0
DrZn2113 0 X-M8D -0 -0
DrZn2113 32 X-M9IV -0 A0
DrZn2113 2 X-000000-0 A0 As
DrZn2113 64 X-M0D -0 -0
DrZn2113 20 X-400000-0 -0 Va</pre>[/QUOTE]Although I still prefer having header data. However, it might be worth exploring common notation systems, headered and non-headered, that applications can switch between.
But then, you can't really grep through pages of headered data as easily. Your format is grep-friendly. My format would require an application.
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Gvetzlatl (DrZn) 2113
* X-F3V -X A0
0 X-M4VI -X -0
15 X-G5V -X -0
35 X-M6V -0 -0
* 1245 X-K7II -0 A0
0 X-M8D -0 -0
32 X-M9IV -0 A0
2 X-000000-0 A0 As
64 X-M0D -0 -0
20 X-400000-0 -0 Va</pre>[/QUOTE]Of course, the slippery slope kicks in here, and I see all kinds of ways to make this 'prettier', until I end up with something similar to my proto-YAML formatting...
The back-reference system seems a little bulky. Instead of listing them A, B, C,... could you simply tag the primaries? It becomes clear that the primary with a large orbital distance begins a far system.
(F3 III M4 VI) G5 V M6 V [(K7 II M8 D) M9 IV M0 D]
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">DrZn2113* X-F3V -X A0
DrZn2113 0 X-M4VI -X -0
DrZn2113 15 X-G5V -X -0
DrZn2113 35 X-M6V -0 -0
DrZn2113* 1245 X-K7II -0 A0
DrZn2113 0 X-M8D -0 -0
DrZn2113 32 X-M9IV -0 A0
DrZn2113 2 X-000000-0 A0 As
DrZn2113 64 X-M0D -0 -0
DrZn2113 20 X-400000-0 -0 Va</pre>[/QUOTE]Although I still prefer having header data. However, it might be worth exploring common notation systems, headered and non-headered, that applications can switch between.
But then, you can't really grep through pages of headered data as easily. Your format is grep-friendly. My format would require an application.
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Gvetzlatl (DrZn) 2113
* X-F3V -X A0
0 X-M4VI -X -0
15 X-G5V -X -0
35 X-M6V -0 -0
* 1245 X-K7II -0 A0
0 X-M8D -0 -0
32 X-M9IV -0 A0
2 X-000000-0 A0 As
64 X-M0D -0 -0
20 X-400000-0 -0 Va</pre>[/QUOTE]Of course, the slippery slope kicks in here, and I see all kinds of ways to make this 'prettier', until I end up with something similar to my proto-YAML formatting...
This makes me want to design a worst-case hex for testing. Taking the star data from above, we'd have to add a planet/GG or two around each primary, and around each near star. Then add 1-3 moons/rings to each planet/GG. We can see everything in action that way.
Note: A big assumption made below is that orbital distances are always expressed with a decimal point, while satellite distances are whole numbers. Implicitly a number with a decimal is in AUs, and a whole number is in thousands of kilometers or whatever that measurement is.
Here it is, mostly without indents.
Note that general system data can be written as a list of items, as seen in the primary system, or 'folded' as in the secondary system.
Empty lines are simply ignored, so 'vertical whitespace' can be liberally scattered throughout the records.
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Sector: Gveszlatl
Sector code: DrZn
Hex 2113:
Primary System:
Name: Serk
Mainworld UWP: B800266-D
Population: 300
Government: Colony
Trade Codes: Va
Planetoid Belts: 2
Gas Giants: 3
Base Code: G
Allegiance: Vf
Primary: F3 III M4 VI
Near Stars: G5 V M6 V
Habitable Zone: -1
System:
0 Serk 0.2 B800266-D G Va
Shabush 7 YS00127-0 Va
Aglashlanlur 8 YS00265-0 Va
Ginamiiduug 40 YS00564-0 Va
1 Aadnigazursha 0.4 Y000000-0 As
2 Esha 0.7 YSGG----0
Uglen 30 YS00000-0 Va
3 Alernishim 1.0 YLGG----0
Uggargasmine 5 Y100000-0 Va
Pashigamam 8 Y100000-0 Va
Liishkhi 9 Y500000-0 Va
Lushigegushe 40 Y740000-0 Ba
4 Shilegishasha 2.8 G5 V
Gakakakhinka 1.0 YLGG----0
Nanikirgale 1 YR00000-0 Ring
Kugdumgaa 2 YR00000-0 Ring
5 Arshimzigam 5.6 M6 V
Ungagiginik 1.0 Y424000-0 Ba
Arguur 11 Y000000-0 As
6 Kuukidiikuki 10.0 Y500000-0 Va
Secondary System:
UWP: Arla Y200000-0 Ba 041 Vf (K7 II M8 D) M9 IV M0 D
Habitable Zone: -1
System:
0 Arla 0.2 Y200000-0 Va
Mika 20 Y000000-0 As
Yoka 40 Y000000-0 As
1 Gamgir 3.0 M9 IV
Kirga 0.5 Y300000-0 Va
Twinkie 10 Y000000-0 As
2 Irsha 5.0 YLGG----0
Flan 15 YR00000-0 Ring
Ginik 45 Y100000-0 Va
3 Mod 10.0 M0 D
Gazur 1.0 Y450000-0 Ba
Sharik 10 Y100000-0 Va
Gam 50 Y000000-0 As
Nikale 1.6 Y310000-0 Ba</pre>[/QUOTE]
Note: A big assumption made below is that orbital distances are always expressed with a decimal point, while satellite distances are whole numbers. Implicitly a number with a decimal is in AUs, and a whole number is in thousands of kilometers or whatever that measurement is.
Here it is, mostly without indents.
Note that general system data can be written as a list of items, as seen in the primary system, or 'folded' as in the secondary system.
Empty lines are simply ignored, so 'vertical whitespace' can be liberally scattered throughout the records.
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Sector: Gveszlatl
Sector code: DrZn
Hex 2113:
Primary System:
Name: Serk
Mainworld UWP: B800266-D
Population: 300
Government: Colony
Trade Codes: Va
Planetoid Belts: 2
Gas Giants: 3
Base Code: G
Allegiance: Vf
Primary: F3 III M4 VI
Near Stars: G5 V M6 V
Habitable Zone: -1
System:
0 Serk 0.2 B800266-D G Va
Shabush 7 YS00127-0 Va
Aglashlanlur 8 YS00265-0 Va
Ginamiiduug 40 YS00564-0 Va
1 Aadnigazursha 0.4 Y000000-0 As
2 Esha 0.7 YSGG----0
Uglen 30 YS00000-0 Va
3 Alernishim 1.0 YLGG----0
Uggargasmine 5 Y100000-0 Va
Pashigamam 8 Y100000-0 Va
Liishkhi 9 Y500000-0 Va
Lushigegushe 40 Y740000-0 Ba
4 Shilegishasha 2.8 G5 V
Gakakakhinka 1.0 YLGG----0
Nanikirgale 1 YR00000-0 Ring
Kugdumgaa 2 YR00000-0 Ring
5 Arshimzigam 5.6 M6 V
Ungagiginik 1.0 Y424000-0 Ba
Arguur 11 Y000000-0 As
6 Kuukidiikuki 10.0 Y500000-0 Va
Secondary System:
UWP: Arla Y200000-0 Ba 041 Vf (K7 II M8 D) M9 IV M0 D
Habitable Zone: -1
System:
0 Arla 0.2 Y200000-0 Va
Mika 20 Y000000-0 As
Yoka 40 Y000000-0 As
1 Gamgir 3.0 M9 IV
Kirga 0.5 Y300000-0 Va
Twinkie 10 Y000000-0 As
2 Irsha 5.0 YLGG----0
Flan 15 YR00000-0 Ring
Ginik 45 Y100000-0 Va
3 Mod 10.0 M0 D
Gazur 1.0 Y450000-0 Ba
Sharik 10 Y100000-0 Va
Gam 50 Y000000-0 As
Nikale 1.6 Y310000-0 Ba</pre>[/QUOTE]
My format is also SORTABLE without data loss; sequential reference systems lose that if taken out of context.
(In short, I'd thought of that, but rejected it, so that I could easily add new data at the EOF, then run a sort in a WP, and have the system stay intact intellectually. Sequential positioning formats don't have that flexibility.)
(Real world case in point: I dumped the whole of the GEnie data into a single spreadsheet, and used sort keys and hide keys repeatedly, using excell as a database engine. I could not count on systems maintaining their relative order, unless the last sort was on hex numbers.... )
And since we're space delimited, we could drop the referential data to system contents (which is mildly useful on the primary, but almost a waste for secondaries) with little effect.
I'm still a fan of TL AND SP being separated by a delimiter.
(In short, I'd thought of that, but rejected it, so that I could easily add new data at the EOF, then run a sort in a WP, and have the system stay intact intellectually. Sequential positioning formats don't have that flexibility.)
(Real world case in point: I dumped the whole of the GEnie data into a single spreadsheet, and used sort keys and hide keys repeatedly, using excell as a database engine. I could not count on systems maintaining their relative order, unless the last sort was on hex numbers.... )
And since we're space delimited, we could drop the referential data to system contents (which is mildly useful on the primary, but almost a waste for secondaries) with little effect.
I'm still a fan of TL AND SP being separated by a delimiter.
StuartFerris
SOC-5
This output is pretty much back to my previously posted output from the HE2 System Module beta.
We're going round in circles here guys. Lets get some focus.
Stuart
We're going round in circles here guys. Lets get some focus.
Stuart
[/quote]
Duh... hey, you're right! Imagine my surprise. How stupid of me.
Indeed, using a simple filter on Stuart's data turns it into a YAML-friendly format. Therefore, Stuart's original post is the most productive of this thread, since his software already uses it and it's easily transformable into YAML. Disclaimer: That doesn't mean Aramis' system isn't useful; it's just that Stuart's solution is a better fit for what I was looking for in the first place.
The difference I detect is how Stuart encodes secondary systems: I prefer them to be bundled with the primary system, but I'll have to look at Stuart's data to see if he does that or not.
Side Note: Aramis is quite right, that his format is standard-sortable and spreadsheet-friendly ... and my comment on its greppability stands there, too. But the mutliline format isn't all that hard to sort and grep -- in Perl, anyway: just change the line delimiter and call sort() on the input. But then, there's no reason two formats can't play together -- if they model the same data then there's some pair of functions which can convert from one to 'tother.
Here's Stuart's example system UWP, converted to YAML via a straightforward filter in Perl. Please note that this is not the prettiest YAML format possible, but rather an input that's good enough to feed to the YAML parser, which stores data using structures internal to the language being used (in Perl's case, the result would be a reference to a hashmap of hashmaps and arrays).
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">HEX 0304:
Name : Serk
UWP : B89A866-C
Trade Code : Wa
Population Multiplier : 7
Planetoid Belts : 2
Gas Giants : 3
Base Code : G
Allegiance : Vf
System Nature : Primary
Primary Star : M4 V
Primary Habitable Zone : 0
Primary Maximum Orbits : 7
Primary Empty Orbits : 1
Primary Captured Planets : 0
PRIMARY SYSTEM:
0:
- { name: 'Serk ', au: 0.2, uwp: B89A866-C, codes: Wa }
- { name: 'Shabush ', km: 70, uwp: YS00127-B, codes: }
- { name: 'Aglashlanlur ', km: 80, uwp: YS00265-B, codes: }
- { name: 'Ginamiiduug ', km: 400, uwp: YS00564-B, codes: Co }
1:
- { name: 'Aadnigazursha ', au: 0.4, uwp: Y000000-B, codes: }
2:
- { name: 'Esha ', au: 0.7, uwp: YB00000-B, codes: }
- { name: 'Uglen ', km: 300, uwp: YS00000-B, codes: }
3:
- { name: 'Alernishim ', au: 1.0, uwp: YC00000-B, codes: }
- { name: 'Uggargasmine ', km: 50, uwp: H100000-B, codes: }
- { name: 'Pashigamam ', km: 80, uwp: Y100000-C, codes: Ml }
- { name: 'Liishkhi ', km: 90, uwp: Y500000-B, codes: }
- { name: 'Lushigegushe ', km: 400, uwp: Y740000-C, codes: Re }
4:
- { name: 'Shilegishasha ', au: 1.6, uwp: Y000000-B, codes: }
5:
- { name: 'Gakakakhinka ', au: 2.8, uwp: YC00000-B, codes: }
- { name: 'Nanikirgale ', km: 10, uwp: YR00000-B, codes: }
- { name: 'Kugdumgaa ', km: 20, uwp: YR00000-B, codes: }
- { name: 'Arshimzigam ', km: 40, uwp: Y300000-B, codes: }
- { name: 'Ungagiginik ', km: 70, uwp: Y624000-B, codes: }
- { name: 'Arguur ', km: 110, uwp: Y663116-B, codes: }
- { name: 'Kuukidiikuki ', km: 300, uwp: Y543145-B, codes: }
- { name: 'Mikagamgir ', km: 350, uwp: Y100000-C, codes: Re }
- { name: 'Irshashuusade ', km: 400, uwp: Y300000-B, codes: }
- { name: 'Arla ', km: 3000, uwp: Y450000-B, codes: }</pre>[/QUOTE]A HUGE benefit to this is that my scripts can use Stuart's data 'almost' natively. (Granted, with a different filter I can also use Aramis' data formats too, and at that point I suppose that means I can write a converter between the two. But that's neither here nor there...
Stuart, do we have more extended system data "out there"? People have been detailing systems here and there for years; for instance, from the Landgrab. Has anyone brought them together?
Indeed, using a simple filter on Stuart's data turns it into a YAML-friendly format. Therefore, Stuart's original post is the most productive of this thread, since his software already uses it and it's easily transformable into YAML. Disclaimer: That doesn't mean Aramis' system isn't useful; it's just that Stuart's solution is a better fit for what I was looking for in the first place.
The difference I detect is how Stuart encodes secondary systems: I prefer them to be bundled with the primary system, but I'll have to look at Stuart's data to see if he does that or not.
Side Note: Aramis is quite right, that his format is standard-sortable and spreadsheet-friendly ... and my comment on its greppability stands there, too. But the mutliline format isn't all that hard to sort and grep -- in Perl, anyway: just change the line delimiter and call sort() on the input. But then, there's no reason two formats can't play together -- if they model the same data then there's some pair of functions which can convert from one to 'tother.
Here's Stuart's example system UWP, converted to YAML via a straightforward filter in Perl. Please note that this is not the prettiest YAML format possible, but rather an input that's good enough to feed to the YAML parser, which stores data using structures internal to the language being used (in Perl's case, the result would be a reference to a hashmap of hashmaps and arrays).
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">HEX 0304:
Name : Serk
UWP : B89A866-C
Trade Code : Wa
Population Multiplier : 7
Planetoid Belts : 2
Gas Giants : 3
Base Code : G
Allegiance : Vf
System Nature : Primary
Primary Star : M4 V
Primary Habitable Zone : 0
Primary Maximum Orbits : 7
Primary Empty Orbits : 1
Primary Captured Planets : 0
PRIMARY SYSTEM:
0:
- { name: 'Serk ', au: 0.2, uwp: B89A866-C, codes: Wa }
- { name: 'Shabush ', km: 70, uwp: YS00127-B, codes: }
- { name: 'Aglashlanlur ', km: 80, uwp: YS00265-B, codes: }
- { name: 'Ginamiiduug ', km: 400, uwp: YS00564-B, codes: Co }
1:
- { name: 'Aadnigazursha ', au: 0.4, uwp: Y000000-B, codes: }
2:
- { name: 'Esha ', au: 0.7, uwp: YB00000-B, codes: }
- { name: 'Uglen ', km: 300, uwp: YS00000-B, codes: }
3:
- { name: 'Alernishim ', au: 1.0, uwp: YC00000-B, codes: }
- { name: 'Uggargasmine ', km: 50, uwp: H100000-B, codes: }
- { name: 'Pashigamam ', km: 80, uwp: Y100000-C, codes: Ml }
- { name: 'Liishkhi ', km: 90, uwp: Y500000-B, codes: }
- { name: 'Lushigegushe ', km: 400, uwp: Y740000-C, codes: Re }
4:
- { name: 'Shilegishasha ', au: 1.6, uwp: Y000000-B, codes: }
5:
- { name: 'Gakakakhinka ', au: 2.8, uwp: YC00000-B, codes: }
- { name: 'Nanikirgale ', km: 10, uwp: YR00000-B, codes: }
- { name: 'Kugdumgaa ', km: 20, uwp: YR00000-B, codes: }
- { name: 'Arshimzigam ', km: 40, uwp: Y300000-B, codes: }
- { name: 'Ungagiginik ', km: 70, uwp: Y624000-B, codes: }
- { name: 'Arguur ', km: 110, uwp: Y663116-B, codes: }
- { name: 'Kuukidiikuki ', km: 300, uwp: Y543145-B, codes: }
- { name: 'Mikagamgir ', km: 350, uwp: Y100000-C, codes: Re }
- { name: 'Irshashuusade ', km: 400, uwp: Y300000-B, codes: }
- { name: 'Arla ', km: 3000, uwp: Y450000-B, codes: }</pre>[/QUOTE]A HUGE benefit to this is that my scripts can use Stuart's data 'almost' natively. (Granted, with a different filter I can also use Aramis' data formats too, and at that point I suppose that means I can write a converter between the two. But that's neither here nor there...
Stuart, do we have more extended system data "out there"? People have been detailing systems here and there for years; for instance, from the Landgrab. Has anyone brought them together?
OK, at the risk of boring everyone (too late...), here's an example using TNE data I scraped from the Missouri Archive. I'm testing out my format to find problems with it.
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">#
# TNE data taken from:
# http://www.mu.org/~joe/traveller/archive/TNE/TNE-Pocket/systems.data.txt
#
HEX 0001:
Name: Rintarna
UWP: X887876-5
Trade Code: Ri Td B:3
Planetoid Belts: 1
Gas Giants: 3
Primary Star: M0 V
Primary Habitable Zone: 0
PRIMARY SYSTEM:
0:
- { name: 'Rintarna', uwp: X887876-5, codes: 'Ri Td B:3' }
1:
- { uwp: YS00000-0 }
2:
- { uwp: H000000-0, au: 0.1 }
3:
- { uwp: YLGG000-0 }
- { kkm: 3, uwp: YS00000-0 }
- { kkm: 5, uwp: Y100000-0 }
- { kkm: 11, uwp: Y764000-0 }
- { kkm: 16, uwp: Y300000-0 }
- { kkm: 20, uwp: Y400000-0 }
- { kkm: 40, uwp: Y300000-0 }
- { kkm: 55, uwp: Y623000-0 }
4:
- { uwp: YLGG000-0 }
- { kkm: 1, uwp: YR00000-0 }
- { kkm: 20, uwp: Y100000-0 }
- { kkm: 40, uwp: Y300000-0 }
5:
- { uwp: YSGG000-0 }
- { kkm: 7, uwp: Y410000-0 }
- { kkm: 9, uwp: Y520000-0 }
- { kkm: 25, uwp: Y400000-0 }
- { kkm: 35, uwp: Y410000-0 }
6:
- { uwp: Y305000-0 }
7:
- { uwp: Y300000-0 }
HEX 0002:
Name: Drinsaar
UWP: D885747-6
Planetoid Belts: 0
Gas Giants: 2
Primary Star: K5 V
Primary Habitable Zone: 1
PRIMARY SYSTEM:
0:
- { uwp: YS00000-0 }
1:
- { uwp: D885747-6, name: Drinsaar }
- { uwp: YS00000-0, kkm: 10 }
- { uwp: Y200000-0, kkm: 40 }
2:
- { uwp: YS00000-0 }
3:
- { uwp: YSGG000-0 }
- { uwp: YR00000-0, kkm: 1, codes: Ring }
- { uwp: YS00000-0, kkm: 9 }
- { uwp: YS00000-0, kkm: 12 }
- { uwp: Y300000-0, kkm: 30 }
- { uwp: Y100000-0, kkm: 35 }
4:
- { uwp: Y222000-0 }
9:
- uwp: M5 V
NEAR SYSTEM:
0:
- { uwp: YS00000-0 }
1:
- { uwp: YS00000-0 }
2:
- { uwp: Y706000-0 }
- { uwp: Y100000-0, kkm: 15 }
3:
- { uwp: YS00000-0 }
4:
- { uwp: YLGG000-0 }
- { uwp: Y200000-0, kkm: 4 }
- { uwp: Y200000-0, kkm: 7 }
- { uwp: Y200000-0, kkm: 8 }
- { uwp: Y300000-0, kkm: 9 }
- { uwp: Y400000-0, kkm: 13 }
- { uwp: Y720000-0, kkm: 35 }
- { uwp: Y300000-0, kkm: 40 }
- { uwp: Y400000-0, kkm: 45 }
- { uwp: Y600000-0, kkm: 55 }
- { uwp: Y510000-0, kkm: 65 }</pre>[/QUOTE]
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">#
# TNE data taken from:
# http://www.mu.org/~joe/traveller/archive/TNE/TNE-Pocket/systems.data.txt
#
HEX 0001:
Name: Rintarna
UWP: X887876-5
Trade Code: Ri Td B:3
Planetoid Belts: 1
Gas Giants: 3
Primary Star: M0 V
Primary Habitable Zone: 0
PRIMARY SYSTEM:
0:
- { name: 'Rintarna', uwp: X887876-5, codes: 'Ri Td B:3' }
1:
- { uwp: YS00000-0 }
2:
- { uwp: H000000-0, au: 0.1 }
3:
- { uwp: YLGG000-0 }
- { kkm: 3, uwp: YS00000-0 }
- { kkm: 5, uwp: Y100000-0 }
- { kkm: 11, uwp: Y764000-0 }
- { kkm: 16, uwp: Y300000-0 }
- { kkm: 20, uwp: Y400000-0 }
- { kkm: 40, uwp: Y300000-0 }
- { kkm: 55, uwp: Y623000-0 }
4:
- { uwp: YLGG000-0 }
- { kkm: 1, uwp: YR00000-0 }
- { kkm: 20, uwp: Y100000-0 }
- { kkm: 40, uwp: Y300000-0 }
5:
- { uwp: YSGG000-0 }
- { kkm: 7, uwp: Y410000-0 }
- { kkm: 9, uwp: Y520000-0 }
- { kkm: 25, uwp: Y400000-0 }
- { kkm: 35, uwp: Y410000-0 }
6:
- { uwp: Y305000-0 }
7:
- { uwp: Y300000-0 }
HEX 0002:
Name: Drinsaar
UWP: D885747-6
Planetoid Belts: 0
Gas Giants: 2
Primary Star: K5 V
Primary Habitable Zone: 1
PRIMARY SYSTEM:
0:
- { uwp: YS00000-0 }
1:
- { uwp: D885747-6, name: Drinsaar }
- { uwp: YS00000-0, kkm: 10 }
- { uwp: Y200000-0, kkm: 40 }
2:
- { uwp: YS00000-0 }
3:
- { uwp: YSGG000-0 }
- { uwp: YR00000-0, kkm: 1, codes: Ring }
- { uwp: YS00000-0, kkm: 9 }
- { uwp: YS00000-0, kkm: 12 }
- { uwp: Y300000-0, kkm: 30 }
- { uwp: Y100000-0, kkm: 35 }
4:
- { uwp: Y222000-0 }
9:
- uwp: M5 V
NEAR SYSTEM:
0:
- { uwp: YS00000-0 }
1:
- { uwp: YS00000-0 }
2:
- { uwp: Y706000-0 }
- { uwp: Y100000-0, kkm: 15 }
3:
- { uwp: YS00000-0 }
4:
- { uwp: YLGG000-0 }
- { uwp: Y200000-0, kkm: 4 }
- { uwp: Y200000-0, kkm: 7 }
- { uwp: Y200000-0, kkm: 8 }
- { uwp: Y300000-0, kkm: 9 }
- { uwp: Y400000-0, kkm: 13 }
- { uwp: Y720000-0, kkm: 35 }
- { uwp: Y300000-0, kkm: 40 }
- { uwp: Y400000-0, kkm: 45 }
- { uwp: Y600000-0, kkm: 55 }
- { uwp: Y510000-0, kkm: 65 }</pre>[/QUOTE]
StuartFerris
SOC-5
Its a lesson I learned long ago. Always check the start of a thread as well as the end - because sometimes the answer is at the beginning. Hey, that sounded quite deep.
Here is an example of the HE2 output for a Binary System:-
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">HE0 File Format (V1.0.5)
------------------------
SYSTEM UWP
Hex Location - 0101
Name - Argip
UWP - C657431-6
Population Multiplier - 7
Planetoid Belts - 1
Gas Giants - 4
Base Code - M
System Nature - Binary
Primary Star - F2 V
Binary Star - M4 D
SYSTEM DETAILS
Primary Habitable Zone - 5
Binary Habitable Zone - 0
Primary Maximum Orbits - 13
Binary Maximum Orbits - 3
Primary Empty Orbits - 0
Binary Empty Orbits - 0
Primary Captured Planets - 0
Binary Captured Planets - 2
Binary Star Orbit - 11
Binary Star Sphere Inner Radius - 5
Binary Star Sphere Outer Radius - 1
PRIMARY SYSTEM - F2 V
0 (0.2) - Gugilimshi Y000000-5
1 (0.4) - Gargagakhir YB00000-5
1 (5) - Akergas Y200000-5
2 (6) - Shargi YS00000-5
3 (8) - Amlisguusidi Y200000-5
4 (9) - Ruurkhabimegi Y100000-5
2 (0.7) - Markirbasham YB00000-5
1 (5) - Lamulamkamkam YS00000-5
2 (8) - Khadushgu Y300000-5
3 (9) - Esash YS00000-5
4 (25) - Kakhudakupdim YS00000-5
3 (1.0) - Kigakir YB00000-5
1 (2) - Gushuupkarkha YR00000-5
2 (3) - Ikhuumkuukhe Y100000-5
3 (8) - Erkumashigi YS00000-5
4 (9) - Lumkuumenen Y400141-5
5 (35) - Gagkun Y540000-5
6 (55) - Diigiishukila Y100000-5
4 (1.6) - Buskurkhumim YC00000-5
1 (1) - Agekhad YR00000-5
2 (5) - Eshkur Y500000-5
3 (6) - Nasir YS00000-5
4 (7) - Dumamiirdegag H400000-5
5 (8) - Lakasu Y100000-5
6 (13) - Gekhirrankaar G650410-5
7 (35) - Amniiggepkin Y300000-5
8 (45) - Khishgekiimur Y300000-5
5 (2.8) - Argip C657431-6
1 (7) - Adgin YS00000-5
2 (9) - Aniigarkii YS00540-5
3 (45) - Irligimzikis YS00000-5
6 (5.6) - Unavailable
7 (10.0) - Unavailable
8 (19.6) - Unavailable
9 (38.8) - Unavailable
10 (77.2) - Unavailable
11 (154.0) - Binary Star
12 (307.6) - Unavailable
BINARY SYSTEM - M4 D
0 (0.2) - Ergagaslum Y868300-5 Fa
1 (8) - Urkigagshaa YS00310-5
2 (9) - Kikagu YS00141-5
3 (10) - Kezar YS00000-5
1 (0.4) - Apa YS00221-5
2 (0.7) - Irsham Y200000-5</pre>[/QUOTE]As you suggested the Binary System is detailed seperately. I designed it that way so it could be easily parsed and also easily read. I understand the logic of your prefered way, but don't think it is too helpful for someone reading the file.
Stuart
Here is an example of the HE2 output for a Binary System:-
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">HE0 File Format (V1.0.5)
------------------------
SYSTEM UWP
Hex Location - 0101
Name - Argip
UWP - C657431-6
Population Multiplier - 7
Planetoid Belts - 1
Gas Giants - 4
Base Code - M
System Nature - Binary
Primary Star - F2 V
Binary Star - M4 D
SYSTEM DETAILS
Primary Habitable Zone - 5
Binary Habitable Zone - 0
Primary Maximum Orbits - 13
Binary Maximum Orbits - 3
Primary Empty Orbits - 0
Binary Empty Orbits - 0
Primary Captured Planets - 0
Binary Captured Planets - 2
Binary Star Orbit - 11
Binary Star Sphere Inner Radius - 5
Binary Star Sphere Outer Radius - 1
PRIMARY SYSTEM - F2 V
0 (0.2) - Gugilimshi Y000000-5
1 (0.4) - Gargagakhir YB00000-5
1 (5) - Akergas Y200000-5
2 (6) - Shargi YS00000-5
3 (8) - Amlisguusidi Y200000-5
4 (9) - Ruurkhabimegi Y100000-5
2 (0.7) - Markirbasham YB00000-5
1 (5) - Lamulamkamkam YS00000-5
2 (8) - Khadushgu Y300000-5
3 (9) - Esash YS00000-5
4 (25) - Kakhudakupdim YS00000-5
3 (1.0) - Kigakir YB00000-5
1 (2) - Gushuupkarkha YR00000-5
2 (3) - Ikhuumkuukhe Y100000-5
3 (8) - Erkumashigi YS00000-5
4 (9) - Lumkuumenen Y400141-5
5 (35) - Gagkun Y540000-5
6 (55) - Diigiishukila Y100000-5
4 (1.6) - Buskurkhumim YC00000-5
1 (1) - Agekhad YR00000-5
2 (5) - Eshkur Y500000-5
3 (6) - Nasir YS00000-5
4 (7) - Dumamiirdegag H400000-5
5 (8) - Lakasu Y100000-5
6 (13) - Gekhirrankaar G650410-5
7 (35) - Amniiggepkin Y300000-5
8 (45) - Khishgekiimur Y300000-5
5 (2.8) - Argip C657431-6
1 (7) - Adgin YS00000-5
2 (9) - Aniigarkii YS00540-5
3 (45) - Irligimzikis YS00000-5
6 (5.6) - Unavailable
7 (10.0) - Unavailable
8 (19.6) - Unavailable
9 (38.8) - Unavailable
10 (77.2) - Unavailable
11 (154.0) - Binary Star
12 (307.6) - Unavailable
BINARY SYSTEM - M4 D
0 (0.2) - Ergagaslum Y868300-5 Fa
1 (8) - Urkigagshaa YS00310-5
2 (9) - Kikagu YS00141-5
3 (10) - Kezar YS00000-5
1 (0.4) - Apa YS00221-5
2 (0.7) - Irsham Y200000-5</pre>[/QUOTE]As you suggested the Binary System is detailed seperately. I designed it that way so it could be easily parsed and also easily read. I understand the logic of your prefered way, but don't think it is too helpful for someone reading the file.
Remember the HE2 System Module is only a Beta at this stage. The original H&E did not use a similar type of format, but simply a list of he variables. As a result I don't think there is too much out there in a parseable format.
Stuart
Thanks Stuart. Splitting out a Near star system is not a problem, and does look nicer. When you have two Near stars, are they listed in their orbit order, the nearer one first, followed by the farther one? And how do you label secondary systems and their near star systems?
StuartFerris
SOC-5
At the moment the Companion Stars are not sorted into orbit. One is simply designated the Binary Star and the other is designated the Trinary Star. This is something that I do intend to rectify though.
Companion Stars cannot have their own Companion Star. Thats my interpretation of the rules sets used in HE2 (CT, MT, TNE & GURPS). Someone correct me if I'm wrong.
Stuart
Companion Stars cannot have their own Companion Star. Thats my interpretation of the rules sets used in HE2 (CT, MT, TNE & GURPS). Someone correct me if I'm wrong.
Stuart
Similar threads
