AstroSynthesis v2.0

[Daneel Olivaw]

I have AS2, though I haven't used it in a while. For a 2-dimensional map, you can simply define the sector with flat dimensions (e.g., 20x20x1 ly).

Does anyone know how to alter the generation of populations in AS2? I find that even the most habitable planets have populations in the millions at most, when I feel that they should be in the billions.

 

[su_liam]

Is there anything equivalent to this and H&E for the macintosh? I do my 3-d maps on chview2 by Jo Jaquinta. It runs on my computer, it's free and the source is available, making customization possible(with knowledge of java, anyway).

I don't use the j-drive anymore, but I did experiment with 3-d "Traveller" for awhile with some modifications. I assumed that jump distance was proportional to jump number to the 2/3rds power. This solved the density problem, but in any case it's nearly impossible to create mains in 3-d. With J1 set at 1 parsec even pairs of systems are rare. As you increase the J1 distance pairs become more common, then big not particularly elongated blobs of J1-reachable systems appear. The point at which it goes from mostly singlets and pairs to more or less spherical blobs to pretty much all systems reachable with a few singlet outliers is a very narrow range of values of J1 distance. At no point does this produce elongated tendril-like chains of systems.

I have intentionally created mains in 3-d, but it gets increasingly difficult and artificial looking the longer the main is. Something like the Spinward Main would be fairly hokey looking, I'm afraid.

One effect of using unmodified j-drive in a 3-d universe is that borders become more, "frothy." In 2-d it's much easier to have Zhodani space strictly excluded from the area inside the outer, "skin," of the Imperium and vice versa. In 3-d space there will be a lot more opportunities for interpenetrating, "bubbles," "tendrils," and "salients." It almost can't be prevented. This is actually common to any 3-d universe regardless of drive system used.

 

[JustinInOz]

Astro Synth Regina Subsector

I am working on producing a Regina Subsector in AstroSynthesis now.

It is a bit of work. I am plotting larger trade worlds and then placing their clusters around them.

When in habitable systems have not appeared, I am moving the orbits of the worlds and adjusting their temperature with the NASA gebitt spreadsheet. The second one is the one I am using. The one with Luminosity, Albedo and Greenhouse effects.

I will post it to the Astro site when I have finished. I am planning on then doing the Jewell, Chronor, and Aramis sub sectors.

I tend to agree that the 3 dimensions do alter the economics. If your jump number is r then in 2 dimensions the number of systems reachable goes up in proportion to r squared. In 3 dimensions the number of systems goes up in proportion to r cubed. 1 to 1 or 1, 2 to 4 or 8, 3 to 9 or 27, 4 to 16 or 64, 5 to 25 or 125 and 6 to 36 or 216. This is a significant change. I am using spherical subsectors that are roughly 10 parsec radius. A j-6 ship will still blow though them. This is no different from the 2-D OTU.

On Astro many star systems get generated that do not have habitable planets but do have gas giants for skimming. Low jump number ships can get around, they just take a long time. I do not hold that 3-dimentionality blows away the 3rd Imperium.

 

[shadowdragon]

I recently had a thought- many people dislike the whole 2-d map thing and want a 3-d map thing. so----

1. Postulate that 3I cartographers knew their stuff, but jump drive effectivly "evens out the playing field" when it comes to travel. a 3-d map is essential for sublight travel but is it necessary for jump? i say no- hence 2d maps for jump travel. eliminate the grid, round off your distances of real life locations to the closest parsec, and let the COMPUTER worry about the specifics. this is what makes generating a jump plot without a computer such a pain in the butt- the computer knows where every thing is thanks to astrogation programs and databases, but it is displayed as a 2-d interface for humans to grasp the distances easily. a system 5.632 parsecs away will require a j-6 drive to get there so on the map it is 6 parsecs away. anything more than 1 parsec but less than or exactly 2 parsecs away will require a j-2 drive so on the map 2 parsec location. etc....

2. this must be an alternate universe because of stars being located where they are not in reality (jump-1 from SOl is a prime example, forget the name of the system).

