Ecliptic Plane and System Traffic

[kaladorn]

I just heard a story about a fellow whose boat went down. The crew ended up having to give chart fix positions (not dead reckoning, but a close first cousin of it) as their GPS batteries had died.

You do things the 'old way' because that works without batteries and because if your batteries fail, you smash the GPS or drop it overboard, someone takes out the satellites, etc... you better darn well have enough *practice* to do it the older and harder way and do it right, because your life might depend on it.

SAC and the military aren't the only ones who do this kind of thing. Most civilian navigators that have any wit and plan to sail outside of sight of land will know and practice these skills too.

 

[mike wightman]

GPS, what's that?
Give me a compass and a map anyday.

 

[kaladorn]

Almost right, Siggy-baby. Maps are for pongos. We in the maritime end of things call them 'charts'.

 

[TheEngineer]

Hi !

Back to ecliptic planes...

Anybody has an idea about the variation, which could be expected in other planetary systems in our galaxy ?

I wonder if those system roughly follow the "master" ecliptic of the galaxy or if its just chaotic ?
Guess there should be some tendency towards the galactic ecliptic, because preservance of rotational momentum...but I really dont know.

Regards,

Mert

 

[Ran Targas]

^ Eng, forgive me for one second ...

Y'all, having served as a ship's navigator and squadron navigator in the service, I completely understand the necessity to do things the old fashioned way (i.e. with paper charts and sextants). I learned to shoot stars, run the redux tables, take bearings and ranges, figure tides and currents, and compute set and drift; it was a requirement. But even so, the U.S. Navy is working toward a completely paperless navigation system, relying heavily on GPS, with a CD library and electronic updates. The tools of technology are available to make the job easier and finally are reliable enough to be accepted by the old guard.

Case in point; when I served, anti-collision software was available on most commercial radar systems (mm band). On merchants, this tech was relied on heavily; the joke was that they train a dog to react to the alarm and wake up the crewman at the wheel. Although installed on our radar system, we were forbidden to use it, even as a safety feature, as it was deemed unreliable by the wizos in D.C. GPS was handled similarly when it first hit the fleet; it was a novelty and not considered accurate enough to provide reliable data.

My rant meant to imply that IMTU, the merchies and civies have all but completely automated the navigation of ships, even to the point of positive ground control. This even allows fully automated freighters and the like. Taking people out of the loop makes accountants and insurers happy. The military and scouts IMTU still do things the old fashioned way (for the 3I) and are therefore much more qualified to carry the name navigator.

Now back to system orientation; the plane on which a system develops is based on the spin of the star as it develops in its nursery (i.e. nebula). I'd have to speculate that this is probably very random as the cause of the initial collapse (a nearby supernova, a passing nursery mate, etc.) may come from any random direction.

 

[chrome_gnome]

Eng,

Our ecliptic plane is something like 63 degrees in tilt when compared to the glactic plane if I remember correctly. So we are more perpendicular than parallel.

Check out this nifty photo with a good description:
http://coolcosmos.ipac.caltech.edu/image_galleries/IRAS/allsky.html

 

[Fritz_Brown]

And, if the solar ecliptic is not something akin to everybody else's ecliptic, then your arrive above/depart below (or v.v.) becomes arrive on the high end of one side of the ecliptic/depart on the low end of that side - unless you are coming from the other direction. Then you would have a different set of points on the other "side" of the system. In other words, you really ought to follow the standard approach, as published by whoever, and not hot-dog it. Else, you might run smack into that large non-gaseous giant - rocks in your clouds is even less fun for a space pilot than it is for terran one....

 

[aramis]

Fritz:

the ecliptic planes should be slowly precessing, and don't all line up.

if the tangent puts a slow moving object in the way, it will precipitate out... at the relevant side. So, for some systems, the jump point from a system might normally be near the world, but when the GG is in the way, it's the solar pole, and when the world's on the far side, also the solar pole. Ugly to keep track of except for VERY small campaigns with detailed orbital mechanics plots AND computer assistance.

 

[Fritz_Brown]

Aramis,
That was why I thought there would be a system that would keep you free of those vagaries (mostly). It would wreak havoc on your trade, if some months you had to drive in from the outer system, and others you popped out 100d from the populated world.

And, this is the kind of thing that, though you wouldn't use it for most of the game, players will find a way to use to their advantage, no matter what it's like in YTU.

 

[kaladorn]

What I think would be interesting would be a module for Universe or H&E and updated full system data that would include an origin date. Then, when you went to a system, you'd type in a current date, the computer would do some crunchy goodness, and be able to tell you where in their orbits all the planets are and how far apart. *That* would be pretty neat.

 

[TheEngineer]

Actually I am working an another tiny program calles "NavComp".
Well, its job is to simulate a Traveller navigators job regarding the specification of a destination jump ccordinate and also run some probabilty number crunching to find out the best jump exit location.

How it will work ?
The program will use input data like departure and destination system names and ccordinates, the target systems mainworld orbit and diameter (and perhaps a date) to derive reproducable geometric stats on relativ position and the relativ orientation of the jump vector.
Resulting data is displayed graphically in a "near mainworld" map, showing a part of the orbital path, the mainworld and its jump limit.
Then the navigator=user could choose a jump exit location.
After that the program will display and analyse the situation depending on different jump travel times and spit out a list of propable total travel times.
Guess I will consider the evaluation of a retained velocity vector too.

I finished something similar in a spreadsheet right now, but its surely nicer in a real application with some graphics.

 

[kaladorn]

Well, I'd love to see it when you've got it ready.