Ah, I think the same could be said of the CotI forums. This thread went from...
Put your pet concept for Galactic Astrography for Traveller here...
.. to ..
Yayoi/Yaoi is Japanese gay ⌧ manga
o: .. :rofl: .. 
Galactic Astrography for Traveller
- Thread starter robject
- Start date
Put your pet concept for Galactic Astrography for Traveller here...
.. to ..
Yayoi/Yaoi is Japanese gay ⌧ manga
o: .. :rofl: .. 
And in particular, my script now keeps the random word it generates... surf over to here:
http://eaglestone.pocketempires.com/survey/t5-prog/t5sysgen-cgi.pl
Enter in any string you like as the sector key, up to appx 20 characters in length I think.
It's alright, but...
You need to add options for Sparse and Dense distributions. Right now, it only seems to do a Standard distribution. Just saying.
Yep, post processing is needed. It also doesn't cap TLs.
Update. Now we can specify density, TL cap, and there's a 'wilderness' option which throws out starport, pop, gov, law, and TL data for worlds with Pop < 7.
Last edited:
More options.
And some of us don't need it to, so that sounds like an option too. I and perhaps others aren't as constrained as the OTU when it comes to SysGen TLs and want the chance for a TL-F+ to show up.
My mom grew up in Tippecanoe county and I've lived in West LaFayette while going to college.
Go, Purdue!!!
My mom grew up in Tippecanoe county and I've lived in West LaFayette while going to college.
Go, Purdue!!!
Yes, I'm a Boilermaker too.
Cheers!
http://eaglestone.pocketempires.com/survey/t5-prog/t5sysgen-cgi.pl
Now you can specify:
- sector key string
- TL Cap, from 6 to 21. Default is 21 (= no cap)
- Wilderness option, which tosses out colonies with Pop<7
- Stellar density, from extra-galactic thru galactic core.
Now I have to get it to map out system data.
Now you can specify:
- sector key string
- TL Cap, from 6 to 21. Default is 21 (= no cap)
- Wilderness option, which tosses out colonies with Pop<7
- Stellar density, from extra-galactic thru galactic core.
Now I have to get it to map out system data.
DangerousThing
SOC-13
The only problem I found was that my test sector "France" has three systems named "Utremo."
I could picture wars being fought over the honor of keeping such a noble name.
I could picture wars being fought over the honor of keeping such a noble name.
I think this points to a flaw in either the hashing algorithm, or the way I use the hash results.
Is Wilderness defined as no starfaring at all? Because if you're only establishing native populations, you need to do more than toss out the low and medium populations. Virgin territory should have an average of one minor race per three subsectors. Call it one per 100 worlds, give or take.
Something else that would be useful: being able to specify how long starfaring has gone on in the area and have it affect the population levels. The fewer centuries, the fewer mainworlds, colonies, and outposts.
I wouldn't know how to begin defining the appropriate algorithms, though.
Hans
Trying not to be too much of a PITA.
Thanks for what is there, though, it is still wicked awesome. Saves me from having to do all the local Sectors by hand. One is enough.
Can't lie, Rob, I am glad someone else had a chance to ask about the Wilderness and Civilized having somethings in between them. I really would like to see greater variance too. But yeah, I know real world and all. Still, I too vote for more variety.
Thanks for what is there, though, it is still wicked awesome. Saves me from having to do all the local Sectors by hand. One is enough.
I would recommending spending some time on selecting a good PRNG and coding it yourself to account for 'floating point formats', etc. so that you can 'take' it with you. I.e. - so for a given seed your outcome will always be the same regardless of platform and future language choices. (Got burned by this given all the different, unanticipated platforms and languages I made game aids on...
)You probably want one that not only has good distribution, but exhibits excellent chaos - i.e. large variation when seed changes by only '1'. (Lot of crypto geared PRNGs tend not to do to well with this aspect.)
BTW: http://www.fourmilab.ch/random/ offers a program for checking out the characteristics of your PRNG.
Already on it... the S-Box algorithm works and is fast, but yesterday I also downloaded the Perl source for ISAAC, which, though developed in '94, is still a useful algo. I've also coded up a very short PRNG from the same author of ISAAC, but haven't tried it out yet. The nice thing about all three of these is that the code is short. The nice thing about ISAAC is that it is popular, and has been ported to over a dozen languages.
Frankly, if SBox works as well as I think it does, I'll use it, because it has decent characteristics, but I want speed most of all.
Ref:
http://en.wikipedia.org/wiki/ISAAC_(cipher)
http://home.comcast.net/~bretm/hash/7.html
http://home.comcast.net/~bretm/hash/10.html
Last edited:
Update
Update. I replaced the underlying S-Box quick hashcode generator with the ISAAC random number generator. I've also added multiple star generation.
If you're interested, give it a poke and see where it breaks. I've already found an error.
Thoughts about Galactic Coordinates. @Joshua: despite its implausibility, it seems so very convenient to use large-ish chunks of space as units of galactic division and measurement.
This time, I'll suggest that the sector is the unit of measurement. What's more, I'll perform howlingly absurd acts of math. Break up the galaxy into 85 concentric bands, each with a depth of 10 sectors. Each band is [68 x Band] sectors wide. Yes, it's howlingly absurd.
Massilia Sector is situated on Band 29/6, Sector offset 1.
Core Sector is on Band 29/5, Sector offset 1.
Band 28 ends two sectors coreward past the Vargr Extents.
Band 30 begins one sector rimward past the Solomani Rim.
A sector clear on the other side of the galaxy would be at Band 29/5, Sector offset 986.
A possible notation would be
So Core would be "29/5.1", the Marches would be "29/4.1969", and "29/4.986" would be a sector on the opposite side of the galaxy. Plugging in 29/4.986 into my procedural generation system could theoretically be the raw data for a sector clear on the other side of the galaxy. In other words, with a serviceable mapping system and a known random number generator, I can see the raw contents* of any sector in the galaxy. I also see a bug in the star generator in hex (0708).
* Raw contents = relatively unfiltered for "actual" population data.
Update. I replaced the underlying S-Box quick hashcode generator with the ISAAC random number generator. I've also added multiple star generation.
If you're interested, give it a poke and see where it breaks. I've already found an error.
Code:
Stellar notation works like this:
Primary -Close Near +Far
Moreover, binary companions look like (G0 VI K0 VI).Thoughts about Galactic Coordinates. @Joshua: despite its implausibility, it seems so very convenient to use large-ish chunks of space as units of galactic division and measurement.
This time, I'll suggest that the sector is the unit of measurement. What's more, I'll perform howlingly absurd acts of math. Break up the galaxy into 85 concentric bands, each with a depth of 10 sectors. Each band is [68 x Band] sectors wide. Yes, it's howlingly absurd.
Massilia Sector is situated on Band 29/6, Sector offset 1.
Core Sector is on Band 29/5, Sector offset 1.
Band 28 ends two sectors coreward past the Vargr Extents.
Band 30 begins one sector rimward past the Solomani Rim.
A sector clear on the other side of the galaxy would be at Band 29/5, Sector offset 986.
A possible notation would be
Code:
Sector ID = [Band].[Sector Offset]So Core would be "29/5.1", the Marches would be "29/4.1969", and "29/4.986" would be a sector on the opposite side of the galaxy. Plugging in 29/4.986 into my procedural generation system could theoretically be the raw data for a sector clear on the other side of the galaxy. In other words, with a serviceable mapping system and a known random number generator, I can see the raw contents* of any sector in the galaxy. I also see a bug in the star generator in hex (0708).
* Raw contents = relatively unfiltered for "actual" population data.
Last edited:
I still think I prefer the idea of dividing sector-deep tracks around the core into a fixed number of sectors (2000), where sectors have a different width based on their distance from the core (width in hexes = track/10, ignore fractions). That keeps rays more or less "straight" for administrative purposes.
Polar math is only a problem if you plot a course of more than 10 sectors in one shot, or when you get inside the core (which may extend out to Track 75?).
Well, that would put Charted Space inside Tracks 321-329, and the Rim out around Track 850.
Sector coordinates would be
Individual hex coordinates would be
Benefits.
The "sector track" system is convenient for locating sector-sized chunks of space, and is just as convenient a starting position for sector generation as for system generation.
Ignoring fractions when calculating sector width is a convenient way of getting 400 parsec depths which allow us to treat local space as more or less 2D semi-cartesian space.
The 2000-sector scheme is easy to remember, and it's easy to tell a sector's "clock position": a value of 1000 is clear on the other side of the galaxy.
Polar math is only a problem if you plot a course of more than 10 sectors in one shot, or when you get inside the core (which may extend out to Track 75?).
Well, that would put Charted Space inside Tracks 321-329, and the Rim out around Track 850.
Sector coordinates would be
Code:
Track.SectorOffset
e.g.
325.1Individual hex coordinates would be
Code:
Track.SectorOffset:Hex
e.g.
325.1:2118
323.1997:1910Benefits.
The "sector track" system is convenient for locating sector-sized chunks of space, and is just as convenient a starting position for sector generation as for system generation.
Ignoring fractions when calculating sector width is a convenient way of getting 400 parsec depths which allow us to treat local space as more or less 2D semi-cartesian space.
The 2000-sector scheme is easy to remember, and it's easy to tell a sector's "clock position": a value of 1000 is clear on the other side of the galaxy.
Last edited:
Well, I haven't really thought much about this, but as a QM, I naturally gravitate towards the idea of a galactic latitude and longitude. That works for finding your actual coordinate position, relative to the galaxy. But the sector / subsector location is relative to other local objects, so non-navigators use that administrative division instead - I may work in the raw lat/long when transiting the ocean, but your GPS automatically plots that on an electronic map, showing your location on a street, relative to other mapped locations, and you never even see the raw coordinates. So in-game, my navigator is theoretically calculating his gallat / gallong posit, that of where he wants to go, working out a great circle course to it, then extracting rhumb line courses every few parsecs, and feeding that into the computer. The rest of the party sees him point to the hex they want to go to and roll to plot the course. If he suceeds, all well and good. But then, the player who's navigator for my PCs is a steelworker, not a quartermaster. He may be smart, but I'm not trying to lay too much real world navigation on him, especially since he's also the purser, and I do make him handle the trade system. If I did that part, it'd bog play too much, and I couldn't answer other players' questions or run anything for them while the Kokasha nav / purser is trying to make deals.
And I really see no reason why the coordinate system needs to refer to sectors / subsectors at all. The real world lat / long makes no mention of the nations that it runs over, and the only connections to the political / social world described are the prime meridian and the international dateline. In Traveller, I'd just use a prime meridian, and not bother with the dateline, since it's just as easy to use it for both. The only hitch is that would mean that anti-spinward would be a day ahead of spinward of the meridian. But then, no-one uses standard imperial time to live their lives, except on Capital. Everywhere else uses the local day, and their hand-comp keeps track of the conversion for them, so when they communicate offworld, they may refer to 1337 local time, 39th day of the 6th month (autumn), etc. But the letter-writing computer taking their dictation turns that into 0317 standard time, day 219. When their friend receives it, their computer then converts that into their local time.
And I really see no reason why the coordinate system needs to refer to sectors / subsectors at all. The real world lat / long makes no mention of the nations that it runs over, and the only connections to the political / social world described are the prime meridian and the international dateline. In Traveller, I'd just use a prime meridian, and not bother with the dateline, since it's just as easy to use it for both. The only hitch is that would mean that anti-spinward would be a day ahead of spinward of the meridian. But then, no-one uses standard imperial time to live their lives, except on Capital. Everywhere else uses the local day, and their hand-comp keeps track of the conversion for them, so when they communicate offworld, they may refer to 1337 local time, 39th day of the 6th month (autumn), etc. But the letter-writing computer taking their dictation turns that into 0317 standard time, day 219. When their friend receives it, their computer then converts that into their local time.