so use the hex locations as guidelines as to locating star systems on a 3-d map for direction and distance. each hex side is 60 degrees, use a protractor for actual direction and convert it all to whatever x,y,z format you want. if it is within a j-# sphere then what is the matter if it is above the map or below it. you know the location, use trig or calc or whatever to figure out its exact location and run with it. as long as the distance fits and matches the 2-d map nothing changes gamewise.

 

[shadowdragon]

routing jumps in astro2..

is anyone here familiar with the script writing for astro2? i was trying to figure out a routing system and i have NO CLUE how to do scripts in astro2 and i discovered real quick excel wont do it in anything close to reasonable time. calculating the position of 75,000+ stars seems to strech its abilities for some reason..

 

[aramis]

I use the Proxima system as proof that jump 1 is 1.49999Pc or less, and J2 is 1.5-2.49999Pc, etc... it's only 4.26 LY away...about 1.306Pc....

 

[Icosahedron]

I recently had a thought- many people dislike the whole 2-d map thing and want a 3-d map thing. so----

if it is within a j-# sphere then what is the matter if it is above the map or below it. you know the location, use trig or calc or whatever to figure out its exact location and run with it. as long as the distance fits and matches the 2-d map nothing changes gamewise.

The problem with 2D maps is that they don't show interdependent distances.
Star A is 3pc from Star B, which is 5pc from Star C and 4pc from star A. You're fine so far, because three points can be mapped accurately in 2D, but add in Star D, whose distances must be defined from all three of the other stars, and the map breaks - it's a mathematical impossibility to represent the network accurately in 2D. Multiply that difficulty by the number of stars IYTU, and you have a strong case for ditching 2D.
2D only works if you measure everything from Star A and the distance from Star B to Star D doesn't matter - but somebody will want to go that route sooner or later, so how far is it - the 6pc the real life figures say, or the 3pc shown on your 2D map?

 

[Droptrooper.]

Burning Empires uses a 2D map with a +/- measurement from the galactic plane. Works fine for me.

 

[Icosahedron]

Maybe, but figuring the travel time between a star at +264,736,873 and another, two 2D hexes away at +264,736,642 is not something I want to do on a regular basis.

 

[Drakon]

This solved the density problem, but in any case it's nearly impossible to create mains in 3-d. With J1 set at 1 parsec even pairs of systems are rare.

