Extended System Data

[aramis]

Originally posted by RainOfSteel:
I personally prefer "aligned" space-delimited layouts, myself.

This makes it far easier to transport the data across platforms.

Comma/Tab delimited will do in a pinch.

The main problem with starsystem data in the OTU UWP is, that it's mainworld-centric. The real center of the starsystem, in OTU terms, is the Hex it's in (Primary Key in a Galaxy layout would be Sector X,Y plus Hex Col,Row), and the star and companion stars in that Hex. Worlds (mainworld or non-mainworld) are details hanging off their stars, not the other way around. Or, at least, that's IMO.

Drat, work calls <pesky salary need thingamagigit />

Which is why one could use
SecAbr.Hex#.Or#.Sat# mode for a huge text database.

For Ex
SpMa.0303.3.0 for the world in orbit 3 of the system in hex 0303 of the Spinward Marches, and
SpMa.0303.3.2 for same world's third moon.

I like text formats to be human readable, too.. it makes figuring out what the stuff is easier, and allows partial recovery in case of lost clusters.

 

[FlightCommanderSolitude]

Lost clusters? Ouch.

 

[robject]

Originally posted by Aramis:

Which is why one could use
SecAbr.Hex#.Or#.Sat# mode for a huge text database.

For Ex
SpMa.0303.3.0 for the world in orbit 3 of the system in hex 0303 of the Spinward Marches, and
SpMa.0303.3.2 for same world's third moon.

I like text formats to be human readable, too.. it makes figuring out what the stuff is easier, and allows partial recovery in case of lost clusters.

Mmmmm... grumble grumble... you know, that does do less violence to the current UWP formatting too... as much as I like to innovate, I have to admit Aramis' format is compelling too.

I might want to use a more generic sector name. Perhaps offset coordinates from Core or something... I dunno.

But if I lost data, I imagine the entire file would be corrupt. And I'd want to web out to someone else's site to recover the data (yet another problem to solve, I know).

 

[kaladorn]

Originally posted by RainOfSteel:
The indentation kills it all.

Please elaborate. I regularly have to parse data that may include significant amount of whitespace or tabs or the like and don't see it as much of an issue. I hardly agree that it 'kills it all'. I'm interested to know why you think so....

 

[robject]

I think a traditional language (such as C) could parse my example relatively painlessly (as long as it can ignore leading whitespace). scanf() implicitly throws out whitespace, if I recal correctly.

 

[TheEngineer]

Hi !

I would agree with Aramis and store the system data in a plain, sequential and delimited format, which is at best readable and modifiable with just a simple text editor and any plattform and without any need of scripting or programming.
Guess its better for any spreadsheet or database work, too.
By using some tag columns it should be possible to arrange the data in a nice view simply by sorting.

IMHO some compromise between storage level and presentation level might lead to something, which is not really efficiently usable on any of these levels without further addons, and thus narrowing usablity.

Maybe thats a bit conservative, but at least all those system data stuff is just table data, even if there is a 3 level hierachy.

Best regards,

Mert

- Contructions like plain surfaces -

 

[aramis]

One of the real problems with most ML's is that, for low data volume entries (like the UWP's, even fully extended) they can wind up doubling or trebling the data space needed. True, not a big deal for the modern COMPUTER, but remember, many people are still making due with modems, and restricted throughput to/from machines.

If one is slinging around large databases, CDT, SDT, and TDT text files are excellent means of pushing around large databases of small records.

Likewise, ASCII text is a world-wide standard. I can read it on old Apple //s, New Macs, CP/M, Linux, DOS, WinXX, and most other new and old OS's (some key exceptions include MacOS prior to 7) due to the fact that nearly every OS shipped with a text editor somewhere.

 

[FlightCommanderSolitude]

Originally posted by Aramis:
... (some key exceptions include MacOS prior to 7) ...

Um, huh?

 

[RainOfSteel]

Originally posted by kaladorn:
</font><blockquote>quote:</font><hr />Originally posted by RainOfSteel:
The indentation kills it all.

