ISO: Sector Mapping Software

[kaladorn]

Now, before anyone runs off and names Galactic, H&E, MADDog's Mapper, Universe, etc.... let me describe what I'm looking for.

Something that shows me a blank sector map, lets me use my mouse and go 'planet here, another one here, another one there' and then use some drop downs to say 'place an A starport here, an X-boat route here, limit this planet to tech-7, a water world here' and then say 'fill in the blanks' and have the rest filled in appropriately.

My problem is most of the completely random ones don't come close to generating what I'm after - I want to be able to set the system up by giving it what the computer geeks call 'hints' beforehand. And having it use those as a guide to generating the sector. Then have some sort of easy drag and drop editing capabilities to modify things if need be (drag a system from hex 0310 to 0309, move an x-boat route, etc).

I'm unaware of any current tool which will let me do that.

Is there one?

 

[Granpafishy]

I know, I know, don't just rattel off names, but, the 1.0.8 version of H&E allows you to create sector/subsector maps, one system at a time if you want. It allows you (after a sector map has been made) to move planets where you want. And it allows you to alter anything in that system before and after saving it. It doesn't go quite as far as what your asking for, but it comes pretty close. Mind you, my experince is with 3 versions of H&E (1.0.3, 1.0.4, 1.0.8) and Galactic, I don't know anything about the others. Also bear in mind, the H&E2 is in beta test right now (I'm one of the testers), and the 2nd of 3 releases will be released on the 19th. The first delt with sector/subsector generation. The second deals with system/planet generation. The third will deal with galaxy generation (placing the sectors where you want in relation to others). Here's the current page for it

http://www.heavenandearth2.com/

He has the link for the oringal(1.0.4) on there and I can send you the upgrade (1.0.8, it's not very big) if you wish.

If you DO find a program that will do what you are asking for, please let us know. I'm sure there are many of us on the board that would love being able to make the systems we want eaiser.

Hope you find either this or something else useful.

 

[kaladorn]

Originally posted by Granpafishy:
I know, I know, don't just rattel off names, but, the 1.0.8 version of H&E allows you to create sector/subsector maps, one system at a time if you want. It allows you (after a sector map has been made) to move planets where you want. And it allows you to alter anything in that system before and after saving it. It doesn't go quite as far as what your asking for, but it comes pretty close.

I think I have the predecessor, some sort of World Builder. Maybe on the other machine I actually have H&E. Have to check.

Mind you, my experince is with 3 versions of H&E (1.0.3, 1.0.4, 1.0.8) and Galactic, I don't know anything about the others. Also bear in mind, the H&E2 is in beta test right now (I'm one of the testers),

Was going to be, but had real reservations once the programmer started including stuff that meant I had to install certain MS components I really wasn't comfortable with....

and the 2nd of 3 releases will be released on the 19th. The first delt with sector/subsector generation. The second deals with system/planet generation. The third will deal with galaxy generation (placing the sectors where you want in relation to others). Here's the current page for it

http://www.heavenandearth2.com/

He has the link for the oringal(1.0.4) on there and I can send you the upgrade (1.0.8, it's not very big) if you wish.

I'll check which version I have on the other machine. I'll get back to you.

If you DO find a program that will do what you are asking for, please let us know. I'm sure there are many of us on the board that would love being able to make the systems we want eaiser.

I've started looking into what it takes to render JPEGs, GIFs, or PNGs. If I can get a handle on the rendering (I really hate UI work because if it isn't done right, it can soooo suck!) of the images, I think I could probably do the other part. If I knew someone who was a good Java or C++ front end guy, I could volunteer to do the backend work on such a project.

One of my other pet peeves is there are several 'standard' datafile formats out there. None of them are entirely adequate. And none are, to my knowledge, explicitly documented. THIS to me seems to be a problem.

I was thinking of building a page and writing data format descriptions for all of the standard sector data formats used by the various programs, consolidating the information to one site, and then writing a composite plaintext and XML version that actually better represented things. I find most of these formats make things like adding extra symbols, graph lines such as xboat routes, etc to be a bit of work or sort of an apparent 'graft on'.

I'd like to see one able to represent all key sector data in one file, ideally human readable, and something portable (hence XML perhaps) that oculd be easily imported into various other tools or programs.

I have seen someone start a traveller system description DTD or XSLT but it didn't look very intuitive or easy to read... in fact, I thought it was a bit of a dog's breakfast....

 

[Granpafishy]

I wish you luck in finding or producing the program.

I'm no longer a programer (knew basic back oh... 15 years ago) so a good portion of what you were listing as wants, went right over my head. Oh, one glitch I seam to have found with the latest version of H&E1, it randomly doesn't generate a sector when told too. I circumvented this by having 1.0.4 & 1.0.8 both loaded on my computer.