I used the old stutterwarp distance of 7.7 light years and got a very cool pattern. Earth is kind of isolated, but you got a great "main" from Sol, to Barnard, to Ross 154, to AX Microscopii. From there it splits to 4 different stars, (GJ852, Epsilon Indi, Lacelle 9352, and EZ Aquarii.

One effect of using unmodified j-drive in a 3-d universe is that borders become more, "frothy." In 2-d it's much easier to have Zhodani space strictly excluded from the area inside the outer, "skin," of the Imperium and vice versa. In 3-d space there will be a lot more opportunities for interpenetrating, "bubbles," "tendrils," and "salients." It almost can't be prevented. This is actually common to any 3-d universe regardless of drive system used.

Hmm... that is pretty cool, and makes frountiers more common. Not just borders between empires, but borders between colonized and unexplored space.

 

[Hal]

In response to the person who asked how to do a Traveller style map using the Astrosynthesis map program...

Assuming that I were inclined towards working on such a project, this is how I'd approach it.

Create a universal hex ID system that allows me to uniquely identify any and every star system listed in the Traveller Universe. Instead of using a 4 digit numbering system (which works for a sector with only 32 columns by 40 rows), I'd use a 6 digit system. Why? Lets say we're talking about creating a map for a 4 sector by 4 sector universe. That would be 4 x 32 hexes wide, by 4 x 40 hexes deep. That would require a numbering system that runs from 001 on through 4 x 32 or 128 hexes wide. It would also run 001 on through 4 x 40 hexes deep, or 160. Thus, we'd need a numbering system for hex id that would run into (for computer programmers) a value of 999.

Next step? If you note carefully, the distance from center of hex to center of hex is identical. In other words, there is a precise mathematical value to be had that would permit someone to determine the location of any center of hex relative to another center of hex. If anyone could find that formula, I would be willing to bet it would be Anthony - he tends to be pretty sharp when it comes to math

In any event - once you have that universal hex ID system in place, and you've modified all of the hex id's of every single star system listed in the HEAVEN & EARTH data files - all of which are available on a single Excel spreadsheet, the next step would be to convert the data for the Third Imperium Universe over to the csv data file that can be used to import data for use with Astrosynthesis.

Why? Because once Anthony (or someone else) figures out how to convert any given HEX Id into an X/Y co-ordinate - all you need to do is enter the value of ZERO for all of the Y co-ordinates. The Sample LocalStarData.csv file that came with Astrosynthesis 2.0, shows you precisely how you need to enter the data from the Traveller Universe in a usable format for use with Astrosynthesis.

Now, the hard part would be to manually go in and detail each of the star systems in Astrosynthesis. First, you'd have to add in the star's planetary bodies. Next, you'd have to Right Click on the planet itself to bring up the properties window. There, you will see a tabbed window that allows you to edit things such as:

planet/mood - physical data of the body in question along with allowing you to determine the allegience of the world in question.

Orbital properties - the data that determines how far away from the star, its eccentricity value, etc.

Surface Map - tells where the file is located that has the surface map on your computer for that particular world

Notes - self explanitory

GM Notes - also self explanitory

System Data Fields - THIS is the biggie. Here is where you can add field names for use with Astrosynthesis. Once you add in extra Data fields, a new "tab" will open up with all of the new data fields that you entered in the System Data Fields tab. In the new tab, you can then enter in the data for all those nifty things you want such as TTL (Traveller Tech Level) or perhaps Gov level or even starport type etc.

Sadly, you'd either need to detail every single world by hand (a laborious prospect to say the least) or you'd need to study on how to create scripts for use with Astrosynthesis. There is already a script for creating GURPS SPACE data fields available for free from NBOS, if you want to download it and give it a shot. If nothing else, it will show you how scripts can help automate certain processes.

That is how I'd approach the project. If I had to choose a given world to specify as the point of origin (ie zero, zero, zero co-ordinates), I'd likely use Capital as the origin point and go from there. Each species/empire would calculate the origin point differently and use their own cultural center point as the point of origin for their maps

 

[Peter Schutze]

I'm not sure if you can place all of the systems on a single plane.

play with the sector setup .... make it (or is it subsectors) 5 ly by 300 rather than cube or sphere then hieght wont matter

 

[crazy_cat]

I am working on producing a Regina Subsector in AstroSynthesis now.

It is a bit of work. I am plotting larger trade worlds and then placing their clusters around them.

When in habitable systems have not appeared, I am moving the orbits of the worlds and adjusting their temperature with the NASA gebitt spreadsheet. The second one is the one I am using. The one with Luminosity, Albedo and Greenhouse effects.

I will post it to the Astro site when I have finished. I am planning on then doing the Jewell, Chronor, and Aramis sub sectors.

I tend to agree that the 3 dimensions do alter the economics. If your jump number is r then in 2 dimensions the number of systems reachable goes up in proportion to r squared. In 3 dimensions the number of systems goes up in proportion to r cubed. 1 to 1 or 1, 2 to 4 or 8, 3 to 9 or 27, 4 to 16 or 64, 5 to 25 or 125 and 6 to 36 or 216. This is a significant change. I am using spherical subsectors that are roughly 10 parsec radius. A j-6 ship will still blow though them. This is no different from the 2-D OTU.

On Astro many star systems get generated that do not have habitable planets but do have gas giants for skimming. Low jump number ships can get around, they just take a long time. I do not hold that 3-dimentionality blows away the 3rd Imperium.

Did anything ever come of this? I've just purchased Astrosynthesis and I'm trying to decide whether mapping a part of the OTU Spinward Marches is an achievable goal or whether I'm going to be better off making something up thats just sort of close to canon?

Any advice or pointers you've got would be much appreciated.

 

[Kilgs]

I’ve been messing around with the trial version and I’m not seeing the real problems that people are claiming up here. Granted, you can’t use the specific maps/planets of the OUT because a 3-D sector has a much larger set of systems. But I’ve been manually building J-1 mains and inserting stations or planets to make it work. It’s a lot of work but the end result is really impressive. While you can definitely see that planets are far more accessible due to uninhabited systems, the prospect of making several non-profitable jumps will cut down on that aspect. Or… you can simply remove all the non-populated stars. However, I’ve found them really useful for connecting clusters etc. Not to mention the naturally occurring rifts are excellent.

My plan was to build a sector (changed to 16x16x16 parsecs in size) and design my own planets. There are a couple options:

One= Pick an existing sector and simply add a boatload more planets in addition to the identified ones.

Two= Design an entirely new sector. (I guess I’m thinking your arguments about OTU center around the inability to make a 32x40 parsec sector with the number of planets as identified in the OTU).

It’s a boatload of work but it looks great. Not to mention all the pluses mentioned by others in the shifting loyalty lines etc. I really wish AS had a simple Jump-Calculator. The Eve Online 3d map has a function where you can click on a planet, tell it the power of your jump drive and it shows you a sphere that highlights the planets in range.
--------

For my “test sectors”, I’ve been using the 16x16x16 scale. Split up into eight subsectors. Average good density is around 3-4,000 with about 4-600 populated planets.

Set up proximity routes with a range of one parsec and it shows you good starting points for building your mains. From there, you just start "connecting the dots" as well as moving them around to be within range.
-------------
And I would be very interested in designing a 3I, ATU, using the program.

 

[shadowdragon]

just a thought- if you are trying to recreate the OTU maps, you can easily position the systems manually, with a y-axis of zero for all systems. by determining the center point co-ordinates for each hex in advance, or just an offset to adjust the x and z coords for each hex, you will have a nearly exact match of the OTU or ATU of your choice. since you will need to go into each systems properties to add specific details, setting the x,y,z coords is not going to be additional trouble. you can also do all the details in a crv format excel file and import it into astro. that actually may be easier.......


again its just a thought


have a day

 

[shadowdragon]

just a thought- if you are trying to recreate the OTU maps, you can easily position the systems manually, with a y-axis of zero for all systems. by determining the center point co-ordinates for each hex in advance, or just an offset to adjust the x and z coords for each hex, you will have a nearly exact match of the OTU or ATU of your choice. since you will need to go into each systems properties to add specific details, setting the x,y,z coords is not going to be additional trouble. you can also do all the details in a crv format excel file and import it into astro. that actually may be easier.......


again its just a thought


have a day

after actually finally playing with it- i don't know exactly what i did but i got it to generate .5 ly on the z-axis. when i went back to do it again i could manually set any axis to .5 but it defaulted to 10 if i tried to generate a new sector. grrrrr- i love this program but these little glitches are so damn irritating.....

 

[Bishop Odo]

I am working on producing a Regina Subsector in AstroSynthesis now.

It is a bit of work. I am plotting larger trade worlds and then placing their clusters around them.

When in habitable systems have not appeared, I am moving the orbits of the worlds and adjusting their temperature with the NASA gebitt spreadsheet. The second one is the one I am using. The one with Luminosity, Albedo and Greenhouse effects.

I will post it to the Astro site when I have finished. I am planning on then doing the Jewell, Chronor, and Aramis sub sectors.

I tend to agree that the 3 dimensions do alter the economics. If your jump number is r then in 2 dimensions the number of systems reachable goes up in proportion to r squared. In 3 dimensions the number of systems goes up in proportion to r cubed. 1 to 1 or 1, 2 to 4 or 8, 3 to 9 or 27, 4 to 16 or 64, 5 to 25 or 125 and 6 to 36 or 216. This is a significant change. I am using spherical subsectors that are roughly 10 parsec radius. A j-6 ship will still blow though them. This is no different from the 2-D OTU.

On Astro many star systems get generated that do not have habitable planets but do have gas giants for skimming. Low jump number ships can get around, they just take a long time. I do not hold that 3-dimentionality blows away the 3rd Imperium.

Did you ever finish that map?

 

[JustinInOz]

I put a lot of work into it. I do not think I finished it.

If you like, I would be happy to post the file of the subsector as it is.

My personal e-mail address is justin.akkerman@gmail.com. Send me a mail there and I will reply to you.