CT Only: What One Thing Would You Change About Classic Traveller?

[infojunky]

Doesn’t answer my question, what is standard deck height.

10 feet... 3 meters take your choice.

Though honestly that is all for the convenance of the occupants... Voids, Cargo rooms, Machinery Spaces all are based of the needs of what goes in to them. The last Diesel ship I was aboard the main engine room was two and half decks tall with about 5 feet of access on the sides and the overhead for example.

 

[TamsinP]

That’s my assumption re hold which is why stacking is important. I’m assuming attachment floor and ceiling. Maybe even side bolts we don’t use in RL stacking, cause multi-g vee suggests even greater stability required.

If you look at shipping containers, on each corner there is a plate with three holes (top/bottom, end, side) for securing to other containers or to the ship. Containers are secured vertically using twist-locks; the holes on the ends are used to secure them laterally (and to some extent vertically using lashing rods. The holes on the sides can't really be used for anything, so I suspect that it is down to speed of manufacturing - the worker welding the corner pieces in place doesn't need to spend time faffing around getting them correctly oriented.

I imagine there would be something similar for high-tech containers in Traveller, maybe in the form of magnetic clamps facing all three directions from each corner.

 

[whartung]

I take it that the jump “best route” is not necessarily the straightest possible line to the destination, as it would be outside of jump?

If circumstances permit, it is the "straightest possible line", to a point.

Here's the game. Take the two planets and draw 100D rings around them.

Draw the orbital vector of your source planet.

Next, generate the normalized vector of the destination planet. The normalized is a combination of the delta V of the two systems along with the orbital vector of the planet. This is the vector of the destination planet relative to your source planet, because your source system is your "zero".

The planet positions don't matter, just the vectors.

Now, you take your ship, and create a vector as you head to 100D.

Then you jump.

You can now place your ship ANYWHERE you like outside of the 100D of the destination planet. The only real margin is the 10% jump window, so allow for that when you arrive. The detail is, of course, that you inherit the vector you created in the source system, and the destination planet maintains the vector you determined before.

Now your task is to accelerate to match your vector with the vector of the destination planet.

The game is, knowing this, to choose your original vector properly to minimize how that acceleration time in the destination system, with the goal of making the overall trip time as short as possible.

For example, if the two planets both have a net vector of "south", perhaps it's better for you to accelerate north. This gets you out of the 100D faster (since the planet it traveling away from you), and allows you to arrive faster, because you target your destination "in front of" the planet, so that it's running toward you.

Similarly, your origin system is going "North", and the destination is going "East", you may vector out "West", again to arrive in front of the destinations orbit, you just won't be getting out of the origins 100D as fast as if you moved directly away from it.

Then there's leaving a large world, and arriving at a small world. If you accelerate the entirety of the original 100D, you can't just arrive at the destinations 100D, as you will not be able to decelerate in time. So, either stop accelerating in the origin system early, or arrive farther out of the destination system.

The fundamental point being that there is an optimal path between worlds, the navigators will figure this out, and most ships will use that path (thus creating ad hoc "jump lanes"). And since they're based on the relative orbital positions (and thus vectors), these will drift over time.

Jump Shadows and Jump Masks wreak havoc on these perfect plans, so that may need to be considered as well.

 

[Kakistocrat]

If circumstances permit, it is the “straightest possible line”, to a point. [… The game is] to choose your original vector properly to minimize how that acceleration time in the destination system, with the goal of making the overall trip time as short as possible. […] Similarly, [if] your origin system is going “North”, and the destination is going “East”, you may vector out “West”, again to arrive in front of the destination’s orbit, you just won’t be getting out of the origins 100D as fast as if you moved directly away from it.

So If I’ve understood you correctly, taking 100D from the source system as the zero point — the center of the “compass” — even if the destination system is, say, “southeast” of the source system in non-jump space, one would still head for 100D on a “west-bound” vector in the source system to make a southeast-bound jump, so that coming out of jump in the destination system, the ship is still oriented (and accelerating) to the “west” to arrive in front of the destination planet’s orbit? That is, the heading of the ship just before jump is completely independent of the non-jump direction of the destination system, and that heading is chosen only to establish the direction of the vector coming out of jump in the destination system?

You can now place your ship ANYWHERE you like outside of the 100D of the destination planet. The only real margin is the 10% jump window, so allow for that when you arrive.

As long as it’s outside of 100D of the destination planet, does “ANYWHERE you like” include at least 100D away from a different world in the same destination system? If the destination system has multiple stars, does it also include at least 100D away from a different world orbiting any of that system’s stars?

 

[whartung]

That is, the heading of the ship just before jump is completely independent of the non-jump direction of the destination system, and that heading is chosen only to establish the direction of the vector coming out of jump in the destination system?

Essentially, yes.

As long as it’s outside of 100D of the destination planet, does “ANYWHERE you like” include at least 100D away from a different world in the same destination system? If the destination system has multiple stars, does it also include at least 100D away from a different world orbiting any of that system’s stars?

Yes. This is in regards to the Jump Shadow/Jump Masking comment.

For example, Regina is in orbit around a gas giant, and the gas giants 100D overwhelms the 100D of Regina itself. So, rather than seeing a stream of traffic in all sorts of directions around Regina, they'll all be heading away from the gas giant, racing to its 100D before they jump. So, using that whole east/west thing. If Regina is on the "eastern" side of the gas giant, and the target system is also heading east, the ships will incur an eastern vector, and will likely decide they have to arrive "behind" the target system, leveraging that eastern vector, in order to chase it down.

Mind, they could also arrive in front of the target system, and then decelerate, "falling" into it as the planet catches up. But the key point is that the influence of Regina being under the Gas Giants 100D umbrella impacts the route choices the ships may choose to use.

Now HOW MUCH impact are we talking about for all this? I don't know! I can never get the math figured out to make the calculations. Seems to involve bunch of stuff I can't get right.

 

[Grav_Moped]

The math also depends on where the origin and destination worlds are in their respective orbits (especially for planets inside another gravity well). And that isn't tracked.

 

[mike wightman]

So the one thing is to change the simple "jump from here to here, it takes a week" to requiring detailed information about the departure systems and the arrival system, relative motion of the bodies in question, details about orbital positions at the time of jump, orbital positions of everything that could get in the way, stellar data, and this is desired for every single jump?

No thanks. I'll stick with you go to 100D, jump, arrive at 100D and nothing gets in the way.

 

[Spinward Flow]

No thanks. I'll stick with you go to 100D, jump, arrive at 100D and nothing gets in the way.

Oh Noes!
Reality Is HARD!

I'll just oversimplify everything and pretend that the complications DON'T EXIST ... thank you very much!



Whenever stuff starts getting "too complex" (and orbital mechanics is one of those fields of study where "too complex" is the Default Mode!) there is always going to be an urge to Keep It Simple Stupid (KISS), which is entirely understandable (as a motivation).

However, even in 1977(!), we were given a mildly famous cinematic example of why such simplistic thinking isn't the wisest possible course.

The followup to which is ... "Just because I make it LOOK EASY doesn't mean it IS EASY."
Yes, we let "the computers" do most of the work for us (lazy humans who aren't that good at math), but that doesn't mean we should just "take it for granted" that the most simplistic Point A to Point B option will ALWAYS be available no matter what.

As soon as you start thinking of gravity wells as "obstacles and turbulence" that you'll want to be avoiding (and/or making use of!) during flights (rather than as inconveniences that are all too easy to ignore), that makes maneuver drives much more important in Traveller campaigns ... adding texture, "space terrain" and an added dose of realism into campaign settings which would otherwise be ... lacking ... due to maximalist simplification and abstraction.

Remember, familiarity breeds contempt ... and if your idea of space travel is "100D, jump, 100D" and that's it ... well, you've just set yourself up to be BORED by the sheer mundane simplicity of such a familiar and unchanging task with no variations or complications possible whatsoever.



My point here is that when you oversimplify things to the point of boredom at the mundane routine of it all, you might have taken things Too Far™ ... and therefore denied yourself some opportunities for narrative/plot complications that will break up the monotony of the routine.

For example ... in the Sol-Terra star system, Sol has a jump shadow of approximately 0.9 AU and Terra is in Orbit 3 at 1 AU. This means that "depending on what time of year it is and where you're trying to jump to/from" there's a chance that the local star's jump shadow could be between Terra and the destination you're trying to reach via jump. You would need to choose a jump point in space that MISSES (departing) or tangentially INTERCEPTS (arriving) Sol's massive jump shadow. This MIGHT then mean that you need to maneuver further away than 100D from Terra in order to reach or arrive from a jump point when traveling from/to the Terra star system.

You can "still make the distance" using a 1G maneuver drive, but it could take a lot longer than just flying out to 100D and jumping from there (through Sol's massive jump shadow?). And it's at that point, when transits out to jump points might require more than "100D" worth of distance traveled, that having more powerful maneuver drives than the absolute bare minimum can start to make life as a Traveller ... interesting ... again.

 

[mike wightman]

I think you maybe misunderstand my point. Either model it correctly, with full relative motion of every object in both systems and galactic movement taken into account, or handwave it all away as something that happens in the background and get on with the game.

The interesting bit, the character interaction and the problem solving. Not the minutiae of solving frames of reference and relative motion orbital mechanics

The vast majority of Traveller goups want to play a game of sci fi adventure, not solve general relativity calculations to determine ship movement.

 

[coliver988]

I think you maybe misunderstand my point. Either model it correctly, with full relative motion of every object in both systems and galactic movement taken into account, or handwave it all away as something that happens in the background and get on with the game.

The interesting bit, the character interaction and the problem solving. Not the minutiae of solving frames of reference and relative motion orbital mechanics

The vast majority of Traveller goups want to play a game of sci fi adventure, not solve general relativity calculations to determine ship movement.

Pretty much. the game I am running now none of the players want to deal with that level of mechanics. While I like at least some of those mechanics, they want to play the game, not spend an hour calculating relative velocities. that's what the nav roll is for. So there is a LOT of handwaving (even the expenses of starships, which I do under the hood but currently they don't worry about it as (a) they are the stars of the holo-series On the Hunt bounty hunter series, and (b) Instellarms, LIC is a major sponsor so as long as their guns get screen time [and the producer makes sure they do] they get enough to cover those costs).

While I personally would like to get to that level of crunch, most people I play with want to play an RPG and not simulate reality. Or at least the Traveller version of reality. So my solo play has a lot of that in there, but my actual game play very little.

 

[Spinward Flow]

I think you maybe misunderstand my point. Either model it correctly, with full relative motion of every object in both systems and galactic movement taken into account, or handwave it all away as something that happens in the background and get on with the game.

So ... ALL or NOTHING ... is what you're saying.
There is no ... continuum of options ... in between those two choices.

Let's pick apart everything you just listed and I'll give you my perspective on how many of those items are relevant to the way that I would Referee a Traveller campaign so that you can judge the merits of my own preferences for yourself. One of those lay your cards on the table kinds of deals.

1. Relative motion of every object in the system of origin
2. Relative motion of every object in the system of destination
3. Galactic motion accounting
4. Ignore 1-3

I don't need to know the relative motion of "every object in either system" ... I just need to know the relative POSITIONS of gravity wells that could obstruct a path from origin to destination. I only need to thread the needle, not whittle the entire block of steel down into the shape of a needle that I'll be using. Kind of like how when you're given a map, you don't need to "go everywhere" on that map, you just need to figure out the "best path" through the obstacles and hazards of that map to go "from A to B" using it. If you have to go a little out of your way to get round an obstacle ... that's just how navigation works.

Galactic motion accounting is the MASSIVE handwave and is for all intents and purposes "the responsibility of the engineering hardware and software" rather than being something that requires manual control (and manual calculations!) to account for. It's basically built into "how jump drives WORK" rather than an extra step.

Ignoring everything so it's just "100D, jump, 100D" is the LAZY way of doing things.
Quicker.
Easier.
More seductive.
The BORING way are they ...



From a "fast and loose" Referee perspective that is quick to abstract and doesn't require explicit mapping, the simplest solution is to assume that 100D from berthing point is the SMALLEST distance to a jump point, rather than thinking that 100D is the ONLY distance to a jump point people ever need bother with.

As soon as you stipulate that "there are going to be times when the closest jump point to your desired destination are going to be >100D away" you can start doing quick and dirty Referee rulings (with dice, if you'd like, fiat if you don't) that determine how far away you need to transit to reach the desired jump point.
150+ diameters due to locations of jump shadows before you can get a "clear shot" that aligns past all of the obstructions?
0.4+ AU to swing wide of a star's jump shadow before you can get a "clear shot" at your destination?

As soon as you allow the "distance to jump point" to VARY and be something besides "100D, every time!" ... maneuver drive travel suddenly becomes more important (and possibly a lot more interesting) because ships need to transit a variety of distances in a variety of directions, rather than just all "riding the rails" each and every single time.

You don't need to calculate the orbital mechanics or draw the map (in 3D!) for the Players. As a Referee, you simply need to say that "at this time of year for your point of origin, the jump point for your destination is going to be farther away than 100D" and then decide (dice rolls optional) how far away the jump point is going to be in order to avoid any jump shadows between the star system of origin and the star system of destination. All the other stuff about "where the planets are in their orbits" can be handwaved away. All you need is a DISTANCE to jump point ... and from that you can use the D=AT²/4 formula from LBB2.81, p10 to figure out how much time it will take for a craft to transit that distance, after which it can jump to the destination star system.



In point of fact, this is EXACTLY what I proposed ought to happen in the Boughene Station Blues OOC #973 run by @Grav_Moped here on the CotI forums. Last I checked, the Silver Streak is going to need to "swing wide" of the central star's jump shadow (which extends well past the orbit of Boughene Station itself) so we would need to fly prograde to a jump point from Boughene to Efate but would prefer to fly retrograde to a jump point from Boughene to Feri.

Since my PC (our navigator) has convinced our captain that it's in our best interests to depart Boughene Station on a retrograde flight path to FEINT towards jumping to Feri ... before doubling back to maneuver into a prograde flight path that will put us on course for an Efate jump point (which could also take us to Menorb, Yres or Pixie if we were so inclined) ... even if our ship gets picked up on sensor net tracking and our flight path reported to our adversaries interested in knowing where we're going, there won't be enough exclusive information to determine "we went HERE, not THERE" for them to dig out of our trajectory tracking.

And that's just ONE example of how you can make maneuvering out to a jump point "more interesting" than just saying ... time passes ... ... and you jump. A week later you're at your destination and ... 100D later ... you're in a starport berth without incident or encounter.

Your mileage may vary, of course.

 

[The Oz]

I cheat.....
When I (as referee) need the complexity, I put in details about jump masking, arrival/departure lanes, etc. But normally I run things the "get to 100D, jump, arrive at 100D, land" way.
The game may be called "TRAVELLER" but I'm usually not all that interested in the trip; it's the destination that matters.

 

[Grav_Moped]

I mean, you absolutely could have a consistent system to establish and track the position and vector of every single body present in the Trav map.

(Orbital periods are known or could be calculated -- use the input seed value to set the world/system calendar offset from an arbitrary year zero* that everything is based on, then spin the planets forward based on the selected in-game date.)

But does it add much to the game?

*Not Year Zero IE, of course.

 

[Grav_Moped]

I mean, you absolutely could have a consistent system to establish and track the position and vector of every single body present in the Trav map.

(Orbital periods are known or could be calculated -- use the input seed value to set the world/system calendar offset from an arbitrary year zero* that everything is based on, then spin the planets forward based on the selected in-game date.)

But does it add much to the game?

*Not Year Zero IE, of course.

To clarify: each system has a (mostly) unique Year Zero set by a function of its seed value. (This will be many hundreds of thousands of years in the past, of course.) At that point in time, every body in the system is set to be directly Coreward of the body it orbits (all at 0.00 degrees in their orbit).

Then run the clock forward to a selected game date to determine their "present" positions.

Add a random vector to the system as a whole as well, if you'd like.

Hard to do at a tabletop with dice, charts, and a calculator, but not a particularly difficult coding task.

But, again, you could just roll a few dice and write it down if it matters for a particular system.

 

[Condottiere]

Might be a judgement call, as to whether you stay out of the shadows, or whether you've found a loophole you can slip through.

 

[Spinward Flow]

But does it add much to the game?

Possibly ... but under most circumstances, that granularity of CRUNCH in dataset (and bookkeeping!) is going to be superfluous rather than necessary.

The real question here is a matter of Decision Process by the PC(s), rather than a matter of data processing by the computers.
To put it politely, all the PCs "care about" is choosing from the menu of options and then letting their choices play themselves out automatically. That's why so much of the space travel experience can be abstracted (see: LBB5.80 starship combat). If you can abstract things down to what amount to "command decisions" by PCs, you can then pretty much handwave away most of the nitty gritty of "making it all happen" in a timely fashion.

For game play purposes, what matters are the CHOICES that the PCs make.
HOW those choices get executed will often times be abstracted ... so as to be able to skip over to the next choice the PCs have to make.
And so on and so forth.

It's the Decision Chain through the choices that Players remember, regardless of the type of game being played.
Eye candy gets you noticed ... but it's GOOD GAME PLAY that keeps you coming back for more.

 

[Kakistocrat]

That is, the heading of the ship just before jump is completely independent of the non-jump direction of the destination system, and that heading is chosen only to establish the direction of the vector coming out of jump in the destination system?

Essentially, yes.

As long as it’s outside of 100D of the destination planet, does “ANYWHERE you like” include at least 100D away from a different world in the same destination system? If the destination system has multiple stars, does it also include at least 100D away from a different world orbiting any of that system’s stars?

Yes. This is in regards to the Jump Shadow/Jump Masking comment.

It would seem to me, then, that the “optimal path between worlds” is only determined by the circumstances in the source system — viz the components of the vector just before the jump, taking into account where necessary a jump shadow in the source system — since there seems to be near-complete carte blanche of where the ship can emerge from jump in the destination system. If this is the case, then the ad hoc “jump lanes” might be “multi-level” in the “Z dimension”, e.g. ships with different maximum maneuver drive potentials might not want to be limited to that of the slowest ship in the “main” jump lane if their immediate target in the destination system is not its starport.

For example, Regina is in orbit around a gas giant, and the gas giants 100D overwhelms the 100D of Regina itself. So, rather than seeing a stream of traffic in all sorts of directions around Regina, they’ll all be heading away from the gas giant, racing to its 100D before they jump

Yes, that makes sense. I’d calculated the location of Luna within Terra’s 100D as varying from 27.9D (at periapsis) to 31.9D (at apoapsis), and Luna’s 100D is entirely within Terra’s 100D.

Now HOW MUCH impact are we talking about for all this? I don’t know! I can never get the math figured out to make the calculations. Seems to involve bunch of stuff I can’t get right.

Do you mean the math of the celestial mechanics, the math of the orbital mechanics, or both?

 

[Spinward Flow]

It would seem to me, then, that the “optimal path between worlds” is only determined by the circumstances in the source system — viz the components of the vector just before the jump, taking into account where necessary a jump shadow in the source system — since there seems to be near-complete carte blanche of where the ship can emerge from jump in the destination system.

While this is predominantly true it is not exclusively true. The positions of gravity wells within the target star system are still relevant (so don't ignore them completely), but they're certainly lower down on the rung of priorities relative to the gravity wells within the origin star system.

Take Terra in the Sol system, for example.

Let's say you move 100D out from Terra (@ 1.0 AU from Sol) and jump (like an idiot) directly towards Sol and the star's jump shadow (because you were stupid like that). What happens?

Well, you successfully enter jump and a week later you break out still in the Sol system at 0.9 AU from Sol because you "smacked into the jump shadow" and couldn't "go" any further than that.

Or let's take another example, of trying to jump into the Terra system with Terra as your destination.

Let's say you line up your departure from the jump point of origin in another star system and jump successfully, but then (like an idiot) you forgot to check the orbital ephemera to see if Jupiter's jump shadow would be occulting (ie. blocking) Terra on the far side of Jupiter. So when you break out of jump, you're in orbit around Jupiter (not intended) rather than in orbit around Terra (intended but unsuccessful navigation).

So the motions and positions of gravity wells at the location of origin and destination is essentially a "navigation hazard" (so to speak) that complex computer databases and programs overseen by trained navigators are supposed to reduce down to being something of a "non-issue" for interstellar travel. However, depending on "relative positions at this time of year" in the star systems on both ends of a jump, the amount of maneuvering needed to/from jump points can be as little as 100D from a destination starport ... but could just as easily be a lot larger (potentially even multiple solar orbits of distance if you're really unlucky).

I'm convinced that this particular "astrogation challenge" is one of the reasons why starships are required to have a minimum of 28 days of power plant fuel supply reserve ... JUST IN CASE ...

 

[McPerth]

IMHO, most those details may be handwaived, for easiness of play, until the referee believes they may/must affect, be it for drama, for plot reasons or just to remind players they are here.

It's not unlike the many tables for a jump in MT:SOM. Use them for every jump and you'll son have your players yawning over the table (aside from having a mishap every 36 attempts at least), but they are good in specific situations (haste to jump, some problems, plot needs, etc.)

 

[kilemall]

I’m guessing short of actually modeling system motion that the jump shadow maneuver part will be like communication and warp travel in Star Trek- inconsistencies and physics by needs of the plot.

If you go that way, just be prepared to note those times you impinge such jump shadow/real space effects, particularly from/to pairs and time of year. Doesn’t have to be modeled, does need consistency.