3d Jump Maps.

Being a mac user and not wishing to boot camp my mac astrosynthesis doesn't work for me.

Why would you choose the brain?

Distances should be pretty easy if you have x, y and z coordinates and a calculator or excel.
 
hiro said:
Distances should be pretty easy if you have x, y and z coordinates and a calculator or excel.

Of course. But why use a s/w program if it lacks even that basic functionality?

There might be something on here you can use. http://www.projectrho.com/public_html/starmaps/software.php
 
hiro said:
Being a mac user and not wishing to boot camp my mac astrosynthesis doesn't work for me.

Why would you choose the brain?

Distances should be pretty easy if you have x, y and z coordinates and a calculator or excel.

TheBrain is all about relational mapping, you can assign classes to both points and edges. So for cognitive mapping, which to be realistic is all that Traveller Jump maps are cognitive maps, one just has to fill in the relative length between two points. The drawback is the display is a 2d display, but that doesn't really get in the way of local maps... The other is that all your inputs are manual, so random goodness has to be generated outside of the environment.
 
Already did years ago. 2300 Near Star Map, spreadsheet , calculator, pencils, ruler and paper. Old fashion but it worked.

Alternity's Cosmos 2 is an interesting source for 3D star mapping. Not hard at all to use with Traveller.

http://www.alternityrpg.net/resources.php?cat=rules&rid=1375&detail=1
 
If you assume that the 2d map is just a 1 parsec wide 'slice' through the galactic plane, all it would need would be a + or - number to indicate how many parsecs a planet is above or below that plane; x would be the horizontal distance between planets on a map, y would be the vertical difference between them, and z would then be the actual 3d distance. Not too difficult to work out.
 
Just so you don't confuse people with the terms, by 'actual 3D distance', you mean the spacial depth (third dimension) rather than the actual distance between two points, correct? And you are also referring to a square grid rather than a hex field?
 
Reynard said:
Just so you don't confuse people with the terms, by 'actual 3D distance', you mean the spacial depth (third dimension) rather than the actual distance between two points, correct?

No, I actually meant that the +/- numbers would give the spatial depth along the vertical x axis, with z being the actual distance between 2 points.
 
Rick said:
If you assume that the 2d map is just a 1 parsec wide 'slice' through the galactic plane, all it would need would be a + or - number to indicate how many parsecs a planet is above or below that plane; x would be the horizontal distance between planets on a map, y would be the vertical difference between them, and z would then be the actual 3d distance. Not too difficult to work out.

This
distance-three-coordinates.png
is the formula for figuring out the distances...
 
sideranautae said:
Rick said:
If you assume that the 2d map is just a 1 parsec wide 'slice' through the galactic plane, all it would need would be a + or - number to indicate how many parsecs a planet is above or below that plane; x would be the horizontal distance between planets on a map, y would be the vertical difference between them, and z would then be the actual 3d distance. Not too difficult to work out.

This
distance-three-coordinates.png
is the formula for figuring out the distances...
Yes, and no. Your formula is perfectly correct for figuring out the distance between 2 points when all you have are the 3d co-ordinates (values of the x,y and z axes). However, I was taking a much more simplistic approach and assuming we were working out a 3d system for the standard Traveller sector map. Both approaches are perfectly valid for their own uses, but I couldn't recommend using your formula on the Traveller sector maps, or vice versa. :D
 
Rick said:
sideranautae said:
Rick said:
If you assume that the 2d map is just a 1 parsec wide 'slice' through the galactic plane, all it would need would be a + or - number to indicate how many parsecs a planet is above or below that plane; x would be the horizontal distance between planets on a map, y would be the vertical difference between them, and z would then be the actual 3d distance. Not too difficult to work out.

This
distance-three-coordinates.png
is the formula for figuring out the distances...
Yes, and no. Your formula is perfectly correct for figuring out the distance between 2 points when all you have are the 3d co-ordinates (values of the x,y and z axes). However, I was taking a much more simplistic approach and assuming we were working out a 3d system for the standard Traveller sector map. Both approaches are perfectly valid for their own uses, but I couldn't recommend using your formula on the Traveller sector maps, or vice versa. :D

Even if you are just stacking Trav sub sectors in one parsec layers you have to use the formula if you are moving more than 2 pc and crossing "cells" up/down or you won't get the right answer. It's not that you can't do it, it's just difficult unless you have a REALLY good 3D matrix to hand measure it.

But like I said earlier I wouldn't use such a system unless it was put into software that correctly displays it, easily creates it, and is cross platform for my players to have to hand. Nothing like that currently exists that is easily customizable for house rules. (no I'm not counting rewriting source code as "easily customizable". I can also remill my engine block but that doesn't count either. 8)
 
Honestly, sideranautae - it is very easy if you have only got 2 planets - just use simple trig; A is at -3 and B is 3pc away on the map and at +2. So, x axis reads 6 pc (including the '0' layer), y axis reads 3 - distance between them is 6.7, or 7 pc.
 
A stack of hex maps do not line up. If you convert the hexes to square grid every other column is shifted a half a square. There are maps out there representing it but three dimensionally it doesn't fit well at all. Stick to simple XYZ. Soooo much easier.
 
Back
Top