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

Extended System Data

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.
Click to expand...
That may be so; I don't recall any traditional UWP data with more than three stars listed. However, (1) referees may wish to create such a system; (2) it is possible in RL, and (3) Malenfant's Revised Stellar Generation rules do create such systems, and, in a word, rock. Therefore, it might be worth taking into account systems like this horrible, ghastly 8-star monstrosity:

(F3 III M4 VI) G5 V M6 V [(K7 II M8 D) M9 IV M0 D]

And, although Malenfant considers it vanishingly unlikely (i.e. his rules don't allow it), a flexible framework might want to have room to support two companion systems. Imagine, if you will, engineers from some long-extinct race who pushed three systems into a configuration like this:

G5 V [K6 V] [F4 V]

(With a garden world, a gas giant, and a planetoid belt each.)

Or this horrible monstrosity:

(F3 III M4 VI) G5 V M6 V [(K7 II M8 D) M9 IV M0 D] [(K1 V M2 D) M3 D M4 D]

Makes me want to run screaming from the room, it does.
 
Funny enough, the one thing I never did for Wypoc was the extended system details....

It is entirely likely, under extant rules, to have a pair of far companions in a trinary system; this results in three systems within the same hex, and mere days apart by light-lag (and years travel by N-space). It will probably be a few years, but sooner or later we'll get an answer.

As a GM, whenever I encounter a trinary, I assume a common center of orbit, but if a dwarf and a non-dwarf companion are there, and in the same orbit, I have them either in a trojan or co-orbital configuration... so being able to code that is important to me.

And at some point, the thread diverged from what's out there, to a more philosophical, what should there be.
 
Aramis, I've been thinking about your filesort-friendly notation this evening, and I might try to play around with it some. I feel another hybrid coming on.

I may have sort of given your suggestion the brush-off. I hope you didn't take offense; I was thinking in YAML. I think your suggestion merits some investigation. How about this variant:
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">CCCCHHHH.SNLM

where

CCCC = Sector Code
HHHH = Hex code
S = System number (1-F)*
N = Insystem star index (0=primary)
L = Orbital index (0-9,A-H,J-N,P-Z)
M = Moon number (or space if not a moon).</pre>[/QUOTE]The actual data drives the rest of the line's format. "UWP" formats and order are preserved as much as possible. Stuff like stars and gas giants can have whatever format works for them (I suppose a GG can have a space station orbiting it?).

I'm thinking that "Hex Zero" actually has header data and comments for the entire sector, and "System Zero" has header data & comments for the entire Hex.

Also, a semicolon after the moon's digit in order to treat the rest of the line as a comment; a 2-digit (or whatever) number can come right after it to preserve line ordering.

Regardless of the heirarchy used, there probably ought to be a code for "Habitable Zone" (Ha) and maybe a separate entry for the "Snowline".

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">0000.001;
0000.002; Test system using a variant of Aramis'
0000.003; positional notation, which not only
0000.004; resolves orbital placement, but also
0000.005; preserves data order across file sorts.
0000.006;
0000.007; The positional data consists of the following:
0000.008;
0000.009; CCCCHHHH.SNLM
0000.00a;
0000.00b; where
0000.00c;
0000.00d; CCCC = Sector Code
0000.00e; HHHH = Hex code
0000.00f; S = System number (1-F)*
0000.00g; N = Insystem star index (0=primary)
0000.00h; L = Orbital index (0-9,A-H,J-N,P-Z)
0000.00i; M = Moon number (or space if not a moon).
0000.00j;
0000.010; Outer groups may be successively omitted; for
0000.011; example, the Sector Code may be left out for
0000.012; representing one sector only; the hex code
0000.013; may be omitted for a system-only list; Finally,
0000.014; all positional data may be omitted if some
0000.015; non-filesort-safe positional representation is used.
0000.016;
1010.1 F5 V
1010.101 0.5 Y000000-0 As
1010.102 Aleppo 1.2 Y876000-0 Ha
1010.1021 30 Y300000-0
1010.1022 65 Y200000-0
1010.1023 130 Y100000-0
1010.103 2.0 Snowline
1010.104 3.0 YSGG000-0 GG
1010.1041 10 YR00000-0 Ring
1010.1042 20 Y300000-0
1010.1043 45 Y410000-0
1010.1044 60 Y310000-0
1010.1045 100 Y200000-0
1010.1046 200 Y300000-0
1010.1fff;
1010.2 1k G6 V
1010.201 Beth 1.0 Y664000-0 Ha
1010.2011 150 Y100000-0
1010.2012 200 Y100000-0
1010.202 2.0 Y000000-0 As
1010.203 2.5 Snowline
1010.204 4.0 YSGG000-0 GG
1010.2041 20 YR00000-0 Ring
1010.2042 40 Y400000-0
1010.2043 60 Y300000-0
1010.2fff;
1010.3 2k K7 V
1010.301 Camel 0.9 Y767000-0 Ha
1010.3011 50 Y200000-0
1010.3012 100 Y200000-0
1010.302 1.8 Y000000-0 As
1010.303 3.0 Snowline
1010.304 3.5 YSGG000-0 GG
1010.3041 50 Y100000-0
1010.3042 100 Y400000-0
1010.3043 150 Y500000-0
1010.3fff; </pre>[/QUOTE]
 
Well, as opposed to going round in circles, maybe I'm "zeroing in" on a target.

By the way, I've posted several of the concoctions floating on this thread here:

http://home.comcast.net/~downport/uwp/

My latest hybrid takes Stuart's format (thanks Stuart!) and twists it slightly. With just a little nudge, it can be made to represent any star systems I'm likely to want to detail.

I keep the orbit number, which represents orbit around the primary, and move the orbital distances after the world/moon/star name. I create patterns distinguishing between the primary -- which can be a binary -- near stars, far stars, planets, gas giants, and moons. I even add a pattern for labeling the Snowline of a system.

An example of this format is at:

http://home.comcast.net/~downport/uwp/esha.esp

The format can be extended to include an initial positional data string, to preserve sort order in files (thanks, Aramis!).

Here's a sample of the datafile (without positional data):

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;"> Serk's Star F3 III M4 VI
0 Serk 0.2 B800266-D G Va
Shabush 7 YS00127-0 Va
Ginamiiduug 40 YS00564-0 Va
1 Aadnigazursha 0.4 Y000000-0 As
2 Esha 0.7 YSGG000-0
Uglen 30 YS00000-0 Va
4 Shilegishasha 2.8 G5 V
Gakakakhinka 1.0 YLGG000-0
Nanikirgale 1 YR00000-0 Ring
5 4.0 Snowline
6 Arshimzigam 5.6 M6 V
Ungagiginik 1.0 Y424000-0 Ba
Arguur 11 Y000000-0 As
7 Kuukidiikuki 10.0 Y500000-0 Va

Arla's Binary 1k K7 II M8 D
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 YLGG000-0
Flan 15 YR00000-0 Ring
Ginik 45 Y100000-0 Va
3 8.5 Snowline
4 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]
 
