Can you predict jump targets by observation?

[Lautenschlaeger]

Maybe my search-fu is weak, but I did not find anything on this.

Context: my group is investigating a pirate operation, which is staking out an attack on a freight. They do not know where the pirates are based, but have encountered a Far Trader about to jump to that base.

Question: Can you deduce the target system of a jumping ship, by observing that ship's jump preparation and transition? E.g. does the jump point, realspace vector, grid charge pattern (or whatever) tell me: "They are jumping to hex XYZ on the map" or at least "They are jumping plus minus x parsecs in a coreward direction"?

 

[mike wightman]

In some iterations of the rules yes but it is difficult. In other iterations of the rules no.

Do you want them to be able to do this in your game?

Do you want police and military ships to be able to do the same?

If the answer to both is yes then do it, it is your game, no one can tell you what to do in it.

 

[Lautenschlaeger]

Thanks, good to know. I guess I'll set this to "general direction is difficult, unless you've got a really cool sensor suite" and "pinpoint is you gotta be kidding me unless you are a specialised military vessel with cutting edge tech". That gives me the most comfortable narrative options as a GM, the way we play.

 

[Condottiere]

In theory, straight line between starship and rift, times energy flash, should give you direction plus threeish light year path they could have dropped out of.

Astrogation charts should give you known large enough gravity wells along that path.

 

[whulorigan]

Thanks, good to know. I guess I'll set this to "general direction is difficult, unless you've got a really cool sensor suite" and "pinpoint is you gotta be kidding me unless you are a specialised military vessel with cutting edge tech". That gives me the most comfortable narrative options as a GM, the way we play.

As Mike said, it depends on edition, but those that allow for it generally imply that the intensity of the "jump-flash" relays some information about the distance of the jump attempted. And if you know that, it filters the number of possible destinations by simply observation of the local astrographics.

 

[Spinward Flow]

I guess I'll set this to "general direction is difficult, unless you've got a really cool sensor suite" and "pinpoint is you gotta be kidding me unless you are a specialised military vessel with cutting edge tech". That gives me the most comfortable narrative options as a GM, the way we play.

Perhaps a more interesting choice would be that the jump flash data allows deductions on where the ship is NOT going rather than where it IS going.

"From these coordinates with this orbital ephemera data, according to our navigational charts they can't be going HERE because there would be a jump shadow in the way, blocking their path along that outbound vector."

Wash, rinse, repeat.
Eliminate possibilities to narrow the options down to the likely destinations ... and then choose where you think they went.

That way, the answer is a multiple choice test and SOME of the possible answers can be eliminated by context and awareness ... but you're unlikely to be able to narrow things down to just a SINGLE destination answer to the problem. And at that point, it becomes a question of "high road or low road?" (kinda sorta) ... and the hunt begins.

 

[Lautenschlaeger]

Thanks all, Il bear those in mind for the game tomorrow.

 

[Spinward Flow]

In theory, straight line between starship and rift, times energy flash, should give you direction plus threeish light year path they could have dropped out of.

MOST starships jump at only a single possible displacement, so any variations in jump flash signature are probably due to the number of parsecs the starship is jumping.

A Scout/Courier jumping one parsec has a jump flash "brightness" of 1 ... and jumping two parsecs has a jump flash "brightness" of 2 ... for example.



In most cases, so long as you know the displacement of the starship making the jump, you can start making educated guesses as to how many parsecs the starship was probably jumping based on the sensor signature of the jump flash.

As soon as you get into VARIABLE DISPLACEMENTS for starships, though ... that kind of educated guess gets a LOT harder to make, because behavioral spoofing becomes an option (intentionally or not, due to external loading).

This is a lot easier to do with LBB2.81 standard drives, since they work on a straight multiply/divide paradigm.



LBB2.81 Drive-A (TL=9) yields code: 2 @ 100 tons and code: 1 @ 200 tons.
So a 100 ton Scout/Courier with A/A/A drives will produce a jump flash for 2 parsecs that is broadly similar to that of a 200 ton Free Trader with A/A/A drives producing a jump flash for 1 parsec. There will be some subtle differences in details, but you'll need some pretty sensitive sensors to pick up on those differences. For the purposes of our discussion here though, let's just say that A/A/A drives produce the same "brightness magnitude" of jump flash when operating at 100% power (J2 @ 100 tons or J1 @ 200 tons).

