Jump Traffic Control

[Andrew Boulton]

Why would Mora want to change an established procedure that probably dates back to the ZS?

 

[Major B]

My call would be that each system decided how they wanted to organize its spacespace (cognate of 'airspace' ;-)) and published instructions in the relevant databases.

My call as well. I remember a small-format book covering the details for most if not all of the airfields in Alaska that I grabbed while preparing for an airfield jump back when I was stationed at Fort Richardson. I didn't think then that anyone from state or federal level had told them what to set as their particulars. It seemed to me that local conditions, prevalent weather, terrain, and volume of traffic all determined how the fields were constructed which determined the patterns air traffic flowed along. Spacespace control would plausibly develop the same way.

I suppose the nav-data could be inspected as part of annual maintenance to ensure they are "up to date", or be part of the 'docking service' at a A or B port.

But if worlds decides to change something (Up is jump in only! No, we just changed it to Down!) it could take quite some time to filter through the system, esp if the ship dodges reputable or non-imperial ports due to the INI wanting to have a chat with them or lack of cash.

If the book I mentioned above is representative, then I don't think that changes would occur all that often. And when they did, the first update would go to the regular navigational aids in system then flow outward as updates. For awhile the in-system controllers would have to divert incoming traffic onto the newly-configured paths until the updates got out to everyone, but that would be routine - nothing more than some good flavor to add to a session as in "Traffic Control has changed their approach routings so it will take us an extra four hours to get dirtside."

To handle changing traffic zones for the main world of the system, you could mandate, at least for busy systems, that ships exiting from jumpspace must do so a certain minimum distance from the world (subject, of course, to the 100-diameter limit for other bodies including stars), THEN receive updated approach information and proceed therefrom.

I think that is spot on and would be common practice even without published traffic rules. You have to precipitate far enough out to receive traffic control guidance and maneuver onto the indicated path.

 

[robject]

I thought just sprung into my mind though. Given even that with the above/below idea you might in a busy system have a lot of traffic there might be a need for more than a simple inbound/outbound rule of space as it were.

YTU might need more coordination if you have a heavy-traffic world, where arrivals jump in every minute, and/or in clumps, etc.

 

[stealth]

I can think of a classic example, say Earth. You want a high port stationed in an a geocentric orbit downrange of the downport at 1G, so that export is as cheap as possible. Then use atmospheric shuttles to offload cargo anywhere on the globe. That means there is only one upward traffic stream from downport to highport.

But ships coming in a 100d, that's the distance to the Moon. I guess they make long corridors from the jump-in zones. I would put them all in one corridor for ease of patrol, and use only one jump-in/ jump-out zone.

 

[stealth]

Also, I never heard the +-3000 km rule before, is it correct?

What I used to do was imagine the target world as a bulls-eye, and you appeared at the set 100d, anywhere from polar to equatorial orbit, but usually somewhere in between. Then you got your flight plan in, and maybe you aren't to far from an escort of some kind.

Also, that kind of made pirate battles more plausable

P.S. We actually tried the old style vectors with a ruler and vector addition, and it was fun, once I taught my players. I insist on science, or something like it, and it does add to the game.

 

[far-trader]

Also, I never heard the +-3000 km rule before, is it correct?

Yep. Marc Miller stated it somewhere (his JTAS article?). Though actually it's +/-3,000km per parsec jumped. Though istr it's just +3000km per parsec jumped. As in you come out further and never closer than the 100d.

 

[Commander Truestar]

Don't know where the thread is, but one person mentioned they used the polar areas, one for incoming traffic, one for outgoing.

I did, on the bottom of the first page of the thread "Can you accelerate during jump?"

Just being helpful as I have not read this entire thread...

Marc(who is in training all this week)

 

[Commander Truestar]

Forgive my ignorance, but how do you determine above and below?

As I said in my post in the other thread, I took the basis of my system(which is admittedly the larger part) from the system FASA designed for Battletech system entry. IN their system "Up" and "Down" were determined from the orbital plane of the planets in the system and by the North and south poles of the system's main world.
An example considering Sol would be that the Zenith(or up) would be above the orbital plane of the planets(except non-standard orbiting worlds) in the system with the direction determined by Terra's north pole. The Nadir(or down) point would be below as determined properly.
Of course, the poles do not address worlds on their side(like Uranus/Sol) which is why I use the primary orbital plane of the worlds in system

Hope that does not confuse a conversation that has moved on

Marc

 

[G. Kashkanun Anderson]

Forgive my ignorance, but how do you determine above and below?

How about this? Whichever vantage point has the observer perceiving the main world's orbit as moving in a counter-clockwise direction* is designated as being 'up' (above the ecliptic). The clockwise view is designated as 'down'.

*As it is in the Sol system: Terra, when viewed in the 'conventional' way (i.e. north being 'up'), is perceived as orbiting in a counter-clockwise direction.

EDIT: Dang, I see that Jeff already covered this possibility. Well, that's what I get for posting before I read all the way through a thread.