Cool... I like the way you've presented the page, and updated the format somewhat.
 
Here's my Extended System Profile (ESP) for Regina. Not having my stuff handy, I've guessed on the main orbital distances from the primary.

Mainworld is indicated with an asterisk out in front. In this example, satellite orbits are given in front of the satellite names.

Code: 
Hex 1910:

Name:             Regina
Mainworld UWP:    A788899-A
Population:       100 million
Planetoid Belts:  0
Gas Giants:       3
Base Code:        A
Trade Codes:      Ri Cp
Allegiance:       Im
Primary:          F7 V M0 D

     Lusor                  F7 V M0 D               
  0  Clement           0.1  Y100000-0               
  1  Ausun             0.3  Y300169-9              7
  2  Burgund           0.7  SGG                     
       3 Cent               Y400367-9              4
       7 Thermidor          Y560000-0               
  3  Olybrius          1.0  F75022A-9              6
      25 Alise              Y20016C-9              6
  4  Assiniboia        1.5  LGG                     
       3 Redes              F595269-9   Ag         5
       6 Printemps          F20036C-A N            8
       7 Brumaire           F564669-9   Ag         5
      30 Harcourt           H43556C-A M RsA        1
*     55 Regina             A788899-A A Ri Cp      1
                                                    
     Darida                 M6 V                    
  0  Augur             0.1  YS00000-0               
  1  Kirunda           0.3  Y210000-0               
       8 Irkirka            YS00000-0               
      11 Arkurer            HS00137-9              7
      13 Irgurkar           Y10046A-A              3
  2  Elazair           0.7  SGG                     
       3 Lashir             YS00000-0               
       8 Diuur Imar         G200269-9              4
       9 Shamardae          Y500000-0               
      20 Arapan             Y200000-0               
      50 Edaku              Y210000-0               
     125 Gagamshir          F534328-A M            3
 
