CT Sensors: Detection and identification

[Vido]

First post to the forums, looking for feedback from veteran players! I've been lurking for a while and I hope this is the correct board to post this...

For a campaign I'm currently running (using The Traveller Book) I wanted to lean a bit further into sensor play, since I believe it could create some interesting situations. After reading several house rulings and versions, I decided to come up with my own... which I hope it's simple enough for my table.
First of all, the detection ranges in page 76 (TTB) are interpreted as the minimum distance required to get a sensor lock on an active or silent target (0.5 light-seconds and 0.25 light-seconds for civilians, for instance). Actual detection is automatic and its ranges are much further (I'm thinking about 3 light-seconds, maybe further for military/scout vessels), and I'll probably just tell them outright what contacts their sensors detect. However, to properly identify one such contact, a sensor lock must be achieved using the following rules:

To manage a sensor lock with a bogey for identification and determination of a fire solution (laser fire without one is subject to a DM-4), throw 8+ on two dice (2d6) with the appropriate DMs. Sensor locks are rolled during the movement phase in space combat, either at the beginning (before movement) or at the end (after movement).

SENSOR LOCK DMs

10+ ton hull	-1
100+ ton hull (usual scenario)	+0
1000+ ton hull	+1
10000+ ton hull	+2
100000+ ton hull	+3
Power plant	+Pn/2 (round up)
Maneuvering	+1 per G
Transponder squawking	+3
Going cold	-1
Detect-n	+n (halve if target uses ECM)
ECM-n	-n
ECCM-n	reduce ECM DM by n
Gunnery expertise	+1 per level

Notes on DMs:

• Hull tonnage: Larger cross-sections and masses will be easier to image.
• Power plant: Signature provided by power plant heat radiation. "Pn" is the power plant number in the drive potential table (page 58).
• Maneuvering: M-Drive flares are easy tracking data.
• Transpoder squawking: Transponders make identification much easier for scanning vessels and air control.
• Going cold: Running the systems on minimum power and reducing emissions make it harder to isolate the signal. Neither M-Drive or J-Drive can be used when going cold. Passengers will also be uncomfortable.
• Detect: Program for computer-aided signal processing. Susceptible to ECM. Detect programs are leveled 1 to 3.
• ECM: Program for active jamming/spoofing to degrade a lock. ECM programs are leveled 1 to 5.
• ECCM: ECM programs can be run in ECCM mode to allow identification and filtering of false-positives and jammer noise.

Further clarifications would be that the Target program is the one to coordinate turrets for actual fire, and Multi-target allows for sensor locks on more than one contact. Also, not sure about transponder spoofing... should I just count it as part of what ECM does?

 

[Vido]

An extra optional rule could also be interesting to add, to make going cold less of a "free -1" for non-civilian ships:

When going cold, ship's computer may still be used, albeit at a "low power" mode. Only a single program (which has the proper capacity to fit) may be run at any single time. Thus, ships have the tactical decision of not being able to run ECM + Target at once when going cold (regardless of computer model), and might prefer to just turn off the drives and loiter at regular power levels.
Or perhaps rule it so that CPU is halved when going cold.

 

[Vido]

One possible solution to the transponder tampering...

Transponder spoofing: Ships that have an active transponder broadcast their identification (vessel ID, tonnage, name, performance...) to aid traffic control. However, in order to fool detectors, these signals can be tampered with (which is illegal in all but the lawless of worlds). Spoofing counts as ECM-1 for the purpose of achieving a sensor lock, but if failed, the target (in this case, the one broadcasting false IDs) can opt to give out false information to the other vessel instead (in addition to not letting it achieve a sensor lock).
Now, obviously if a so-called "humble 200-ton Free Trader" wants to dock with you but looking out the window you see a Corsair, then it may already be too late to check your sensors again.
Transponder spoofing can be done by software on military ships (included in ECM program operation), but on civilian ones the device must be physically tampered with (risky since it can be found out in an inspection) after crawling into the avionics, which could easly imply a throw (DMs for electronics skill, high education... a failure might still allow spoofing but the tampering will be obvious if inspected).

 

[kilemall]

Nicely comprehensive.

While I like the ship program subgame, my players don’t. So I go with detection range by computer model, and differentiate sensors by type and long vs. short and active vs passive.

The sensor type expands on the JTAS article that parts of went forward on Mongoose, but I added some like acoustic and EMF. This is mostly to allow for stealth and wily detection games.

 

[whartung]

Off the cuff, I see nothing about how long a lock lasts, and there seem to be no DMs for range at all. (Contrasting that there's a difference between detection and lock.)

Other than that, how does it play for you?

 

[Spinward Flow]

I go with detection range by computer model, and differentiate sensors by type and long vs. short and active vs passive.

I have to say, using a "computer model = sensor quality" paradigm makes things a LOT simpler and easier. Just drop the bis and fib notations and use the straight number of the computer model.

• Short Range scanning (details: yes) @ (computer model # + 1) * 0.1 light seconds
• Long Range detection (details: no) @ (computer model # + 1) * 0.2 light seconds
• Extreme Range tracking after being detected @ (computer model # + 1) * 0.3 light seconds

It's a slightly different paradigm than what is offered in LBB2.81, p32 or TTB, p76 ... but it offers more variability in possible matchups.

Note that the above paradigm makes no distinction between civilian vs military sensors, but it can be (somewhat) safely assumed that military craft will tend to have "better computers" installed on them (because: combat) than the "absolute cheapest/bare minimum necessary" for civilian/commercial operations.

The above paradigm does mean that a model/9 computer can:

• Make detailed scans of craft within 1 light second
• Can detect "new" contacts within 2 light seconds
• Can track "already known" contacts out to 3 light seconds

... which is reasonably congruent with LBB2.81 and TTB design potentials, except extended out to include LBB5.80 developments up to model/9 computers. So not a perfect alignment with precedent ... but close enough to keep things simplified and easy to use.

If it helps to borrow from Star Trek bridge operations examples ... think of Short Range scanning as being the "coming within visual range/on screen" threshold of distance. Beyond that range, the sensors can "detect" but they can't resolve images/give many details ("have it on sensors, now, captain") ... although some things will tend to be obvious (such as acceleration rate) even at long range. Exceed the Extreme Range band and "we've lost them, sir" and the target will need to be re-acquired using Long Range before tracking can resume.

SENSOR LOCK DMs

Honestly, this feels like a LOT of complexity for not a whole lot of return on the investment.
In LBB2/TTB space combat, ECM is simply there to defeat incoming missile attacks ... not sensor acquisition/tracking by opposing craft.

If you absolutely HAVE TO include an ECM/ECCM=EW layer to sensor detection and tracking, I would simplify it into being a case of modifying the computer model # for the above Short/Long/Extreme sensor ranges I outlined above. Craft with an ECM program running force all opposing craft to use the relative computer model # as a modifier to determine their range bands for sensors.

Model/4 computer with ECM program opposing model/3 computer without ECM program (a -1 relative model # disadvantage).

• Model/4 computer with ECM program ranges (short/long/extreme): 0.4/0.8/1.2 light seconds
• Model/3 computer without ECM program ranges (short/long/extreme): 0.2/0.4/0.6 light seconds

Model/4 computer with ECM program opposing model/4 computer ALSO with ECM program (a -0 relative model # disadvantage).

• Model/4 computer with ECM program ranges (short/long/extreme): 0.4/0.8/1.2 light seconds
• Model/4 computer with ECM program ranges (short/long/extreme): 0.4/0.8/1.2 light seconds

This creates a rules paradigm in which overmatch between computer models is required in order for ECM to be "effective" against opposing sensor systems for the purposes of detection and tracking ranges.

Note that this overmatch potential becomes "a lot easier" when opposing forces have differing tech levels of construction ...
Net result is that higher tech level fleets will tend to detect and maneuver "favorably" around lower tech level fleets because of the computer model differential in sensor ranges allowing earlier detection and longer range tracking, resulting in a "bias" of initiative favoring the higher tech level fleet.

 

[Vido]

While I like the ship program subgame, my players don’t. So I go with detection range by computer model, and differentiate sensors by type and long vs. short and active vs passive.

That's a shame... I was unsure about using it at first, but when I stumbled upon this suggestion on another thread:

BTW: a way I've helped players keep it straight when managing programs in the game is by using 3x5 cards printed with the name of the program, it's effects, and it's space requirement.

The players have two stacks: one for the CPU and one for Storage. They shuffle the cards back and forth between the stacks as they use them in the appropriate phase, or for routine operations. This way it not only gives the computer PC something to do that adds atmosphere, but it is really easy to see what's running in the computer at any given time.

I really liked that method. So I made some playing card sized papers with CPU size, title and a brief description of the program, then fit them into dust covers. It ended up being quite useful, and during their first space combat they seemed to enjoy the mini-game!

---

Off the cuff, I see nothing about how long a lock lasts, and there seem to be no DMs for range at all. (Contrasting that there's a difference between detection and lock.)

Other than that, how does it play for you?

You're right... I forgot to mention those parts.

But first I probably should better define the difference between:

• Detection: This is just a "blip on the screen", meaning that there's something there, you just don't know exactly what it might be. Detection will give the general direction and distance to a space borne object. If its emissions are very strong though, additional clues as to what it is could be provided. Detection is automatic at a range of 1 LS for civilian ships, or 3 LS for military ones. Tracking range is equal to detection range.
• Sensor Lock: This is pointing sensors arrays and such towards the actual detected object in order to identify it. A lock will give accurate position, vector, ship type, drive potentials... depending on the information available, as well as allowing a firing solution to be calculated. The range at which a lock is possible is the "active range" of a ship, and is equal to 0.5 LS for civilian ships, or 2 LS for military ones.

Regarding duration: Once achieved, a lock lasts indefinitely unless the target leaves active range. A target actively using countermeasures will probably require the lock to be renewed each combat turn.
Regarding range: My original idea was to factor in range as the binary condition which lets someone detect an object (at detection range) or try to lock it (at active range). For more granularity I might rule that a DM+4 is applicable if target is at half-active range or closer, or DM-4 if trying to lock past active range (at a maximum of 1 LS further).

As of now I haven't had the chance to test these rules yet, but posted them anyway to try and refine them as much as possible before our next gathering! Last time I used some iffy sensor rules and wasn't convinced.

 

[Vido]

I have to say, using a "computer model = sensor quality" paradigm makes things a LOT simpler and easier. Just drop the bis and fib notations and use the straight number of the computer model.

• Short Range scanning (details: yes) @ (computer model # + 1) * 0.1 light seconds
• Long Range detection (details: no) @ (computer model # + 1) * 0.2 light seconds
• Extreme Range tracking after being detected @ (computer model # + 1) * 0.3 light seconds

It's a slightly different paradigm than what is offered in LBB2.81, p32 or TTB, p76 ... but it offers more variability in possible matchups.

Hmm... I do like having the computer model determine sensor quality (and scanning range). Last version I had was (in short) roll 2d6 under computer model number, with a couple of applicable DMs.

Honestly, this feels like a LOT of complexity for not a whole lot of return on the investment.

Well, my plan is to have the players roll to identify stuff, to have tension... So if there's a throw, it's only natural that there are DMs. I listed some off the top of my head, but the list is certainly not exhaustive.

About the table: Since most encounters will be with ships in the 100-999 ton range, I could do away with the first five rows (hull tonnages) to reduce bookkeeping. Maybe leave only the first one, listed as "small object/ship's boat". To speed things up, a simple list with all the power plant signatures and M-Drive potential for each common ship could be useful, such as:

• Free Trader - 1/1G
• Scout/Courier - 1/2G
• Merc. Cruiser - 2/3G
• ...

While adding in electronic warfare is not strictly necessary to me, I feel like it complements quite well starship operations and space combat. It adds another very interesting dimension, because I can totally picture ships using decoy drones, or launching sand/chaff canisters just to mess with possible locks and not be attacked. Maybe even sensor drones to detect and ping remotely.
I have no military experience or anything like that, but I just feel like those things would make sense.

 

[Vido]

Like so:

SENSOR LOCK DMs

Small object / Ship's boat	-1
Power plant	+Pn/2 (round up)
Maneuvering	+1 per G
Transponder squawking	+3
Going cold	-1
Detect-n	+n (halve if target uses ECM)
ECM-n	-n (or reduce target's ECM DM by n)
Gunnery expertise	+1 per level

Note: These are just for common circumstances. Other DMs are possible in other situations as determined by the referee.

 

[Spinward Flow]

BTW: a way I've helped players keep it straight when managing programs in the game is by using 3x5 cards printed with the name of the program, it's effects, and it's space requirement.

The players have two stacks: one for the CPU and one for Storage. They shuffle the cards back and forth between the stacks as they use them in the appropriate phase, or for routine operations. This way it not only gives the computer PC something to do that adds atmosphere, but it is really easy to see what's running in the computer at any given time.

I really liked that method. So I made some playing card sized papers with CPU size, title and a brief description of the program, then fit them into dust covers. It ended up being quite useful, and during their first space combat they seemed to enjoy the mini-game!

That actually DOES sound like a much more intuitive/obvious way to handle the computer (re)programming mini-game when you can't have everything running at once.
Additionally, I would not have known about it if you didn't link to it.

Hmm... I do like having the computer model determine sensor quality (and scanning range). Last version I had was (in short) roll 2d6 under computer model number, with a couple of applicable DMs.

The trouble with using a 2d6+DMs roll is that ... the dice will conspire against you.
This will create edge case scenario possibilities that essentially wind up being ridiculous and/or demand gross incompetence from someone (either PC or NPC) in order to explain the outcome(s).

Knowing what is nearby around your craft in an orbital context is the difference between survival and DEATH.
I don't think I should need to explain why that is the case, right?
Do you REALLY want to "play dice with the universe" on the question of whether or not your sensors can do their (one) JOB or not?

SENSOR LOCK DMs

Honestly ... this revised (now shorter) list of DMs doesn't fill me with confidence either.

If anything, the hull size DM ought to be using the modifiers from LBB5.80 combat (because consistency is helpful).

• Hull Code: 0 ... -2 DM (up to 99 tons)
• Hull Code: 1-A ... -1 DM (100-1999 tons)
• Hull Code: B-K ... +0 DM (2000-19,999 tons)
• Hull Code: L-P ... +1 DM (20,000-74,999 tons)
• Hull Code: Q+ ... +2 DM (75,000+ tons)

I don't much care for the Pn/2 DM, partially because it feels like something of a "pile on" in favor of the detectors. It also means that most warships are going to be "so loud" on sensors that you can't miss them. The flipside argument is that Neutrino Sensors are a TL=A+ bit of kit that is going to be pretty standard as a part of sensor suites, because you can use them to determine if a sensor contact has a nuclear reaction (Y/N?) happening inside of it. If yes, that's almost certainly a power plant ... so that's very likely to be a manufactured craft of some kind. The only way to get around this problem, by my way of thinking, would be use of Jump Capacitors (introduced in LBB5.80) to enable basic power to be sustained (basically, battery power) while the (nuclear) power plant is shut down (so, Neutrinos? N) for attempts at behavioral spoofing to get close enough to pull off a surprise of some kind.

The acceleration DM makes more sense, since objects actively accelerating are going to be much more "important" from a detection standpoint, so the analysis algorithms would be trained/tuned to find and label such objects. Being able to "drift past a sensor net" as a zero acceleration object "too far away to scan in detail" is an important behavioral spoofing trick that ought to be preserved.

Detect-n and ECM-n are not a part of the baseline RAW computer programming options, so you have to be doing some kind of house rule stuff there.

Gunnery skill has nothing to do with sensor analysis.
If anything it ought to be Navigation skill (of all things) that is canonically involved in long range sensor analysis.

LBB1.81, p21 or TTB, p27:

The navigator interprets the long-range data provided by the ship's scanners and detectors.

If anything, I'd say that the real defining difference ought to be between Detection (which can be done at "long" range) and Detailed Analysis (which I'm postulating ought to be done within "short" range). That way, you need to "move closer" if you want to get "a better look" at anything you've detected.

 

[Vido]

This will create edge case scenario possibilities that essentially wind up being ridiculous and/or demand gross incompetence from someone (either PC or NPC) in order to explain the outcome(s).

Fair enough. I should add an "auto-identify range" factored from active range, so that close enough objects can be recognized without the need of a roll. It ought to be long enough to make sense but short enough to discourage closing in to anything suspicious.
On second thought this is what you were proposing, if I understood correctly!

• Short Range scanning (details: yes) @ (computer model # + 1) * 0.1 light seconds
• Long Range detection (details: no) @ (computer model # + 1) * 0.2 light seconds
• Extreme Range tracking after being detected @ (computer model # + 1) * 0.3 light seconds

Though in my case I would keep the roll as a thing for those regions in between. To get a detailed scan for something in "long range", for example.

If anything, the hull size DM ought to be using the modifiers from LBB5.80 combat (because consistency is helpful).

For now I'm not planning on using High Guard... although there are many aspects of it that I like! Once my players have a stronger grasp on the fundamentals I'll look into using/adapting more stuff from it.

I don't much care for the Pn/2 DM, partially because it feels like something of a "pile on" in favor of the detectors. It also means that most warships are going to be "so loud" on sensors that you can't miss them.

If you mean that because warships will have drives with higher potentials (and thus require more powerful power plants relative to their hull size) then yes, although I assume such warships would be loaded with countermeasures to reduce their sensor signature, and/or with more powerful computers to have the range advantage despite it.

Detect-n and ECM-n are not a part of the baseline RAW computer programming options, so you have to be doing some kind of house rule stuff there.

Those are house rules, yes. I provided a brief description for them in my first post, but just in case here is a more detailed listing of those programs (just the relevant part):

Detect: Increases the ship's computer's ability to filter readings and provide viable data for the sensor operator. The program will provide computer augmented "guesses" in attempts to aid the sensor operator with probable readings. It is susceptible to electronic countermeasures, halving its ability to gather correct data.

• Detect-1. DM+1 for sensor lock attempts. CPU 1.
• Detect-2. DM+2 for sensor lock attempts. CPU 2.
• Detect-3. DM+2 for sensor lock attempts. CPU 1.
• Detect-4. DM+3 for sensor lock attempts. CPU 3.
• Detect-5. DM+3 for sensor lock attempts. CPU 2.

ECM: Interferes with missiles, exploding them prematurely or rendering them inert. It is also used as active jamming/spoofing to degrade a lock, or can be run in ECCM mode to allow identification and filtering of false-positives and jammer noise to counter an opposed ECM program. It is now available in multiple levels, and substitutes the one listed in the book (which would be equivalent to ECM-2).

• ECM-1. Disables missiles on a throw of 8+. DM-1 for enemy sensor lock attempts, or reduce target ECM by 1. CPU 2.
• ECM-2. Disables missiles on a throw of 7+. DM-2 for enemy sensor lock attempts, or reduce target ECM by 2. CPU 3.
• ECM-3. Disables missiles on a throw of 6+. DM-3 for enemy sensor lock attempts, or reduce target ECM by 3. CPU 4.
• ECM-4. Disables missiles on a throw of 5+. DM-4 for enemy sensor lock attempts, or reduce target ECM by 4. CPU 5.
• ECM-5. Disables missiles on a throw of 4+. DM-5 for enemy sensor lock attempts, or reduce target ECM by 5. CPU 6.

There's also other programs I made that let a ship provide guidance to missiles to help them defeat ECM and such.
Haven't had the chance to test these yet, though!

Gunnery skill has nothing to do with sensor analysis.
If anything it ought to be Navigation skill (of all things) that is canonically involved in long range sensor analysis.

You're right there about Navigation. I pictured a gunner would know how to properly focus sensors in order to determine range, hull dimensions, etc. in order to get firing calculations. Perhaps it's best listed as a skill that could substitute for Navigation in this situation, albeit at a lower level. This could be the case for Electronics as well.

 

[kilemall]

Since I’m resolving along mostly HG lines with a range DM component I usually leave the EW component for the weapons to the computer model plus minus DM.

For further intel/analysis, I do have a lock on/target solution roll. Each successful roll can yield more detail like exact tonnage, damage state, etc and once it’s failed no more that round.

A big DM is the ship being scanned either active emission in the EM band of the sensor, or passive, and if the sensor is active or passive.

Besides an interplay about how sneaky the sensor or target is being tradeoffs, there is a big design issue of stealth- basically 10% per -1 DM per EM band.

One can set stealth for more common sensors and slide by cheaply only to be thwarted by the occasional specialized scout or science ship, or pay up and have a totally -4 DM ship- at 5x the base cost. Including maintenance and repairs.

That’s why stealth IMTU is usually reserved to small craft- perfect for sneaking around, special missions, infiltration, scouting, extraction, smuggling etc but not really Romulan type major warships.

Another subgame is using active sensors may be construed as hostile. A science ship may be using active for just ranging to calibrate an accurate reading and gain more intel/what is the object but be interpreted as a threat, with consequences. First contact protocol may involve passive only.

Spinward I use the HG size DMs for both sensor ship and target detect mods, on the theory that sensors are mounted on hulls in VLA clusters, the bigger the hull the more clusters and therefore array resolution.

 

[kilemall]

Oh minor point for Spinward- sensor operators for me are either Electronics, Navigation, Gunnery or Survey skill.

Electronics is the catch all no plus/no negative DM. The others are +1 for their specialty and -1 for all others. But they have to be doing just the sensor work, else just the computer running it with minimal instruction/filters/capability.

So gunnery could be doing it for combat but they won’t be dual use firing. On a practical basis most warships will have a dedicated electronics/gunnery rating doing their sensor work, and smaller ships typically the navigator if they aren’t pulling other duty.

My view of skills in Traveller is they are broad and getting accurate target locks is a big part of success, so they are trained to do that. Not so much scanning for life forms on the planet or detection of space hazards.

 

[Spinward Flow]

On second thought this is what you were proposing, if I understood correctly!

Now you're cottoning on.

Though in my case I would keep the roll as a thing for those regions in between. To get a detailed scan for something in "long range", for example.

Short Range, details are automatic (no need for rolls).
Long Range, details do require a sensor operator roll (cue: Navigation skill use) in order to resolve details. Could even do a "margin of success" type thing where the better the roll the more numerous the details you're able to obtain at beyond Short Range.

For now I'm not planning on using High Guard... although there are many aspects of it that I like! Once my players have a stronger grasp on the fundamentals I'll look into using/adapting more stuff from it.

In this case, there's no (good) reason NOT to borrow something from High Guard, even if you aren't using it YET.
For one thing, it will help cut down on confusion later when you start introducing High Guard type elements into your gameplay.

If you mean that because warships will have drives with higher potentials (and thus require more powerful power plants relative to their hull size) then yes, although I assume such warships would be loaded with countermeasures to reduce their sensor signature, and/or with more powerful computers to have the range advantage despite it.

The downside with that approach is that there are no "countermeasures" for neutrino detectors, since neutrinos pass through all normal matter like it isn't there (most of the time). I'm hard pressed to come up with any plausible ECM "notions" that would "confuse" detection akin to what you can do with the EM spectrum. Not saying it CAN'T be done, just that I can't fathom how it would be done.

Also, take a step back and examine what you're doing here.

Military craft need big power plants to power weapons, screens and computers.
They need big computers to run big ECM programs.
They need to run big ECM programs to mask the blindingly bright sensor signature of their big power plants.
You're kind of building something of an ouroboros there (snake eating its own tail) in terms of baseline assumptions for game mechanical structure.

It's not exactly "rocket equation" self-defeating (need a bigger rocket to lift more fuel, which needs an even bigger rocket to lift even more fuel ... etc. etc. etc.) on the diminishing returns scale, but it's getting there.

There's also other programs I made that let a ship provide guidance to missiles to help them defeat ECM and such.
Haven't had the chance to test these yet, though!

You're right there about Navigation. I pictured a gunner would know how to properly focus sensors in order to determine range, hull dimensions, etc. in order to get firing calculations.

Actually, no.
Consider that gunners on space craft aren't exactly using iron sights on machine guns within Mk I Eyeball visual range.
When combat ranges are measured in fractions of a light second (!) ... everything is going to be "beyond visual range" for the gunnery crews.

All space combat ... with extremely RARE exceptions ... is going to be handled by computer tracking and automation. While in combat, the "job" of the gunner(s) is to mark targets (shoot this, not that) and push the big red button marked "FIRE!" (or equivalent) to command the weapon(s) to engage. There's no "slewing of the turret ring pintel mount" by hand to line up the shots and squeeze the trigger.

Gunnery crews in space craft have more in common with the gunners of modern day (real world) battle tanks ... stare at a screen and command the turret, let the auto stabilizer do a LOT of the work ... click the button ... while in combat. Out of combat, their primary "jobs" are maintenance of the weapon systems (go figure) and running simulations (play FPS every day and get paid!).

Observe
Orient
Decision
Action

OODA looping is what "being a gunner" is all about. Most of what makes gunnery possible (let alone successful) is a plethora of automation aids (in Traveller, this means computer programs). Gunners "make things go AWAY" ... rather than concern themselves with the details and nuances of sensor readings to identify stuff.

Designate
Lock
Fire

Asking for details about a sensor ping ... don't ask the gunnery chief, ask the navigator (if you have one!).

This could be the case for Electronics as well.

TTB, p23:

Electronics: The individual has skill in the use, operation, and repair of electronic devices. The person is considered handy in this field, with the equivalent of a green thumb; this skill includes the repair of energy weapons. An advanced technological civilization depends heavily on the use of electronic devices. The need to use, repair, and replace electronic devices is ubiquitous.

Electronic expertise allows a character to use and operate electronic items; generally the skill is a DM applied to the throw to understand, repair, assemble, or operate. Complex items would also require a certain level of education or a very high intelligence; many devices may also require some degree of dexterity to disassemble, repair, and reassemble.

Some people would say that this means that someone with Electronics skill would know how to interpret (complex) sensor readings. Whether you want to make the navigator's role as the skill to "parse" sensor data (correctly) exclusive or not, is up to you.

You could even "split the baby" such that someone with Electronics skill can look at a sensor readout and know "yup, something's out there!" but be unable to give much more detail than that. Conversely, someone with Navigation skill can look at a sensor readout and know "that's a Free Trader maneuvering on course {insert trajectory plot here}, it looks to be unarmed and probably has a hold full of cargo" ... which is a lot more details and context than the "yeah, I've got a contact on the screen bearing {insert number mark number} at range {insert number}, characterization: unclear" interpretation with Electronics skill would yield.

It would be the difference between USE (electronics) and having the skill to PARSE (navigation) what the equipment is telling you.

 

[Vido]

Short Range, details are automatic (no need for rolls).
Long Range, details do require a sensor operator roll (cue: Navigation skill use) in order to resolve details. Could even do a "margin of success" type thing where the better the roll the more numerous the details you're able to obtain at beyond Short Range.

I like it, thanks! I'll definitely look more into it, then maybe post something.

The downside with that approach is that there are no "countermeasures" for neutrino detectors, since neutrinos pass through all normal matter like it isn't there (most of the time). I'm hard pressed to come up with any plausible ECM "notions" that would "confuse" detection akin to what you can do with the EM spectrum. Not saying it CAN'T be done, just that I can't fathom how it would be done.

Haven't thought of that... but even then, how much does neutrino radiation affect getting a target lock on something? For what I've seen neutrino sensors are another form of passive sensors (those that would detect something automatically at detection range), and as I understood it, getting a sensor lock involves using active sensors (and I assume those can be interfered with).

Military craft need big power plants to power weapons, screens and computers.
They need big computers to run big ECM programs.
They need to run big ECM programs to mask the blindingly bright sensor signature of their big power plants.
You're kind of building something of an ouroboros there (snake eating its own tail) in terms of baseline assumptions for game mechanical structure.

Hmm... I do see the over-engineering spiral of death you mention. However:
As I see it right now (and I know High Guard does it different) computers are not directly correlated to power plant rating. If they were, it would be a factor when determining required power plant letter for a ship (only J-Drive and M-Drive potential are). It's more of a tech level/size/price limitation, and less of a power one.

Actually, no.
Consider that gunners on space craft aren't exactly using iron sights on machine guns within Mk I Eyeball visual range.
When combat ranges are measured in fractions of a light second (!) ... everything is going to be "beyond visual range" for the gunnery crews.

I didn't interpret it as "aiming down the iron sights" either. But then, with the Gunnery skill being quite vague (TTB, pg 26):

Gunnery: The individual is skilled in the operation of gunnery mounted on board starships and spacecraft. The use of such weaponry is covered in the chapter on space combat. Defensive and offensive weapons are mounted on a variety of interplanetary and interstellar vessels. Gunnery skill qualifies an individual to operate such weaponry, and to be hired on a ship's crew with the title of gunner. Gunnery may also be used for similar weapons mounted on ATVs or air/rafts.

And then there's also the Gunner Interact program (TTB, pg 70)...

Gunner interact interfaces the expertise of the gunner in a specific turret to the hit probability of those lasers hitting the target. The expertise of the gunner becomes a positive DM to hit when using laser fire.

Which I interpreted as there being some sensor play involved for the gunner against a target.

 

[whulorigan]

The downside with that approach is that there are no "countermeasures" for neutrino detectors, since neutrinos pass through all normal matter like it isn't there (most of the time). I'm hard pressed to come up with any plausible ECM "notions" that would "confuse" detection akin to what you can do with the EM spectrum. Not saying it CAN'T be done, just that I can't fathom how it would be done.

The only bit of handwavium I might be able to come up with might be to suggest something that is a spin-off of either Nuclear Damper or Meson Screen technology - i.e. technology that manipulates the Weak Nuclear Force. Neutrinos are usually produced as a by-product in Weak Nuclear interactions - perhaps a screen or field of some sort could be created that induces a particle transmutation reaction in which neutrinos are "reactants" in a process producing another subatomic particle via an induced Weak Interaction, wherein the product particle is easily trapped by more conventional (i.e. electromagnetic) means.

 

[Spinward Flow]

I like it, thanks! I'll definitely look more into it, then maybe post something.

Haven't thought of that... but even then, how much does neutrino radiation affect getting a target lock on something? For what I've seen neutrino sensors are another form of passive sensors (those that would detect something automatically at detection range), and as I understood it, getting a sensor lock involves using active sensors (and I assume those can be interfered with).

You're conflating 2 different things which have very different (even if related) applications.

Detection is one thing (step 1).
Firing solutions are another (step 2).

Think about all of those WWII submarine movies that were so wonderfully dramatic.

First the sonar operator reports a contact ("conn, sonar, contact bearing {insert numbers here} depth {more numbers}, heading {more numbers} speed {number} knots").
The once detected, the sonar operator begins tracking the contact, monitoring it so it doesn't get "lost" and so command knows "what's out there" and what the contact is doing.

The skipper "responds" to the contact, either by changing course and speed to intercept ... or by maneuvering away/around it to not alert the contact to the presence of the submarine.

Second, the submarine gets maneuvered into a position where weapons can be brought to bear ("firing solution light, sir!") and the skipper then makes the decision on timing of when to shoot weapons at the target ("fire tubes {number(s)}").

Parsing that for Traveller space combat purposes, the sensor operation and tracking work is done by the Navigator.
The target solution and "ready to fire" work is done by the Gunnery crew.
They're similar tasks, but done for very different purposes.

Hmm... I do see the over-engineering spiral of death you mention. However:
As I see it right now (and I know High Guard does it different) computers are not directly correlated to power plant rating. If they were, it would be a factor when determining required power plant letter for a ship (only J-Drive and M-Drive potential are). It's more of a tech level/size/price limitation, and less of a power one.

Computers of model/3+ consume EPs (1-12, depending on model number), meaning that power plants need to be "bigger" in order to generate sufficient excess power for the computer over and above what is needed for maneuver agility (another concept that LBB2 design and combat sequences doesn't have yet).

Weapons and screens (except for missiles and sandcasters) consume EP as well, meaning that power plants need to be "bigger" yet again in order to power these energy hungry systems.

The 1000 ton Crysanthemum-class Destroyer Escort (LBB S9, p14) and the follow on 1000 ton Fer-de-Lance-class Destroyer Escort (LBB S9, p15) both have Pn=9 (EP=90) power plants in them.

The 3000 ton Destroyer-class (LBB S9, p16) has a Pn=B (EP=330) to power a 50 ton particle accelerator bay weapon, 8x triple laser turrets, a nuclear dampener screen (code: 4), a meson screen (code: 2), a model/9fib computer ... and sufficient EPs left over to power the 6G maneuver drive @ Agility=6 for combat.

For combat oriented craft featured in LBB S9 built using LBB5.80 High Guard ... Pn=9-A is pretty common ... from 1000 tons all the way up to 500,000 tons.

Things get even wonkier for small craft, because of their small tonnage but enormous (relative) fraction of power that needs to go to computer+energy consuming weapon systems.

In my own Pondering Starship Evolution thread, starting at post #786 ... I've got a 25 ton medium fighter (decoy!) design that uses a LBB2.81 standard Power Plant-C drive, generating EP=6 ... adapted from a 25 ton Jolly Boat "shuttle" concept that (originally) used a Power Plant-A drive (hence the "decoy" designation). The Fighter Decoy design needs to spend EP=1.5 to reach Agility=6 (without external loading), another EP=1-2 on the computer model/3 or 4 (depending on TL of construction) and another EP=3-2 on laser weaponry (either triple pulse lasers or dual beam lasers). Total power demand for the TL=9-A options ... EP=5.5 in combat (without external loads attached). Total power generation from Power Plant-C drive ... EP=6.

So in a USP code block, what would the Pn for such a craft be?

• 6 / 0.25 = 24
• Pn code: Q

The Pn "gets that high" because it's generating EP=6 inside a 25 ton hull.
Needless to say, this is a mathematical edge case that the LBB2.81/TTB starship construction paradigm wasn't exactly "built" to handle, so all kinds of things break down and fall apart.

I didn't interpret it as "aiming down the iron sights" either. But then, with the Gunnery skill being quite vague (TTB, pg 26):
And then there's also the Gunner Interact program (TTB, pg 70)...
Which I interpreted as there being some sensor play involved for the gunner against a target.

That's a kind of cart before the horse interpretation, methinks.
The Gunner Interact "allows" the gunner's skill level to "matter" in the To Hit rolls. Without the Gunner Interact program, the computer is doing ALL of the work to engage ... and the gunner's skill level means nothing.

1. Designate target for the computer
2. Authorize computer to fire on target
3. Computer selects timing to fire weaponry on target

Without the Gunner Interact program, the gunner is just there to give the weapon automation permission to fire ("mother, may I?") so as to preserve the "man in the loop" factor.

With the Gunner Interact program, the gunnery crew "has more input" into the firing solutions so there's more of a blending of automation assist and crew skill factors going on. The gunnery crew aren't just "giving permission" to the computers to engage, the gunnery crew are "helping" (with their experience and skill) to choose how to "lead" the target so that shots fired will actually hit, "walking fire onto target" style. It's not a "manual override" situation (with zero automation assist!).

Also, consider that in LBB2.81, p30/TTB, p74 space combat, there are range penalties to accuracy when engaging with weapons beyond certain distances.

• -2 DM starting at 0.833 light seconds (2500mm)
• -5 DM starting at 1.667 light seconds (5000mm)

Those ranges do not "align" with the listed detection ranges of 0.5 light seconds (1500mm), 2 light seconds (6000mm) and 3 light seconds (9000mm) in either book, so trying to conflate sensor detection ranges with gunnery "ranges" is an error of the first order (because they're not the same thing).

 

[mike wightman]

I would do everything possible to distill a ship's sensor signatures into numbers that can be added to their data sheet.

So a ship has an active signature based on size, configuration and any active stealth hull design/coating.

Detection depends on signature, range, and computer/TL/sensor model (and PC skill) depending on how you do things

Inside a certain range detection is automatic, beyond this is the range at which the sensor operator must make a check.

 

[kilemall]

Re: gunner interaction, HG81 says skills for warships are assumed to be 2, including gunners. Needs Gunnery-4 to get a +1, arguably Gunnery-1 should get -1.

I look at computer level as assuming increased levels of Predict/Evade/Gunner Interact so already accounted for.

I disagree on the conflation critique, better to say detection is easier than target solution but both are about using sensors to increase data on target to the point of accurate analysis /weapons use.

The rest is referee view on skill definition.

 

[Vido]

Parsing that for Traveller space combat purposes, the sensor operation and tracking work is done by the Navigator.
The target solution and "ready to fire" work is done by the Gunnery crew.
They're similar tasks, but done for very different purposes.

Detection depends on signature, range, and computer/TL/sensor model depending on how you do things

Inside a certain range detection is automatic, beyond this is the range at which the sensor operator must make a check.

detection is easier than target solution but both are about using sensors to increase data on target to the point of accurate analysis /weapons use.

Let me see if I can synthesize what's going on, to see whether I'm actually getting it.

• Detection concerns the navigators. It involves analyzing sensor data in order to actually notice things around the ship, tracking them, and extracting further information from them (distance, trajectory, size...) with detailed scans. Detection is automatic at a certain range (calculated from computer model number) but might involve a throw past that.
  • DMs are applicable for hull size, power plant, M-Drive acceleration, Navigation skill (maybe Electronics minus 1 as well), or programs such as Detect or ECM/ECCM.
• Targeting concerns the gunners. It involves controlling the weaponry of the ship in order to bring fire effectively upon a target when desired. Targeting is not possible without prior detection. To determine whether a firing solution is effective, a throw is required (which is the to-hit throw in space combat!).
  • DMs are applicable for programs such as Predict, Gunner Interact, Auto/Evade or Maneuver/Evade, Pilot or Gunnery skill (if appropriate programs are used), range, or obscuring sand.