I look forward to hear from you on any progress one way or the other.

 

[tjoneslo]

Originally posted by kaladorn:
I have seen someone start a traveller system description DTD or XSLT but it didn't look very intuitive or easy to read... in fact, I thought it was a bit of a dog's breakfast....

RE: XML. XML is a scary item. I think you can either make it human readable or machine readable but not both.

Have you seen TravLib?

It is also an attempt to do what you want, using C/gnome and scheme. It may be worth looking at.

FWIW: I've started looking at doing a Java/XML version of Galactic/H&E/Universe. It's now in an early alpha state. I was planning on getting the XML DTD done this weekend, but not having my proper reference manuals from work and out of town guests made that difficult. Ah well. If I get more done would you be willing to offer critiques?

 

[robject]

travtrack/travdb looks interesting... scheme is a nice, portable language for functions (portable in that interpreters exist for many platforms and in many languages, including Java).

I was thinking along the lines of translating UWP data into a CSV file or something like that. From there, anyone who can write a basic parser can use CSV data. Moreover, additional data can be stored in additional CSV files, be it world-builder-type info, starship info, corporate info, what-have-you. Essentially a text database dump.

I've got a perl script which does a good job at reading UWP-sector-format files, and is somewhat forgiving when the formatting isn't exactly 'standard'. The main trick is anchoring the pattern match on those two critical pieces of info, the hex location and the UWP. After that, one can go a long way in either direction.

Here's the core matcher. It can still be tripped up, but it does reasonably well. Please note that it also parses in the apocryphal "XBoat-link data" following the stellar data.

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;"> # Convert really really old format into new format.
$line = sprintf( "%-49s 001 ?? ??", $1) if $line =~ /^(.{29,50}\s*)G\s*$/;
$line = sprintf( "%-49s 000 ?? ??", $1) if $line =~ /^(.{29,50})\s*$/;

return () unless
( $line =~
#
# name col row uwp base codes zone pbg allg. stellar xboat
#
/^(.*)(\d\d)(\d\d) (\w.{8}) \s?(.) (.{15}) (.) \s?(\d{3}) (..) ([^:]*)?\s*.*)?$/
);</pre>[/QUOTE]

 

[robject]

Ah, as long as I'm here, y'all might like to know that I've imported several sectors into MySQL tables with names like "asteroid", "gasgiant", "hex", "planet", "registry", and "starsystem".

I've got 2,010 hexes & starsystems filled in, which accounts for 2010 planets (!), 4156 gas giants, and 27,538 items in the 'registry'. Each mainworld has a disinct starport, landing field, commodity exchange, bank, pub, and shipyard -- all of which are currently rather abstract, but present nonetheless. There are also 2199 starships, scattered throughout all of the shipyards waiting to be sold.

Let's see... those 2199 starships are type:
A (192)
A2 (593)
A3 (59)
R (332)
M (259)
Y (156)
S (86)
S2 (133)
C (114)
K (220)

Here's the columns for each ship:
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">+------------+-------------+
| Field | Type |
+------------+-------------+
| id | int(11) |
| name | varchar(20) |
| type | varchar(4) |
| year_built | int(3) |
| wear | int(4) |
| sr_free | int(4) |
| lb_free | int(4) |
| cargo_free | int(4) |
| fuel | int(4) |
| did | int(11) |
| parsecs | int(2) |
| eta_day | int(3) |
| eta_hour | int(2) |
+------------+-------------+</pre>[/QUOTE]The 'type' field indexes into an architectural table describing the capacities of that ship type. New types can conceivably be created, and then ships of that type can be 'built'. Here's the architect table. It's pretty basic. I suppose I ought to have a 'component' table and define a ship by its type and list of components. Have to think about that some.

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">+-------------+-------------+
| Field | Type |
+-------------+-------------+
| type | varchar(4) |
| name | varchar(15) |
| hull | int(3) |
| streamlined | int(1) |
| maneuver | int(1) |
| jump | int(1) |
| staterooms | int(4) |
| low_berths | int(4) |
| cargo_hold | int(4) |
| fuel_tank | int(4) |
| price | int(4) |
+-------------+-------------+</pre>[/QUOTE]Yeah, the more I think about it, the more I see the usefulness of a cross-reference table mapping architectural types to components. Something like this:

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">table architect
(
type char(4),
component varchar(20)
)

table shipmods
(
shipid int(11),
component varchar(20)
)

table component
(
id varchar(20),
class varchar(20),
subclass varchar(20),
rating int
)</pre>[/QUOTE]Components would include jump and maneuver drives 1-6 and weapons, plus any special stuff like lab space, a spinal gun, etc. The 'ship' table should have the number of hardpoints (varies per ship) and whether or not it's a planetoid.