Last edited:
...and here's Yori, with data borrowed from the TML Landgrab.

In this example, satellite orbits are lined up with the planet orbital radius. I think I like it better this way. No, I think the other way is easier to read. Although it seems less 'balanced'. Hmmmm.

Code: 
Hex 2110:

Name:             Yori
Mainworld UWP:    C360757-D
Population:       70 million
Planetoid Belts:  1
Gas Giants:       3
Trade Codes:      De Ri RsB
Allegiance:       Im
Primary:          F1 V

     Liecs                 F1 V                                             
  0  Dueck           0.1   H200000-0                                        
  1  Dragu           0.3   Y100000-0                                        
       Draguring       1   YR00000-0   ; Surprising considering Dragu's size
       Hou            25   YS00000-0                                        
  3  Depoli          1.0   Y200000-0                                        
       Hotte           8   YS00000-0                                        
       Hovind         60   YS00000-0                                        
  4  Duerholt        1.1   Y440100-9             6                          
  5  -               1.5   Y000000-0   As                                   
  6  Dectura         2.6   SGG                                              
       Skyline         2   YR00000-0                                        
*      Yori           25   C360757-A   De Ri     7                          
       Tino           35   HS00000-0                                        
  7  Dumka           5.5   LGG                                              
       Hynd           10   Y300000-0                                        
       Haque          11   H510000-0                                        
       Hein           35   Y734000-0             1                          
       Haler          40   G400266-A   RsB       5                          
       Hekzco         55   H200000-0                                        
       Heddle         60   G200226-9   ExC       4                          
  8  Dusoswa        11.0   SGG                                              
       Dusoswaring     1   YR00000-0                                        
       Hann           40   Y200000-0                                        
       Harcus         45   YS00000-0                                        
  9  Dzioba         19.0   Y94A000-0                                        
       Hnetka          9   F72631A-9   Corp      3                          
 10  Dyck           38.0   Y410000-0
 
Last edited:
About the only extra thing I'd like to see is (yeah its minor) the satellites slightly indented wrt the objects they orbit. This is more of a visual thing, but if it could be easily accomodated, it would be nice.

Very nice work, by the way, all.
 
OK, I'm playing with the indentation a bit. (Looking more like Book 6, eh?) Check out the two systems above; I've changed them in different ways, and I'm trying to decide which one I like better. Suggestions?
 
Hi !

Guess I would prefer the Regina example.
IMHO its more eye-friendly and it does not mix similar values with different meaning (AU and Sat-orbit in one row).
Would You mind about placing a char code in front of the star columns, just like "P" for primary or "B" for binary etc ... ?

How would You specify the location of a binary star in this system ?

As I am always thinking of parsing when looking at text data files, do You think of a fixed length system for the row entries ?

Regards,

Mert
 
Throwing all caution to the wind, in the spirit of "Hide the UPP and UWP in T5", here's the Regina system in text.

My basic assumption is that our computers are powerful enough to parse data without needing too many text cues or fixed columns, and we have enough memory now to store uncompressed string data.

Please note that it only takes up 5x the space of my UWP-style Regina system: 7k instead of 1.6k. 10,000 star systems of similar size would eat up 70 megabytes of space uncompressed.

If some world patterns become ubiquitous, it may also be possible to use a descriptive alias in place of the world's physical characteristics. That's an area that needs more study.

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">---
Hex 1910:

Primary Star:
Name: Lusor
Type: Binary Star (F7 V, M0 D)
Note: >
This is a notes entry for the primary star. Comments are
marked by the indentation, but blank lines do not count as
indented text, so we can introduce a paragraph break...

...just like that. When the indentation changes, the comment is
done.

Satellites:

Orbit 0:
Name: Clement
Type: Planet
Distance: 0.1 AU
Size: 1600 km
Code: Empty
Note: >
Although this format is quite verbose, there is still
some shorthand going on. For example, when there is no
starport, and the atmosphere, hydrosphere, and population
are all zero, then the shorthand "Code: Empty" line is
used, instead of populating all three entries.

Orbit 1:
Name: Ausun
Type: Planet
Distance: 0.3 AU
Size: 4800 km
Code: Empty
Population: 70
Government: Subordinate
Law Level: 9
TL: 9
Note: >
Here's an example of overriding data. The "Code" field
lists the planet as "Empty", meaning no starport, no
atmosphere, hydrographics, or population. However, the
population field is set, overriding the Empty field at
that point. Note that since population > 0, the government,
law level, and TL must also exist.

Orbit 2:
Name: Burgund
Type: Gas Giant
Distance: 0.7 AU
Size: 0.5 j
Satellites:

Orbit 1:
Name: Cent
Type: Planet
Distance: 1.5 j
Size: 6400km
Code: Empty
Population: 4000
Government: Subordinate
Law Level: 7
TL: 9

Orbit 2:
Name: Thermidor
Type: Planet
Distance: 3.5 j
Starport: none
Size: 8000 km
Atmosphere: Standard pressure, breathable
Hydrographics: none
Population: none
Note: >
In this case, there is an atmosphere, so starport,
hydrographics, and population entries must be present.
However, since there is no population, then government,
law level, and tech level are not necessary. If there
is technology present in operation without the presence
of a population, then a note should explain the
presence of the tech.

Orbit 3:
Name: Olyrbrius
Type: Planet
Distance: 1.0 AU
Starport: Good-quality spaceport
Size: 8000 km
Atmosphere: Standard pressure, tainted
Hydrographics: none
Population: 600
Government: Participating Democracy
Law Level: 10
TL: 9
Satellites:

Orbit 1:
Name: Alise
Type: Planet
Distance: 200000 km
Size: 3200 km
Code: Empty
Population: 60
Government: Subordinate
Law Level: (what's a 'C'?)
TL: 9

Orbit 4:
Name: Assiniboia 1.5 LGG
Type: Gas Giant
Distance: 1.5 AU
Size: 1.0 J
Satellites:

Orbit 1:
Name: Redes
Type: Planet
Distance: 3.0 J
Starport: Good-quality spaceport
Size: 8000 km
Atmosphere: High pressure, tainted
Hydrographics: 50%
Population: 500
Government: Subordinate
Law Level: 9
TL: 9
Agriculture: High

Orbit 2:
Name: Printemps
Type: Planet
Distance: 6.0 J
Starport: Good-quality spaceport
Size: 3200 km
Atmosphere: none
Hydrographics: none
Population 8000
Government: Subordinate
Law Level: C
TL: 10
Naval Base: 112

Orbit 3:
Name: Brumaire
Type: Planet
Distance: 7.0 J
Starport: Good-quality spaceport
Size: 8000 km
Atmosphere: Standard pressure, breathable
Hydrographics: 40%
Population: 5 million
Government: Subordinate
Law Level: 9
TL: 9
Agriculture: High

Orbit 4:
Name: Harcourt
Type: Planet
Distance: 30 J
Starport: Poor-quality spaceport
Size: 6400 km
Atmosphere: Thin, tainted
Hydrographics: 50%
Population: 100000
Government: Subordinate
Law Level: C
TL: 10
Military Garrison: 451
Research Station: Alpha

Orbit 5:
Name: Regina
Type: Planet
Distance: 55 J
Starport: Top-quality starport
Size: 11200 km
Atmosphere: Dense, breathable
Hydrographics: 80%
Population: 100 million
Government: Impersonal Bureaucracy
Law Level: 9
TL: 10
Naval Base: 19
Scout Base: 200
Wealth: Rich
Political: Sector capital

Far Companion 1:
Name: Darida
Type: Star (M6 V)
Satellites:

Orbit 0:
Name: Augur
Type: Planetoid
Distance: 0.1 AU
Size: 750 km
Code: Empty

Orbit 1:
Name: Kirunda
Type: Planet
Distance: 0.3 AU
Starport: none
Size: 3200 km
Atmosphere: Trace
Hydrographics: none
Population: none
Satellites:

Orbit 1:
Name: Irkirka
Type: Planetoid
Distance: 25,600 km
Size: 500 km
Code: Empty

Orbit 2:
Name: Arkurer
Type: Planetoid
Distance: 35,200 km
Starport: Poor-quality spaceport
Size: 600 km
Atmosphere: none
Hydrographics: none
Population: 70
Government: Self-Perpetuating Oligarchy
Law Level: 7
TL: 9

Orbit 3:
Name: Irgurkar
Type: Planet
Distance: 41,600 km
Size: 1600 km
Code: Empty
Population: 30000
Government: Subordinate
Law Level: 10
TL: 10

Orbit 2:
Name: Elazair
Type: Gas Giant
Distance: 0.7 AU
Size: 0.5 J
Satellites:

Orbit 1:
Name: Lashir
Type: Planetoid
Distance: 1.5 J
Size: 800 km
Code: Empty

Orbit 2:
Name: Diuur Imar
Type: Planet
Distance: 4.0 J
Starport: Routine-quality spaceport
Size: 3200 km
Atmosphere: none
Hydrosphere: none
Population: 400
Government: Subordinate
Law Level: 9
TL: 9

Orbit 3:
Name: Shamardae
Type: Planet
Distance: 4.5 J
Size: 8000 km
Code: Empty

Orbit 4:
Name: Arapan
Type: Planet
Distance: 10 J
Size: 3200 km
Code: Empty

Orbit 5:
Name: Edaku
Type: Planet
Distance: 25 J
Starport: none
Size: 3200 km
Atmosphere: Trace
Hydrographics: none
Population: none

Orbit 6:
Name: Gagamshir
Type: Planet
Distance: 62 J
Starport: Routine-quality spaceport
Size: 8000 km
Atmosphere: Very thin, tainted
Hydrographics: 40%
Population: 3000
Government: Participating Democracy
Law Level: 8
TL: 10
Military Garrison: 125</pre>[/QUOTE]
 
Hi G....RObject !

Did I miss some traumatic event that caused a name change ?


Now that format above is quite near to the way I do it the XML way.
In fact I prefer consequent hierachical structures because they fit to common hierarchical tree data structures.

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">
<StarSystem Name="Gitosy">
<Primary Type="Star" Name="Primary" Class="G6 V" Orbit="0">
<object Type="Planet" Name="Gitosy I Alpha" UWP="G-352200-8" Orbit="0">
<Satellite Type="Moon" Name="Gitosy I Alpha Ay" UWP="Y-S00000-0" Orbit="6"/>
<Satellite Type="Moon" Name="Gitosy I Alpha Bee" UWP="Y-S00000-0" Orbit="40"/>
</object>
<object Type="Planet" Name="Gitosy I Beta" UWP="X-C00000-0" Orbit="1">
<Satellite Type="Moon" Name="Gitosy I Beta Ay" UWP="Y-726100-9" Orbit="11"/>
<Satellite Type="Moon" Name="Gitosy I Beta Bee" UWP="Y-200000-0" Orbit="30"/>
<Satellite Type="Moon" Name="Gitosy I Beta See" UWP="Y-200000-0" Orbit="35"/>
<Satellite Type="Moon" Name="Gitosy I Beta Dee" UWP="Y-300000-0" Orbit="65"/>
</object>
<object Type="Planet" Name="Gitosy I Gamma" UWP="B-000676-9" Orbit="2">
</object>
<object Type="Planet" Name="Gitosy I Epsilon" UWP="F-646314-8" Orbit="4">
<Satellite Type="Moon" Name="Gitosy I Epsilon Ay" UWP="Y-R00000-0" Orbit="3"/>
<Satellite Type="Moon" Name="Gitosy I Epsilon Bee" UWP="Y-300000-0" Orbit="5"/>
</object>
<object Type="Planet" Name="Gitosy I Zeta" UWP="G-584500-8" Orbit="5">
</object>
<object Type="Planet" Name="Gitosy I Eta" UWP="F-866334-8" Orbit="6">
<Satellite Type="Moon" Name="Gitosy I Eta Ay" UWP="Y-715000-0" Orbit="4"/>
<Satellite Type="Moon" Name="Gitosy I Eta Bee" UWP="Y-200000-0" Orbit="45"/>
<Satellite Type="Moon" Name="Gitosy I Eta See" UWP="Y-320000-0" Orbit="50"/>
</object>
<object Type="Planet" Name="Gitosy I Theta" UWP="Y-444469-8" Orbit="7">
</object>
<object Type="Planet" Name="Gitosy I Iota" UWP="F-572325-8" Orbit="8">
<Satellite Type="Moon" Name="Gitosy I Iota Ay" UWP="Y-100200-8" Orbit="5"/>
<Satellite Type="Moon" Name="Gitosy I Iota Bee" UWP="Y-301000-0" Orbit="15"/>
</object>
<object Type="Planet" Name="Gitosy I Kappa" UWP="H-402528-8" Orbit="9">
</object>
<object Type="Planet" Name="Gitosy I Lambda" UWP="H-613467-9" Orbit="10">
</object>
<object Type="Planet" Name="Gitosy I Mu" UWP="G-300319-8" Orbit="11">
</object>
</Primary>
<Binary Type="Star" Name="Binary" Class="M3 D" Orbit="0.02">
<object Type="Planet" Name="Gitosy II Alpha" UWP="X-000000-0" Orbit="0">
</object>
</Binary>
<Trinary Type="Star" Name="Trinary" Class=" M3 III" Orbit="12">
<object Type="Planet" Name="Gitosy III Alpha" UWP="X-100000-0" Orbit="0">
</object>
<object Type="Planet" Name="Gitosy III Beta" UWP="X-200000-0" Orbit="3">
</object>
<object Type="Planet" Name="Gitosy III Gamma" UWP="X-300000-0" Orbit="4">
</object>
<object Type="Planet" Name="Gitosy III Delta" UWP="X-400000-0" Orbit="9">
</object>
</Trinary>
</StarSystem></pre>[/QUOTE]Ok, I kept the UWP...

Oh, regarding limitations.
I just was surprised about this bloody Excel, which isnt able to cope with more than 65536 columns.
When I tried OpenOffice (I thought "hey, thats new, its Java, its free, its better) but it dies after 32000 column.
So, the tiny Hipparcos catalogue with its 118000 lines of data is just to much for these programs :(

Regards,

Mert
 
Re XML: You actually pinned the tail on the donkey while blindfolded. My format is YAML, a data serialization format spoken by scripting languages such as Perl, Ruby, Python, PHP, etc. Alas, Java doesn't have a YAML parser to date :(

http://yaml.org

Re UWP: That's OK, the UWP is still acceptable. I'm just beginning to think it should be the approximation, hence derivative rather than the authority. I may change my mind several times over this for awhile.

Re Excel: Will OpenOffice accept huge hunks of data?

Re Namechange: I'm undergoing a revelation that began with the QSDS seven years ago, and coincided with a couple of well-placed arguments on RPG.net. I only hope it's not too late...
 
You need to probably use multiple sheets Mert.

Or use a DB and demand-load parts of the data from the DB as needed.

Rob: Never to late to become a bit of a grognard. Turn to the dark side..... <sound of ventilator breathing>
 
Kaladorn, I use a DB and several sheets now, but really, to have it in one spreadsheet was just fine and I am really annoyed, that such "sophisticated" programs have a column limit at the 2^15/2^16 margin.

Regarding the use of the UWP there is always the option to specify parts of data in detail. So, we could have both, the approximation via UWP and details via additional attributes.

Eg.:
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">
<object Type="Planet" Name="Gitosy I Mu" UWP="G-300319-8" Orbit="11" Density="6.8" SurfaceG="0.11" >
</object> </pre>[/QUOTE]What would You think about specifying additional data like FarPorts or DeepSpace stations in the system profile ?
Anyway I will have a look, if there is a kind of YAML control or converter for VB...


Regards,

TheEngineer
 
Engineer,

Yes, we will always have use for the UWP. In fact, the mainworld may be the only unit we really need expanded-out data for, since that's basic Traveller.

What additional data to include and how it is represented becomes a new challenge. Probably FarPorts and the like can have their own UWP entries; offhand, I would suggest that they be labelled as planetoids (size 'S'), but that may be misleading, since surface atmosphere and hydrographics are probably zero. An interesting problem.

I doubt VB knows YAML, but you never know.
 
Anyone else think about doing a decent capacity relational database.. the text files people like work as a report, I'd use something like GURPS spaces format for the details, with code to convert to UWP for ouput, extended UWP if required.

And an import routine or two to handle existing data (ASCII or some sort for file exchange) the internal data format and how it gets presented need not be the same.

Transfers in XML etc not too hard to do.

Tis a question of deciding whats the minimum data required (UWP i'd say) and then what else you want to fit to it. as long as its capable of generating its own data keys you can exchange systems or sectors as reports or some sort.

the actual efficency isn't really an issue. I work with decent sized DBs for a living, waste some space, normalise it then optimise if you really need to. for home use the difference witha big datasaet (several 100's of megs) will be a few seconds.

only if you want to put it on-line directly does it really matter hoe efficent the database is, i'd have a less effieicent but normalised design that stores (or at least can store) way more detail than is actually required, hook it up to something that can take a UWP code for say atmosphere, and produce something more detailed that still fits, like expand just what the 'taint' could be etc

cross platform is nice, but a clean SQL structed database can be implemented cross platform, who cares if tis Access on one machine and MySQL on another? as long as you can exchange files it will work
 
Yep, people have been grousing about RDBs for Traveller data on and off here. As in a lot of things, it's mainly a project waiting for the right person to come along...
 
Claire Rand,

Oh yes! I've one of those "grousers" robject mentioned.

I've looked at it several times.

The trouble is, finding a natural key that uniquely identifies a solar system object.

I've got several ideas, but they would involve fundamental alterations to the ways in which solar systems and their objects (or "bodies") are generated.

For instance, I've very recently been discussing that solar system generation must be star-centric. The Primary Star and then all companions must be generated. Malenfant's excellent new stellar generation program should be used in preference to any other rule, as it avoids generating stars never observed by astronomers, and creates a better average distribution of stellar types.

The old orbital-slot system must be dropped.

All objects a star will have are generated one at a time, and then, at that point, assigned an orbital radius; and that act, the assignment of the orbital radius, is what "creates" an "orbit", instead of the old slot-based system.

This would give a body in orbit around a star a Focus (the star), a Radius, a Position (which would be the displacement, in kilometers, along the circumference of the orbit, providing for support of rosette-type systems), a "direction" (orbits can be going in either direction, even if it's not common), and a Speed (from which we can calculate the orbital period).

Once the orbit is known, other information can be generated, in the correct order and more properly affecting each other.

I suppose something can be cobbled together that exactly represent the existing worldgens (one of them). But my heart is set upon a "new" worldgen, one that can only be promised by the oncoming T5 (although T20 has made some very promising steps in the right direction).

If you dig into the matter, parts of the old Book 6 system are either difficult to use or impossible to succesfully interpret.
 
To continue Chris' thoughts...

I've thought the top-level thing that needs a unique key is the Hex, which can be assigned a Ring/Ray value; from there, Solar System entities can point to their owning Hex just fine; the solar system itself would probably have a unique ID (it doesn't make sense to use the name, since names change, and sometimes even mainworlds change).

Of course, Ring/Ray assumes you want to keep a 2D universe, and once we start innovating the temptation to go 3D becomes strong.

I never really took to the Book 6 system either. It seemed a bit bulky for my tastes.

And unfortunately, Mal's stellar gen is for existing mainworlds: it fixes problems that crop up due to habitable mainworlds mixing with very harsh primaries.

I've also used something like what Chris is describing above; generate the primary, then proceed outward planet by planet, assigning orbital radii as you go; I've also thought that an accretion method would be pretty interesting, even if done by hand.

Both methods could be made simply elegant on the top level, while being painfully detailed on lower levels, for those who like that kind of pain.
 
You must log in or register to reply here.

Similar threads

D
Help tracking down a program
Replies
7
Views
1K
Wintertree
W
robject
Calculating trade values in T5 using BASIC
Replies
1
Views
1K
Enoff
Enoff
P
HIGHGUARD - A DATA card generator that uses Highguard Templates
Replies
1
Views
1K
Peter Kreft
P
P
Explanator - A software that explains worlds
Replies
12
Views
4K
Redcap
R
S
MT Only: MT Referee's Manual 1987 2nd Printing Extended System Generation
Replies
7
Views
1K
snrdg082102
S
Back
Top