Dynamic Sector Map Idea

[DangerousThing]

I'm going to be running a T5 game shortly, and I would like a dynamic mapping program that would calculate orbital positions so that I could easily show the positions of the planets in each system (in single system view) and also calculate the jump shadows so that I could calculate how far a ship has to go in realspace before it can jump to system B.

Not only will this make things seem more real, but it may effect the character's next destination.

If nobody has written this, it's time to brush off my Java. Or something else.

I'm just going to assume basic elliptical orbits without gravitational interaction. I don't have the time to solve the n-body problem.

All I need is something that works given a starting position and the current date.

 

[Marchand]

Astrosynthesis 3.0 from NBOS software does this.

 

[DangerousThing]

But can they be coaxed into doing a Traveller style map?

At least I have the program. I just have to install it on my laptop.

 

[77topaz]

Linking hexes on a sector map to AstroSynthesis or other system models would be possible (it would require quite some coding, though, I expect, if done on a webpage, but it wouldn't be impossible as such).

A full sector map on AstroSynthesis might look a bit weird since Traveller sector maps are based in 2D (the systems are also further apart than the systems it randomly places).

 

[Kilgs]

There are some discussions further back in time here that cover Astro with Traveller mapping (2d). But for OP's need, can't you just create the systems without any real connection to their place in the sector? Since it's for purposes of determining orbital positions within a solar system, as long as all of the systems are on the same date, you're fine.

Also, you can use the AS sector map as a "conceptual" map for your players. Ignore actual real distances and just make clusters of 1 parsec/2psc etc based on the 2D maps. Explain it away as a computer's rendering of routes and not actual stellar positions.

We do it with molecules all the time!

Also, there is plug-in on NBOS to convert the system stats to Traveller UPP.

 

[robject]

But for OP's need, can't you just create the systems without any real connection to their place in the sector? Since it's for purposes of determining orbital positions within a solar system, as long as all of the systems are on the same date, you're fine.

^this^

...a dynamic mapping program that would calculate orbital positions so that I could easily show the positions of the planets in each system (in single system view) and also calculate the jump shadows...

First, the likelihood of a planet shadowing a jumpline is essentially nil -- it's better left as a probability rather than a program.

And let's talk about resolution. If you can handle lower resolution, then let's also put a tabletop solution on the table, so to speak.

Consider a 11" x 11" piece of paper with five concentric circles drawn on it, corresponding to the first five orbit numbers. Divide each circle up into six segments. Roll 1D for the segment of each planet. Then have a table showing the added distance due to relative position.

Handwave away orbits 6 and on: the triangle formed by their distance from the other worlds is most of the distance; opposition and conjunction don't add enough to matter, given the acceleration-deceleration formula. Maybe.

 

[Fritz_Brown]

first, the likelihood of a planet shadowing a jumpline is essentially nil -- it's better left as a [referee fiat] rather than a program.

fify. (imho)

EDIT: OK, why won't it let me do "FIFY" and "IMHO", instead of "fify" and "imho"?

 

[robject]

fify. (imho)

EDIT: OK, why won't it let me do "FIFY" and "IMHO", instead of "fify" and "imho"?

Referee fiat works for me, too.

Otherwise, I too like to at least get an idea as to where the planets are situated around the primary.

 

[HG_B]

First, the likelihood of a planet shadowing a jumpline is essentially nil -- it's better left as a probability rather than a program.

There's probably about a 5% chance that the star of the system your in or, the star of the destination planet creates a problematic jump shadow.

Maybe a little higher if either of planets is a "hot" world.

 

[samuelvss]

What about the Interactive Atlas of the Imperium,

http://www.utzig.com/traveller/iai.shtml

if you have internet access during play?

If you go to the System, System Data, System Detail, this gives you the position of bodies in the system on a date that you fill in. It has an in-system travel calculator, which gives you the relative positions on a date that you fill in; if you leave 1G in the acceleration, and 0 in the "Start Slot" and "Dest Slot," then it will just plot the worlds' positions on that date.

Do this with the starting system, and then the destination system, make the asumption that "up" is coreward on the system map, and you've got a good start. To prep for play, these maps can be pre-printed, based on likely jump scenarios.

 

[robject]

There's probably about a 5% chance that the star of the system your in or, the star of the destination planet creates a problematic jump shadow.

Maybe a little higher if either of planets is a "hot" world.

Can you explain further, please?

 

[HG_B]

Can you explain further, please?

Kinda lengthy without a visual aid & this board won't allow me to upload an inline jpeg. Do you understand how a star creates a jump shadow?

 

[Enoki]

I think you are looking for something like this:

http://www.utzig.com/traveller/iai.shtml

 

[HG_B]

I think you are looking for something like this:

http://www.utzig.com/traveller/iai.shtml

No. Wrong kind of diagram.

 

[whartung]

How are you basing your jump shadow? I'm not familiar with the T5 Jump Shadow rules. Are we talking simple "within 100D (or whatever)" rules, such as when a planet is too close to its star?

Or are we talking about some other line of sight thing where the destination is on the wrong side of the star this time of year, so the star is "in the way"?

 

[DangerousThing]

How are you basing your jump shadow? I'm not familiar with the T5 Jump Shadow rules. Are we talking simple "within 100D (or whatever)" rules, such as when a planet is too close to its star?

Or are we talking about some other line of sight thing where the destination is on the wrong side of the star this time of year, so the star is "in the way"?

The jump line cannot pass through the jump shadow (100D) of any significant mass. I figure that for part of the year the suns will block the jump line.

And I can't use most of the standard web pages because I am running my game in a non-OTU setting.

 

[Greylond]

The jump line cannot pass through the jump shadow (100D) of any significant mass. I figure that for part of the year the suns will block the jump line.

And that's why a smart crew travels above or below the Orbital Plane to get out of the Jump Shadows. If you travel in any direction other than up or down(relative to the plane of orbit) then you can have a potential jump line blocked. Travelling 100D up or down should get you in a good position.

 

[HG_B]

And that's why a smart crew travels above or below the Orbital Plane to get out of the Jump Shadows. If you travel in any direction other than up or down(relative to the plane of orbit) then you can have a potential jump line blocked. Travelling 100D up or down should get you in a good position.

If the shadow is in the destination system, won't help. And, travelling up/down doesn't matter. It is the added time doing so that matters.

The shadow is 3D not 2D.

 

[whartung]

And that's why a smart crew travels above or below the Orbital Plane to get out of the Jump Shadows.

Umm..but you're still blocked by the shadow. If the planet is on the far side of the star (in reference to your current position, you effectively have this 100D big ball in your way. Jumping to the "top" will certainly shorten your trip compared to jumping to the outer edge on the ecliptic, but you still need to fly "down" to the planet, it's still not a straight shot by any means.

I guess the base assumption is that all of the stars share the ecliptic, parallel to (I guess) the galactic plane, no reason to add even more complexity of having say, system X ecliptic perpendicular to system Y.

This way you can simply grab a bearing off of the sub sector map and project it in to the system based on the planet locations. So, for most cases, you can probably just stick to the 2D view and ignore the "top" and "bottom" thing. Going to the "top" isn't really much different than going to the closest edge for most purposes.

If you're "due east" with the star in the way, and the planet is "due west" behind the star, heading to the northern 100D limit, southern D limit, top or bottom will all be the same distance to the planet. As the planet moves north or south, then that point will be the best destination. Truth is, I don't think the "top" or "bottom" well ever be the best move.

So, why complicate it even more by adding that detail.

 

[whartung]

If the shadow is in the destination system, won't help. And, travelling up/down doesn't matter. It is the added time doing so that matters.

The shadow is 3D not 2D.

Yea, if the shadow is in the origin system, the ship's just going to have to climb out of the hole no matter what, but, again, even with a 3D ball in the middle, the orbit is effectively 2D, so "top" and "bottom" aren't really relevant vs "north" and "south".