Please elaborate. I regularly have to parse data that may include significant amount of whitespace or tabs or the like and don't see it as much of an issue. I hardly agree that it 'kills it all'. I'm interested to know why you think so.... </font>[/QUOTE]How is it, when parsing it (either throwing out the whitespace, or counting spaces or tabs), that you know for sure what "level" that line is at?

Sure, if you want to program your parser to interpret each possible level of indentation, that's fine. I view that as a pain in the neck. That's what I meant be "kills it all", I meant that it was annoying and or a pain in the neck. Yes, it can be programmed, but why export something into a format that is only tougher to import?

I would also like to point out that in my post that followed on the post you mention states that I realized that these formats were being done for human-readability purposes, not for formatting for ease of import into other computer applications.

Obviously, if the data was being exported for use in imports, it would be formatted differently.

 

[robject]

Nah, a parser needn't even care about the indentation when reading... each block of information has a header that's easy to detect. Leading whitespace can be ignored completely.

Or maybe I'm missing the boat completely...

 

[aramis]

Originally posted by FlightCommanderSolitude:
</font><blockquote>quote:</font><hr />Originally posted by Aramis:
... (some key exceptions include MacOS prior to 7) ...

Um, huh? </font>[/QUOTE]MacOS 5 and 6 did not include a text file reader/editor as part of the OS. One of the few that shipped without the ability to read text files as part of the OS. IIRC simpletext was developed during the System 6 days. At the release of the Mac, the lack of a text editor was a "Major" flaw. There were and are several good freeware and/or cheap shareware ones for systems 5 and 6.

MS DOS has Type and More.
Apple // had a similar capability.
CP/M has Type
almost all posix systems come with 2 or more (Vi and emacs being common).
VMS had edit
MacOS7-9 shipped with simpletext
MacOS10 has 3+ (at least two posix ones, and also TextEdit)
Atari's OS had some feature to read text files, in ROM, IIRC.

 

[FlightCommanderSolitude]

The indented style robject posted is far superior, IMO, to crushing everything down to a single-line entry. It's much easier to eyeball.

Ideally, route and polity boundary information would be included. How might that go? One trick is with xboat routes that exit a subsector, or exit a sector - especially if your data format mirrors the natural hex/subsector/sector hierarchy of Traveller. For example, let's say you have a chunk of data that represents the Jewell subsector, and another chunk of data that represents the Regina subsector. How, and where, do you note that there is an xboat link between Efate/Regina and Lysen/Jewell? In one file? Or worse, in both? The problem turns up again at the sector scale, too. Ideas?

MacOS 5 and 6 did not include a text file reader/editor as part of the OS.

I'm fairly certain that is incorrect. TeachText shipped with System 6 at least, and probably originated in System 4 something. I think there was something that was just called Edit before that. And MacWrite shipped with the original Mac; I'm pretty sure it could open plain text and not just its own files. I recall no outcry over the "lack of an editor". Lack of a programmer's editor, sure ...

 

[kaladorn]

Originally posted by robject:
Nah, a parser needn't even care about the indentation when reading... each block of information has a header that's easy to detect. Leading whitespace can be ignored completely.

That's what I thought.

Add to which you can use templates of various sorts or sub parsing scripts to parse individual entries (even versionizing your parsing template), this really isn't that gross IMO.

The other nice thing is textual data usually compresses reasonably with a good ZIPping. So if you have to move a large database worth of data, you squish it down and off you go.

 

[kaladorn]

The trick is if you are using sectorwise coords for your planets, how do you represent destinations outside the sector?

Use a 'galactic' coordinate system. H&E and Universe and other systems had to deal with this.

 

[robject]

...and a partial answer to that is to use Ring/Ray notation, which has been around since (at least) The Traveller Book.

My big beef with Ring/Ray is that Sylea passes through an ODD Hex Column but an EVEN Ray (Ray Zero), which means one has to use two slightly different distance formulae depending on which coordinate system you use. My fix is to shift everyone over (forcing Sylea to Ray 1) and delete Ray 0 completely.

Update. Hey, you know what? I think I'm wrong... I think the coords of the reference world, Sylea (Core 2118) is 10,000 Ring/Ray 1, which is OK. Well thank goodness, I thought it was all a mess!

 

[aramis]