If you have details of the starship (class) making the jump (it's a Free Trader, not a Scout/Courier) you can start eliminating possibilities.

"A jump flash of that brightness from a starship of that displacement means they must have jumped { insert computational answer } this many parsecs."

And obviously, the longer the jump "the bigger the haystack" of possible destination (hexes) based on the jump point location.



But if you allow external loading of your starships (reducing drive performance) the same way that L-Hyd Drop Tanks and External Demountable Tanks will do ... suddenly ... starship displacements stop being "fixed" and can instead become variable. And what if a starship adds external loading that isn't just fuel tanks (drop or demountable)?

What if you've got a "container ship" that can act as a jump/maneuver tug that can be docked to and towing external loads?



LBB2.81 Drive-H (TL=10) yields code: 3 @ 533 tons, code: 2 @ 800 tons and code: 1 @ 1600 tons.
If the jump drive needs to be run "at full power" in order to jump, the range of the "full power" jump is limited by the total displacement when jumping ... so knowing how much of an external load a starship is encumbered with becomes important.

It's possible to determine the "how much tonnage?" answer from detailed sensor scans ... but depending on the orientation of the sensor target relative to the sensor detectors, this might be a difficult question to answer from sensor readings alone if you can't resolve a visual or a silhouette (turn the target ship a different way, get a different sensor return/silhouette).

It's also possible to make educated guesses about "how much tonnage?" from the maneuver drive performance (1G? 2G? 3G?) ... but even that can potentially be "spoofed" (kinda sorta) by the sensor target starship declining to run their maneuver drive at full power. The ship is currently loaded to 800 tons and is capable of J2/2G, but is maneuvering to a jump point at only 1G ... implying that it is loaded up to 1600 tons and is only capable of J1/1G instead of just 800 tons and capable of J2/2G. By deliberately maneuvering at a lower acceleration to a jump point, the sensor target starship can "camouflage" its true condition and instead operate at J2/1G to mislead an observer into thinking that the starship was only capable of J1/1G. That error in assumption can then be used to lay a false impression of potential destinations based on the brightness of the jump flash.

"A jump flash of that brightness from a starship of up to 1600 tons combined displacement means they must have jumped { runs computation to reach the WRONG conclusion with confidence } only 1 parsec."

When in fact, what was actually observed was a starship of up to 800 tons combined displacement jumping 2 parsecs.



Mind you, this is almost certainly going to be a greater level of depth and detail (as an answer to your question) than you probably need or want ... but I'm giving it to you anyway (pro bono) because that greater level of depth and detail can yield a richer and more textured set of possibilities that can highlight the challenges of deducing where a starship went based on a sensor record of its jump flash. If all you're paying attention to is a single parameter (let's call it "brightness" for simplicity) then you could easily miss a wealth of other important details that would change your conclusions.

Kind of like how nearby dim stars can appear "brighter" to an observer than far away stars that are actually much brighter. Brightness is a function of distance (the old 1/r² deal) such that if you don't know how far away a star is, you're going to have a difficult time figuring out what that star's actual brightness really is. You can look at other data than just the brightness (such as redshift and spectroscopic analysis, parallax, etc.) to get more details, but that takes WORK and more specialized sensors to obtain those additional details.

My point being that sensor signatures (like transponder codes) can be "spoofed" or otherwise camouflaged when you've got the added complication of starships capable of towing external loads. This means that you can't just "know" a particular class of starship is Z many tons (exclusively) and therefore ... { insert jumping to the WRONG conclusions with confidence here }

 

[Marcatlas]

Maybe my search-fu is weak, but I did not find anything on this.

Context: my group is investigating a pirate operation, which is staking out an attack on a freight. They do not know where the pirates are based, but have encountered a Far Trader about to jump to that base.

Question: Can you deduce the target system of a jumping ship, by observing that ship's jump preparation and transition? E.g. does the jump point, realspace vector, grid charge pattern (or whatever) tell me: "They are jumping to hex XYZ on the map" or at least "They are jumping plus minus x parsecs in a coreward direction"?

Depends on Edition. In most you cannot

 

[Dragoner]

Question: Can you deduce the target system of a jumping ship, by observing that ship's jump preparation and transition? E.g. does the jump point, realspace vector, grid charge pattern (or whatever) tell me: "They are jumping to hex XYZ on the map" or at least "They are jumping plus minus x parsecs in a coreward direction"?

I would let the navigator roll a check to see if they could figure it out. It is sort of half and half realistic anyways, likely to be exact no, however there are only so many places they could be jumping to.

 

[whartung]

I'm of the opinion that because your maneuver vector is maintained through jump, that between two planets in two different systems, there is an "optimal approach". Since the navigation task is the same, and time is money, I assert that commercial traffic between two worlds will trend toward similar exit vectors from a world.

These vectors are not set in stone, since the planets move. But they adjust over time. But, on any given day, the bulk of the traffic from Epsilon Irandi V to Gamma Hydra III will be on mostly congruent vectors as they run to 100D. I colloquially call these "Jump Lanes". Jump Lanes have an alternate effect of clustering traffic which makes patrols more effective. Don't patrol the plains, just the trails with the wagon trains.

So, what does that mean?

First, no, you can't tell where a ship is going when they jump.

However, for routine traffic, you can say "The Age of Our Fathers jumped out two days ago, accelerating in the Jump Lane to Kappa Iota IV".

 

[Grav_Moped]

I'm of the opinion that because your maneuver vector is maintained through jump, that between two planets in two different systems, there is an "optimal approach". Since the navigation task is the same, and time is money, I assert that commercial traffic between two worlds will trend toward similar exit vectors from a world.

These vectors are not set in stone, since the planets move. But they adjust over time. But, on any given day, the bulk of the traffic from Epsilon Irandi V to Gamma Hydra III will be on mostly congruent vectors as they run to 100D. I colloquially call these "Jump Lanes". Jump Lanes have an alternate effect of clustering traffic which makes patrols more effective. Don't patrol the plains, just the trails with the wagon trains.

So, what does that mean?

First, no, you can't tell where a ship is going when they jump.

However, for routine traffic, you can say "The Age of Our Fathers jumped out two days ago, accelerating in the Jump Lane to Kappa Iota IV".

If you're willing to tolerate inefficiency (and with almost-free maneuver except for the wasted time, you can), you can feint toward a different destination with your outbound realspace track.

 

[whartung]

If you're willing to tolerate inefficiency (and with almost-free maneuver except for the wasted time, you can), you can feint toward a different destination with your outbound realspace track.

Absolutely. You can pull a "Millennium Falcon", get in the Jump Lane for some distant system, but actually just jump back to the origin system. Ideally your pursuers will chase after you and end up in that distant system.

 

[Spinward Flow]

If you're willing to tolerate inefficiency (and with almost-free maneuver except for the wasted time, you can), you can feint toward a different destination with your outbound realspace track.

Really?
You don't say ...

 

[Enoki]

Well...

While I ascribe to the idea that momentum is conserved when you jump, I also increase risk of a mis-jump if you aren't stopped when you do it. As far as determining where a ship is going, I'd say you really can't tell other than if you have some idea what its jump capacity is. For a J1 ship this is to just one (using the game map) of six destinations, with empty hexes eliminated. For J2 it increases to 18 hexes, most of which are likely empty too.

Of course, that's trying to deduce where a ship jumped to versus tracking the ship itself.

I would allow some generalized direction reducing the possible locations--again in reference to the game map--where if they were doing a J1 it's pretty obvious where they're going (one of six hexes), or if say J2 one of just 3 to 5 hexes (think a cone shaped volume of space ahead of the ship that grows as distance increases).

I also allow (depending on crew skill levels) not jumping to the primary planet in a system and making inner system jumps (like jumping from 100d off Earth to Pluto for example). In my version, a jump often ends with the ship not at the 100-diameter distance from the world jumped to but further out due to crew skill levels. Higher skill levels mean greater jump accuracy.

 

[Grav_Moped]

Higher skill levels mean greater jump accuracy.

I think some rules versions include this.

CT does not, but I lampshade it in, sometimes, for dramatic effect.

 

[MontyLovering]

IMTU the relative motion between star systems is compensated for on the burn out to 100D, with the ship moving as required for the desired vector and velocity on arrival (which is normally toward the destination world).

That means the vector and velocity (which might be in 10 km/s in the opposite direction to the destination, but is required as that system is heading towards the system the ship is in), are fairly determinative. Even if there are multiple systems within range of the ship the relative motion of each is unlikely to be similar (in practice I roll a D6 for each system if this needs to be determined, if the value is the same then the ship could be heading for either one if they are in range.

Of course a ship can Jump from one system into another with any vector and velocity. It might mean you enter the destination system moving at 10 km/s in the + z relative to the system's mean orbital ecliptic and would need to manoeuvre some to have a useful vector or stable orbit of the destination system.

So you can make it look like you're matching for the relative motion of X and Jump to Y.

I might be persuaded that there is a dT x Jn 'flash' (of visible light or otherwise) that can determine Jn if dT is known.

But I prefer not to; my idea of J-drive is that is is based on the McMuffin effect that allows reationless manoeuvre drives and power plants, all made possible via manipulating gravity. The J-drive is seldom discovered as it is a counter intuitive use of the McMuffin effect that is the equivalent of turning the knobs up all the way and overloading the field to the point the ship pops through a pseudo-singularity into Jump space and anything in the immediate proximity, include all energy flux, goes with it. Most sophont species either never try it as the equations are the equivalent of 'there be dragons', or do try it and basically assume it's a dead-end as it makes the vessel with the device on it disappear and anything attached to it get cut off. "Oh it just crushes things in a pseudo-singularity' is the conclusion. Only a few species go down the pub, have a drink in memory of Jim, the daft bugger, and see if they can figure out how to protect from the effects of whatever the hell is happening.

But the absurd idea of ships turning around midway to 100D so that they Jump whilst 'stationary' makes my brain hurt. Stationary relative to what? If their velocity is 0 in relation the vector the took to reach 100D of the planet they have just left, they are still moving, for example at 30 km/ s in orbit of the system primary and 230 km/s in orbit of the galactic core.

 

[Condottiere]

Going down the rabbit hole should be a dead stop in relation to the rest of the universe.

Unless, there's rift drift in the space time continuum.

 

[aramis]

MOST starships jump at only a single possible displacement, so any variations in jump flash signature are probably due to the number of parsecs the starship is jumping.

A Scout/Courier jumping one parsec has a jump flash "brightness" of 1 ... and jumping two parsecs has a jump flash "brightness" of 2 ... for example.

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).

 

[Black Vulmea]

IMTU:

1. If a starship jumps with a relative velocity of zero - the standard assumption in CT - then direction cannot be determined beyond the obvious limits of drive capability and known star systems in range.

2. Because a starship "retains the speed and direction that it had when it entered jump" (JTAS 24, "Jumpspace," by Marc Miller), if a starship's relative velocity is greater than zero, it's possible for a sharp navigator to infer a possible destination - my house rule is throw 13+, +1 per 1000 mm of vector, +3 per level of Navigation skill. Spies often make these sorts of observations of military vessels, which is one reason warships on routine business "slow to zero" before jumping.

3. Commercial traffic files a flight plan before ascent and notifies system control - a system control exists in all star systems with A or B starports automatically or in systems with a C starport on a throw of 7+ - of its destination on arrival at the jump point. This information is shared among Imperial starports as well as non-Imperial 'ports in high traffic areas and is used in declaring ships overdue. A skipper can lie and change destinations, announce an "unconfined" jump with no destination, or simply jump with no notice to system control at all, but eventually the word gets around to different starports of this behavior which tends to attract "Imperial entanglements."

4. Many starships are dependent on commercially available flight plans due to the expense of the Generate program; in fact, many if not most corporate-owned starships require their skippers to use pre-generated plans to ensure the ship is going to the corporation's desired destination. A key part of hijacking a ship is bringing along a Generate program so the hijackers can feed the navigation system a new destination, if their intent is to escape with the entire ship instead of merely offloading cargo and/or taking prisoners for ransom. Data brokers may hack commercial flight plan dealers to obtain information on plans sold and sell the same to pirates and hijackers.

5. I like this . . .

LBB2.81 Drive-A (TL=9) yields code: 2 @ 100 tons and code: 1 @ 200 tons.
So a 100 ton Scout/Courier with A/A/A drives will produce a jump flash for 2 parsecs that is broadly similar to that of a 200 ton Free Trader with A/A/A drives producing a jump flash for 1 parsec. There will be some subtle differences in details, but you'll need some pretty sensitive sensors to pick up on those differences. For the purposes of our discussion here though, let's just say that A/A/A drives produce the same "brightness magnitude" of jump flash when operating at 100% power (J2 @ 100 tons or J1 @ 200 tons).

If you have details of the starship (class) making the jump (it's a Free Trader, not a Scout/Courier) you can start eliminating possibilities.

"A jump flash of that brightness from a starship of that displacement means they must have jumped { insert computational answer } this many parsecs."

And obviously, the longer the jump "the bigger the haystack" of possible destination (hexes) based on the jump point location.

But if you allow external loading of your starships (reducing drive performance) the same way that L-Hyd Drop Tanks and External Demountable Tanks will do ... suddenly ... starship displacements stop being "fixed" and can instead become variable. And what if a starship adds external loading that isn't just fuel tanks (drop or demountable)?

What if you've got a "container ship" that can act as a jump/maneuver tug that can be docked to and towing external loads?

LBB2.81 Drive-H (TL=10) yields code: 3 @ 533 tons, code: 2 @ 800 tons and code: 1 @ 1600 tons.
If the jump drive needs to be run "at full power" in order to jump, the range of the "full power" jump is limited by the total displacement when jumping ... so knowing how much of an external load a starship is encumbered with becomes important.

It's possible to determine the "how much tonnage?" answer from detailed sensor scans ... but depending on the orientation of the sensor target relative to the sensor detectors, this might be a difficult question to answer from sensor readings alone if you can't resolve a visual or a silhouette (turn the target ship a different way, get a different sensor return/silhouette).

It's also possible to make educated guesses about "how much tonnage?" from the maneuver drive performance (1G? 2G? 3G?) ... but even that can potentially be "spoofed" (kinda sorta) by the sensor target starship declining to run their maneuver drive at full power. The ship is currently loaded to 800 tons and is capable of J2/2G, but is maneuvering to a jump point at only 1G ... implying that it is loaded up to 1600 tons and is only capable of J1/1G instead of just 800 tons and capable of J2/2G. By deliberately maneuvering at a lower acceleration to a jump point, the sensor target starship can "camouflage" its true condition and instead operate at J2/1G to mislead an observer into thinking that the starship was only capable of J1/1G. That error in assumption can then be used to lay a false impression of potential destinations based on the brightness of the jump flash.

"A jump flash of that brightness from a starship of up to 1600 tons combined displacement means they must have jumped { runs computation to reach the WRONG conclusion with confidence } only 1 parsec."

When in fact, what was actually observed was a starship of up to 800 tons combined displacement jumping 2 parsecs.

. . . and I'm considering stealing it going forward. Thanks, @Spinward Flow!

So, if a pirate is attempting to escape a system quickly, which is to be expected given the hazards of the trade, they often jump "at velocity" and it's possible to infer a destination. If a pirate has the opportunity to "slow to zero" to disguise their destination, they may and probably will. But there's one more point to consider:

6. The weakest point of any security system is its human beings. Get a pirate drunk enough, lure 'em into an indiscreet position - *ahem* - or seize 'em and load 'em up with Truth drug, and you may find answers more quickly than watching jump flashes.