Something like that, anyway...

OK, enough rambling, I really ought to get some sleep.

 

[kaladorn]

Originally posted by tjoneslo:
RE: XML. XML is a scary item. I think you can either make it human readable or machine readable but not both.

Not so. I wrote a giant ERP tool for a major project that included some stupid number of fields. Making it easily readable by the human and usefully readable by the machine required thought, but it was not an impossibility. In fact, the end result I was quite proud of. If I knews XSLT (I only knew XML and DTD), I could probably have done an even better job.

It is also an attempt to do what you want, using C/gnome and scheme. It may be worth looking at.

This sounds '*NIX'ish. I don't have no stinky antipodean waterfowl around here...

FWIW: I've started looking at doing a Java/XML version of Galactic/H&E/Universe. It's now in an early alpha state. I was planning on getting the XML DTD done this weekend, but not having my proper reference manuals from work and out of town guests made that difficult. Ah well. If I get more done would you be willing to offer critiques?

Of the XML, the DTD or the Java?

Yes. Critcism is something that isn't hard to manage. I'll even try hard to make it of the useful variety

 

[kaladorn]

I was hoping for an XML format because I want something that both my PC and I can read (and that PC can be running a GatesDaemonOS or a PenguinLoverOS or even a GotterdammerungMacOS). I want something cross platform but also readable by human beings with a glance, not with arcane mental gyrations to decipher which code means what!

Yes, this won't make for the most compact sector files, but my final comment to that is *who cares!?*

I say that because hard drive space and CD storage space is cheap and you can get a whackload of characters into 680Mb or into a few Gb on a hard disk.

The ability to just open a sector file, know what sector it is, be easily able to browse the systems using IE or something else that can open up XML straight (or some of the DOM tools) would be a great and wonderous thing I think. And having my machine able to parse and absorb this data would also be wonderful.

XML is bloated (no arguments on that one). OTOH, it can be nice, easy to read, easy to browse, and better in many ways than text or binary formats.

 

[robject]

I see no conflict with having an XML reader-writer for Traveller data. We did once attempt to hammer out a DTD for system data; one wonders where it is now. But of course, portability is a strong argument, and so is standardization, so XML away! In fact it could be relatively easy to convert between XML, YAML, "Traveller", and other odd formats.

Your design might even be used by other Traveller coders out there.

Which reminds me... anyone have working experience with YAML? I heard it's being incorporated into XML, thus solving readability, standardization, AND size all at once...

 

[FlightCommanderSolitude]

Originally posted by kaladorn:
...I want something cross platform but also readable by human beings with a glance, not with arcane mental gyrations to decipher which code means what!

For my own nefarious purposes I crunked up some Perl scripts that sucked in all of the sector files that I grabbed from here:

classic.tgz

and reformatted them into one giant xml file that looks something like this (excerpt):

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;"><data>
<sector name="Spinward Marches">
<subsector quadrant="a" name="Chronor">
<system hex="0101" uwp="C330698-9" name="Zeycude" base="" comment="Na Ni Po De" zone="" giant="3" allegiance="z" />
<system hex="0102" uwp="C1207B9-A" name="Reno" base="" comment="Na Po De" zone="" giant="3" allegiance="z" />
<system hex="0103" uwp="B263664-B" name="Errere" base="z" comment="C0 Ni Ri" zone="" giant="0" allegiance="z" /></pre>[/QUOTE]This format is admittedly pretty simple; I'm sure you can come up with a format that suits your needs. One thing I haven't added yet are the xboat routes and polity boundaries, which I'll get to eventually ie when I need it and I have time to do it.

I found some other xml stuff for Traveller at:

AstroMLv6.xsd and AstroMLv6.xml. These appear to attempt to incorporate all kinds of data that, frankly, I don't care about.

I suppose that's going to be the key bit of trouble when encoding Traveller astrogation data: what do you include? There are those like myself that are happy with essentially the CT stuff; other people understandably want support for MT/TNE/GT/T4/T20 stuff, as well as non-canonical/homebrewed extensions. I say start with something simple and build on it as needed.

BTW, YAML? WTF!

 

[kaladorn]

Nice XML format in that you've used XML data tags effectively. I'd like to see the sector tags also feature the X, Y from some reference point (so you can locate them in the larger map of known space) but that's a minor quibble.

The thing about XML is that you should be able to setup your format in the DTD such that there are mandatory and optional bits, thus the 'extra stuff you don't want' could be added in, but would not be required. Thus it could be stripped and the DTD would still permit it, but for those who want the extra field (ie me), they could be present and the same tools could read/display the result.

