• Welcome to the new COTI server. We've moved the Citizens to a new server. Please let us know in the COTI Website issue forum if you find any problems.
  • We, the systems administration staff, apologize for this unexpected outage of the boards. We have resolved the root cause of the problem and there should be no further disruptions.

Can you predict jump targets by observation?

In a strict CT Bk2, that's wrong. The letter drives use maximum rating no matter how close the target is. And full fuel, as well.

That you can read the jump first attains some canonicity in MT SSOM... but rules appear first in TNE's supplements (Regency SB, IIRC; not checking).
Only true under 1st edition. 2nd ed only needs fuel for the range used, not the nameplate range. At that point, assuming a detectable "flash" proportional to M*Jn, range can be estimated if tonnage is known.

T5 before tech is "standard" quality might work that way though.

Direction can be inferrred (or eliminated from consideration) based on the departure point's position with respect to the origin world -- you can't jump through a planet's 100D exclusion zone.
 
Last edited:
There is a minimum, the fuel for a one parsec jump.

An insystem jump or even a jump that returns you to your starting location uses the minimum of one parsec's worth of fuel.

Unless someone can find a reference to using only a proportion of this for micro-jumps...
 
There is a minimum, the fuel for a one parsec jump.

An insystem jump or even a jump that returns you to your starting location uses the minimum of one parsec's worth of fuel.

Unless someone can find a reference to using only a proportion of this for micro-jumps...
Yes. You can spoof a 1-parsec jump by doing a microjump instead. Heck, you could aim back at the planet and spoof any jump length by forcing an (almost) zeeo-distance jump!
 
Then there's a device I call the jump flasher: a jump torpedo that doesn't work. That is, it gets into jumpspace, but as far as anyone can tell, it doesn't come back out again (at least in any detectable form, let alone in one piece). What it does do is create a jump flash like a Size A drive.

Handy if you are in a vessel that can't jump, but want pursuers to think you just did so they'll stop looking for you.
 
5. I like this . . .
. . . and I'm considering stealing it going forward. Thanks, @Spinward Flow! :)(y)
Please feel free to do so. ;)
Among other things, such an interpretation turns matters into more of a case of "reading tea leaves" rather than singular outcomes of totally definitive answers.

Blockade runners need to have a few tricks up their sleeves. Behavioral spoofing to give false impressions is merely the first of many options for how to disguise intent and purpose.

That 400 ton big craft dawdling along at 1G?
That's a Fat Trader ... not a Corsair ... 🔎
 
TNE doesn't seem to have very clear rules on this. It just states in the Regency Sourcebook (p.79) that if a ship has a sensor lock on another ship as it jumps, it has a good enough view of the jumping ship's entry angle, vector, etc. that "proper analysis" can allow a prediction of the "likely direction and distance of the jump". I haven't found any other reference in the RS, and don't intend reading the whole thing to make sure.

Even without a lock, checking jump shadows and looking at departure vectors and comparing them with desirable inbound vectors in nearby systems should often allow some fairly well-informed guesswork, especially if you know what the jump range of the ship is.

TNE assumed that ships did not jump from standing starts, and tried to line up their vector so that when they re-entered normal space at their destination their vector would line up nicely with their target world, so all they'd need to do is de-accelerate. Compared with a standing jump this cuts down in-system transfer times and also fuel consumption, which is a consideration when using HEPlaR.
 
TNE doesn't seem to have very clear rules on this. It just states in the Regency Sourcebook (p.79) that if a ship has a sensor lock on another ship as it jumps, it has a good enough view of the jumping ship's entry angle, vector, etc. that "proper analysis" can allow a prediction of the "likely direction and distance of the jump". I haven't found any other reference in the RS, and don't intend reading the whole thing to make sure.

Even without a lock, checking jump shadows and looking at departure vectors and comparing them with desirable inbound vectors in nearby systems should often allow some fairly well-informed guesswork, especially if you know what the jump range of the ship is.

TNE assumed that ships did not jump from standing starts, and tried to line up their vector so that when they re-entered normal space at their destination their vector would line up nicely with their target world, so all they'd need to do is de-accelerate. Compared with a standing jump this cuts down in-system transfer times and also fuel consumption, which is a consideration when using HEPlaR.
The assumption in TNE is stacked with the assumption all system have zero relative motion.

So it kind of takes the entirely sensible idea of entering Jump so you’ll be heading toward your destination world on exit with ignoring relative motion.

Relative motion combined with standard approach vectors for the destination world make guessing destination fairly easy IMTU. Of course a ship can enter Jump with any bearing and velocity and burn to correct for relative motion etc. after exit.
 
The assumption in TNE is stacked with the assumption all system have zero relative motion.
I think it doesn't so much assume no relative motion, so much as fold it into the skill check to see if you got your exit vector right. This is a bit generous if using HEPlaR (because the relative motion might require as much a 4 G-hours to match, though less than 1 G-Hour is far more common), but if using reactionless thrusters, it's a perfectly reasonable assumption.
 