Originally posted by FlightCommanderSolitude:
</font><blockquote>quote:</font><hr />MacOS 5 and 6 did not include a text file reader/editor as part of the OS.

I'm fairly certain that is incorrect. TeachText shipped with System 6 at least, and probably originated in System 4 something. I think there was something that was just called Edit before that. And MacWrite shipped with the original Mac; I'm pretty sure it could open plain text and not just its own files. I recall no outcry over the "lack of an editor". Lack of a programmer's editor, sure ... [/QB]</font>[/QUOTE]Most New machines shipped with MacWrite. The OS didn't. Not all of us had new machines; used ones often had to be updated. 6.0.8 DID ship with teachtext; 6.0.4 didn't. My mom's LC shipped with NO editors installed and no text editor; simpletext was on the 6.0.8 update, as well as in the PageMaker installs. Notepad, which was text only, didn't open nor save files. Led to LOADS of pirate copies of MacWrite, and the wide dissemination of seveal BBS-spread shareware ones.

There was some outcry, but not much; very few people bought the ones without preinstalled software. There was extensive grousing on the BBS's I was on... I kept my Apple II to BBS, as I didn't have a good comm program for the mac....

 

[aramis]

In a traditional sector notational system, one could use numbers up to -9 for off up/rt, and up to 42/49 for the other two.

Fairly simple, and retains positions relative to the relevant sector.

 

[robject]

My other thought ties in with a couple of threads I've seen on COTI -- first, habitable mainworlds seem too commonplace; second, there's no way to really tell what a world's "standard pressure" atmosphere is made of.

I saw a post here that expressed the absolute difference of a world's physical stats from Terra's physical stats as a letter, with 'M' being Earth type (of course).

I wondered if that data plus the population & TL digits could be used to determine if the world is truly habitable... or if the population lives in domed or underground cities.

The process would be something like this: put the numbers together, grind them up, and see what comes out. Insert that value inside the UWP... the COTI poster inserted it between Hyd and Pop -- not unreasonable: if the 'digit' is actually a letter code it might stand out enough. Or just add a classification code with the Trade Codes. Or allocate some more letters for Atmosphere.

Here's the kind of thing I'm thinking of. This is untested, by the way. Caveat Traveller.

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">RULES: Take a mainworld with an atmosphere in the breathable ranges,
BUT doesn't have the "Ag" trade classification (?),
and filter it:

- No water present:
- World size 1-5:
- Code: Tm
- CO2 with some O2
- Example: Mars
- World size 6-A:
- Code: Tv
- CO2 with some N2
- Example: Venus
- Water present:
- Population 6-A and (TL 9- or pop mult is odd)
- Code: Te or none
- N2, O2, some CO2
- Example: Earth
- Otherwise:
- Code: Tt
- N2, NH3, complex hydrocarbons
- Example: Titan</pre>[/QUOTE]Problem with the above: it's too deterministic. I need a pseudo-random way to make some lower-pop worlds "nice", and a bare few higer-pop worlds "horrible".

Perhaps using a rule-of-thumb for determining likely interstellar traffic would make it more likely that a horrible world could have a higher population.

And of course this clashes with the Traveller Trade Classification codes, which I should also be taking into account!


Examples
Keanou C792348-8 Tt

According to my brittle process, Keanou has a N2 + NH3 atmosphere, with some complex hydrocarbons.

D'Ganzio A120610-E Tm

...and D'Ganzio is Marslike...

Lanth A879631-D Te

...and Lanth is Earthlike.

Nah, this needs work.

 

[kaladorn]

Let's try another point:
What about the many non-human races?
What about human races geneered to not follow standard hab profiles?
What about tech that makes outside climate little or no factor in habitation?

Ah, it isn't a simple answer! And do census figures always represent just humans? Nay I say! So how can you tell, from a pop digit, who lives there? Ye canna, Cap'n J.T.!

Aye, far from ideal would our old UWP be as a ye olde compleat descriptor...

 

[aramis]

Well, WRT Races:

under 5% is not considered at all.
5-94% of non-standard-for-the-sector is rated with an annotation in the data line, currently... or supposedly so. (in practice, the notation is available but unused.)

Besides, Traveller population are in sophonts, not humans.