I saw the system XML description - that was the document I was referring to as (IMO) unreadable by mortal man. It was... boggling.

Even though it consumes some space, I like clear tag attribute names and clear tag names as that makes the thing much more humanly readable or text-mode browsable.

I also like people who intelligently harness the nested nature of HTML (using your example, I could have 30 sectors in the same doc, all collapsed, and due to your use of tags, I could still pick out which was which, for instance).

I undoubtedly *will* take a stab at an XML format once I get some documentation up on the existing file formats. I want to understand what we have as a basis point and then start a discussion of what we *should have* and what should be mandatory or optional.

YAML - Yet Another Modelling Language I think. As for the claim this will solve all the ills of the modelling world.... heh... There'll be a pack of meat-eating K'kree before that's likely.

 

[robject]

Hey, that's a pretty nice XML format. Concise, you know? It makes me think that there ought to be concise tags in the 'standard' as well as 'line-item'-style tags for, erm, atomic data.

YAML™ (rhymes with "camel") is a straightforward machine-parsable data serialization format designed for human readability and interaction with scripting languages such as Perl and Python. YAML is designed for data serialization, formatted dumping, configuration files, log files, Internet messaging and filtering.

It uses horizontal whitespace and something like sigils to demarcate different pieces of data.

It's NOT designed for generic document support. It's designed for data. Here's an example invoice they give on yaml.org:

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">--- !clarkevans.com,2002/^invoice
invoice: 34843
date : 2001-01-23
bill-to: &id001
given : Chris
family : Dumars
address:
lines: |
458 Walkman Dr.
Suite #292
city : Royal Oak
state : MI
postal : 48046
ship-to: *id001
product:
- sku : BL394D
quantity : 4
description : Basketball
price : 450.00
- sku : BL4438H
quantity : 1
description : Super Hoop
price : 2392.00
tax : 251.42
total: 4443.52
comments:
Late afternoon is best.
Backup contact is Nancy
Billsmer @ 338-4338. </pre>[/QUOTE]Very, very human readable, and, apparently, it's also machine parsable. Win-win, I guess, although I don't know if there's a Java YAML parser out there yet, but there are bindings for Perl and Python.

 

[kaladorn]

Isn't *anything* machine readable with the right parser?

I mean, what we see their isn't machine code/opcodes for the processor... nor is it compiler intermediate language nor anything of that sort... nor is it bytecode. It's some grammar that looks okay to humans and which a machine can decode, which is (in a sense) like what XML is.

In truth, an XML format is only *one* format which traveller tools should be able to read/write. It would be nice to write some standardized data structures and then create the kind of system or utilities that can import and populate them and export from them populated versions into a wide variety (text, XML, HTML etc... possibly compatible with YAML or others) of output formats.

But yes, I am a dreamer...

 

[robject]

There's a wonderful overview of YAML here:
http://yaml.freepan.org/index.cgi


Here's some practical YAML. First, documents are separated by three dashes on a line, ---.

Lists appear as items with a dash in front of them, such as:

- Regina
- Hefry
- Jenghe

Maps, which are something like hashtables or string-indexed arrays, use the colon:

1910: Regina
1809: Ruie

You can nest lists and maps. Peer elements with a common parent must all be at the same indentation level.

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Spinward Marches:
- 1910:
Name: Regina
UWP: A788234-C
Bases: A
- 1809:
Name: Ruie
UWP: C444944-8 </pre>[/QUOTE]There are also a plethora of text-grouping indicators.

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">---
Spinward Marches:
- 1910:
Name: Regina
UWP: A788234-C
Bases: A
Notes: >
This is a text block where lines are
grouped together into one paragraph.

Paragraphs are separated by an
empty line.
- 1809:
Name: Ruie
UWP: C444944-8
Notes: >
Marc Hault-Oberlindes might be here.</pre>[/QUOTE]And there's the five-minute overview. I guess that just scratches the surface.

 

[FlightCommanderSolitude]

Originally posted by robject:And there's the five-minute overview.

Nice! Thanks, that hit the spot. In some ways this is nicer than XML in that you can just dump your data structures into YAML without much thought. I think XML, for my limited purposes, is a little better in that I can sift through a big blob of it event-wise and find stuff, although I imagine there are or could be stream-based readers for YAML too.

 

[robject]

Yes, I think XML is still a more popular choice, and quite useful due to the support available.

 

[kaladorn]

Yeah, that was a good precis.

XML is a bit more generally useful given:
1) abundance of XML viewer-editor tools
2) ability of things like IE to display XML without a special add on
3) lots of XML streaming tools and add in modules for various languages

YAML may have #3, but it lacks 1 and 2 I think. (it is text, but it can't be displayed with syntactic highlighting etc in IE out of the box)