This is where that maneuver in jumpspace thing starts to matter- jump on one vector to one system, maneuver to hit another.

Looks like you really need the navigator and powered jump flight after all.
 
This is where that maneuver in jumpspace thing starts to matter- jump on one vector to one system, maneuver to hit another.
If that's true, I guess I've heard it both ways, but if that's true, then instead of "jump lanes" with folks building up vectors based on the destination, everyone would simply be maneuvering trailing the planet. That is, simply, the fastest route to 100D then jump. Because you have a full 168 hours in jump space to adjust the ship for a "perfect" arrival. So, your exits will always be as fast as possible, and your arrivals will be as best as can be managed (given the jump window), again, perhaps, arriving in front of the planet to let it catch you as you decelerate from 100D.

This suggests that, in general, all ships will be leaving in the same direction, regardless of destination, and all ships will be arriving in roughly the same spot.

This does not necessarily apply to HEPLaR ships because they have the fuel constraints to perhaps not burn fuel in order to get the perfect vectors. But with M-drive, they're stuck in Jump Space, and have absolutely nothing better to do. They can spend the first part of the trip "maneuvering" for reentry.
 
Naturally no, there is not a way to predict where a ship is going, though I'd give a player a roll based on nav/int to guess.
 
If that's true, I guess I've heard it both ways, but if that's true, then instead of "jump lanes" with folks building up vectors based on the destination, everyone would simply be maneuvering trailing the planet. That is, simply, the fastest route to 100D then jump. Because you have a full 168 hours in jump space to adjust the ship for a "perfect" arrival. So, your exits will always be as fast as possible, and your arrivals will be as best as can be managed (given the jump window), again, perhaps, arriving in front of the planet to let it catch you as you decelerate from 100D.

This suggests that, in general, all ships will be leaving in the same direction, regardless of destination, and all ships will be arriving in roughly the same spot.

This does not necessarily apply to HEPLaR ships because they have the fuel constraints to perhaps not burn fuel in order to get the perfect vectors. But with M-drive, they're stuck in Jump Space, and have absolutely nothing better to do. They can spend the first part of the trip "maneuvering" for reentry.
My way of thinking is that this is guessing what planet is the target, not specific lanes to pursue them to. So the maneuver would be to change destinations.

Although if one can do that, changing drop lanes would be trivial.

Only a few planets in any given direction the jump ship is going within its jump drive range.

Should be more hazardous.

Retained or possibly gained see, manual normal space propagation vs jump shadow/planetary mass exit, and any other universe rules would impact options.
 
My way of thinking is that this is guessing what planet is the target, not specific lanes to pursue them to. So the maneuver would be to change destinations.
Well, the overall idea is that the lanes form naturally from watching traffic "do what it does", take the most practical direct routes.

There's a story that back when University of California Irvine was first opened, they didn't make any sidewalks.

Rather they let the folks using the campus just start making trails. Then, they took the popular ones and paved them.

If maneuver is relegated to normal space, then it behooves the ship operators to make the most efficient routes through operations before and after jump. The jump itself is this little CEP (Circular error probable) blip in the middle of the route. Simply, Jump is jump, the only place to gain efficiency is in space.

However, if they can maneuver and adjust in jump, that's no longer the case. Now the main drive towards efficiency is getting into jump as soon as possible, because you've got "all week" to prep for arrival. The route is now divided into three distinct phases: pre-, mid-, and post-jump. The game is to get into jump because, all told, that's the real time sink compared in normal space maneuvers.

So, if there is no maneuver in jump, you'll see the organic, colloquially called, jump lanes form as ships line up the most efficient routes to their respective destinations. If you can maneuver in jump, you'll just see everyone running for the hole in space at nearest 100D mark.
 
If that's true, I guess I've heard it both ways, but if that's true, then instead of "jump lanes" with folks building up vectors based on the destination, everyone would simply be maneuvering trailing the planet. That is, simply, the fastest route to 100D then jump. Because you have a full 168 hours in jump space to adjust the ship for a "perfect" arrival. So, your exits will always be as fast as possible, and your arrivals will be as best as can be managed (given the jump window), again, perhaps, arriving in front of the planet to let it catch you as you decelerate from 100D.
When leaving, all directions are equally 'close', because you have the relative motion of the world. The 'best' direction would be 'that which gives a clear jump line to the destination and requires the least travel time', which is usually going to be nearly 'straight up' from wherever you started unless the world is inside the star's jump limit (assuming you care about those).
This suggests that, in general, all ships will be leaving in the same direction, regardless of destination, and all ships will be arriving in roughly the same spot.
This follows, but it follows to a fair extent anyway. Running or standing start, it doesn't matter - even with normal jumps (no in-jump anything) there'll be a 'best' point to jump from and a 'best' to jump to, and these may differ depending on how much acceleration the ship has. If an observer knows the ship's acceleration and destination world they'll be able to make an informed guess as to their planned exit point (assuming they're not choosing a non-optimal one to slow pursuit).
 
(assuming they're not choosing a non-optimal one to slow pursuit).
5aUk0W5.gif
 
Back
Top