Special Supplement 4: Sensors

[robject]

Three thoughts based on this discussion's ramblings. No, four.

* Doesn't passive sensing make more sense as a "non-task"? That is, the player never has to say "turn on passive sensors and do a passive sensor sweep!" Doesn't it make more sense to have them always listening, so the referee can let the players know when there's a blip? "The EMS array has gone 'blip' about 3,000 times since you entered the system. Thirty of those blips are within 1 million km of the ship."

* Neat use of Forward Observer

* Re-habilitate "Battle Rider" - it's a cool name

* Don, is there any help we can give you for the Droyne book?

 

[Supplement Four]

* Doesn't passive sensing make more sense as a "non-task"? That is, the player never has to say "turn on passive sensors and do a passive sensor sweep!" Doesn't it make more sense to have them always listening, so the referee can let the players know when there's a blip? "The EMS array has gone 'blip' about 3,000 times since you entered the system. Thirty of those blips are within 1 million km of the ship."

The way I handled it with these rules (and I see that T5 followed in my footsteps, using the same idea) is that passives will detect a bogey, but the sensor roll represents the sensor operator interpreting the data.

In other words, the passives will tell you to look at something, but it takes a sensor throw to get details.

Look at POST 6 of my rules at the beginning of this thread, where it says....

In actuality, ship's sensors (Passives) are always considered scanning. The Detection Throw represents the sensor operator's efforts in interpreting that data.

* Neat use of Forward Observer

I agree. I should update POST 7 to accommodate it.

 

[kilemall]

This is very close to what I have going on with my sensor rules, except that I am throwing in three states a detection target may be in- stealth, passive and active.

Stealth involves shutting everything down, operating on capacitor power, not even full passives but just low power ones like optical, weapons uncharged and retracted, a life support room to retreat to but in the bowels of the ship, etc.

Such a ship is showing as much absolute nothing it can (without achieving ambient space temperature), but as a result is also near blind, difficult to even pick up an active scan or lock on, so it can be surprised and effectively ambushed in return. Reactor restart is going to take minutes, and will be ugly under fire. High reward high risk.

Otherwise, similar vein and concepts even if the ranges rolls and minutiae are different. I applaud, of course.

 

[Supplement Four]

This is very close to what I have going on with my sensor rules, except that I am throwing in three states a detection target may be in- stealth, passive and active.

Stealth involves shutting everything down, operating on capacitor power, not even full passives but just low power ones like optical, weapons uncharged and retracted, a life support room to retreat to but in the bowels of the ship, etc.

Stealth is covered in these rules, too. I call it "silent running".

Passive and Active sensor packages are covered as well.

I applaud, of course.

Thanks!

 

[kilemall]

Ah yes the line about bogey silent running, missed that.

I have a thorough description of what constitutes each state, stealth is pretty rough sledding and relies on a lot of capacitor add-on rules to operate for any length of time (think U-boats in spaaaaaaace).

One of my goals is to allow a chance of slipping a stealth lander onto a planet without detection, so I don't have quite the auto-detect up close that the CT rules or your modification does.

Although I also make it harder for some situations in that I amp up the starport as a detection vessel all it's own, with A and B starports having military grade sensors and C with BSPs by your lingo.

By the time you get to D starports, it's pretty much orbital radar and transponders. They will be able to log where and when your pirate SOS call came in and send out salvage tugs afterwards to satisfy the bank loan people as to your ship's fate, so that's nice.

The other point is that the stealth ship detection capability is impaired greatly to achieve stealth. Did you have that in there?

 

[pendragonman]

Of course auto detect by the equipment does not imply that the operator noticed the detection.

Quiet system, rarely anything to detect...I need to use the head...then auto detect kicks in and mister sensor operator is out of the room...

 

[Supplement Four]

Of course auto detect by the equipment does not imply that the operator noticed the detection.

Quiet system, rarely anything to detect...I need to use the head...then auto detect kicks in and mister sensor operator is out of the room...

The way I pulled in player interaction is that your passive sensors are always considered "scanning", of course. When something is detected, it's a bogey. The Sensor Operator still needs to interpret the data, which is the sensor ops roll (roll Computer Number or less). Modifiers may apply.

So, the Navigator (the main sensor operator) hears a ping, checks the panel, then interprets the data--how well he does on the data is determined by the roll. If he fails it, the Ref should give him wrong info from his reading.

From time to time, the GM should have passives pick up bogeys that are really nothing--hydrogen clouds that are more dense than normal, sunspots, things like that. False readings. So, that players realize that bogey detected by passives is not necessarily another ship.

 

[BlackBat242]

Of course auto detect by the equipment does not imply that the operator noticed the detection.

Quiet system, rarely anything to detect...I need to use the head...then auto detect kicks in and mister sensor operator is out of the room...

And when he returns the "detection alert" light is flashing red (or a fashionable shade of mauve) - which it will continue to do until he hits the "clear alerts" button.

 

[kilemall]

The way I pulled in player interaction is that your passive sensors are always considered "scanning", of course. When something is detected, it's a bogey. The Sensor Operator still needs to interpret the data, which is the sensor ops roll (roll Computer Number or less). Modifiers may apply.

So, the Navigator (the main sensor operator) hears a ping, checks the panel, then interprets the data--how well he does on the data is determined by the roll. If he fails it, the Ref should give him wrong info from his reading.

From time to time, the GM should have passives pick up bogeys that are really nothing--hydrogen clouds that are more dense than normal, sunspots, things like that. False readings. So, that players realize that bogey detected by passives is not necessarily another ship.

Actually, I'm going to be doing a LOT more 'navigational hazard' stuff, solar flares, uncharted rocks/meteor storms, massive stellar events, maybe even the occasional ship debris or undeclared mine warfare event.

Everything hurts a lot more hitting it at .02C.

Which gives each of the potential sensor ops guys on CT skill sets something specialized to do- Navigation picks up on the rocks/storms, Gunnery is better at the ships, and Survey for planetary sensor work. Electronics would be the JOAT of the sensor set, probably -1 for each type.

 

[pendragonman]

And when he returns the "detection alert" light is flashing red (or a fashionable shade of mauve) - which it will continue to do until he hits the "clear alerts" button.

Yep, and it may have been missed long enough that the inbound vampires are almost there.

Autodetect ranges imply awful close...

 

[Supplement Four]

Which gives each of the potential sensor ops guys on CT skill sets something specialized to do- Navigation picks up on the rocks/storms, Gunnery is better at the ships, and Survey for planetary sensor work. Electronics would be the JOAT of the sensor set, probably -1 for each type.

I like the idea of more navigational hazards. Maybe not realistic, but space opera and fun.

I'd caution getting too specialized with CT skills, though. That goes against the game's design. CT characters have few skills, and therefore, those skills should have broad interpretations.

In these sensor rules, I reference a lot of skills that can be used as the "sensor skill". Navigation is the primary "sensor ops" skill. It "includes" sensor ops and can be used as Sensor Ops at the same level.

Remember that, if using the CT rules as written, more than a few characters will come out of character generation with just a skill or two. It's not uncommon to have two skills (then use the Experience rules to boost up a skill or two), and that's it.

If skills are too specialized, then you'll have characters who can do only one thing and nothing else.

If you go with broad interpretations, your characters are more useful and realistic as they can apply their skills to many types of situations.





Have a problem in engineering? Obviously, the Engineering skill applies. But, if it's a mechanical problem, then Mechanical skill can be used instead. If it's an Electrical problem, then Electronics can be used instead. If it's a problem with the Engineering control software, then Computer or Engineering can be used.

And, many skills in CT have no penalty if a task is attempted without skill (or the penalty is that the character doesn't get a skill bonus--where even a +1 DM is a lot in the standard CT 2D system).

The engineering problem takes a 10+ throw to fix, with +2 per Engineering level. But, a character without skill can attempt to fix it by just throwing 2D and getting 10+.

 

[kilemall]

Im not suggesting that ONLY the Navigation guy can pick up the rocks, only that he's better at it given his specialization in using the sensors for that purpose.

 

[kilemall]

Got to thinking about this thread and the missing sensors, so proposing two additional options plus commentary on a possible effect/EW mechanism.

Acoustic Sensor- Otherwise known as SONAR, this can also cover atmospheric acoustic arrays for picking up supersonic + craft.

Of course in space these will not be of much use, but in planetary atmo and very much in liquid/water situations (SDB and sub hunts) they would be a primary instrument.

They would also be desirable as standard kit on small craft as a security perimeter/indirect passive ranging system.

An interesting thought came to mind about acoustics- in a dense particle/plasma field in space, could sound propagate as though it were an atmosphere or liquid? If so, maybe one could replicate a space version of sub hunts.

Perhaps Admiral Kirk missed a trick in the Mutara Nebula- or maybe Fed cruisers don't come with acoustic sensors!

May be a BIG player in gas giant fights.

Magnetic sensors- One would assume that the EM sensors would cover this spectra, but I think it rates a specific mention along with the gamma and other EM emissions.

I would anticipate that it would be largely a short range detection mechanism, but would be useful in SDB/sub hunts (think MAD on patrol planes), and detecting the hulls of otherwise passive/hidden ships with reactors off behind asteroids without being in direct LOS.

May be overlooked like acoustic sensors on major warships, but definitely standard issue for SDB planetary war and exploratory/scout/seeker rigs, for prospecting if nothing else.

Electrical systems may also be a detection issue at close range, to an extent the hull should shield a lot of the EMF emissions but may not be able to entirely especially for a civilian craft that has not gone through a regimen of testing and applying stealth equipment and procedures.

Finally, on countermeasures, consider the mass sensor/densitometer.

Hard to mask how much of a 'dent' a ship's mass makes on the local gravitic field.

Except.

We DO have equipment that messes with gravity, specifically anti-grav, ship grav plates, etc.

What effect would using such fields have on that type of sensor? Eliminate gravitic readings in the direction of anti-gravity? Cause it to go haywire (indicating anomalous and likely sentient interference, but maybe not)?

Then, throw in the repulsor defensive system, specifically designed to project a gravitic-based field to deflect/impact missiles.

Would aiming a repulsor at a ship with a mass sensor eliminate readable mass from the emitting ship? Or more interestingly cause 'negative mass' readings or gravity to be read coming 'from' the opposite direction?

A lot depends on what your view of gravitics and repulsors are actually doing.

 

[Supplement Four]

Although its not spelled out anywhere, but can easily be inferred by the rules, the Classic Traveller game seems to take that stance that Sensors are a moot point in most situations. It's very hard to hide in space, and therefore, just about every target should be known to any ship entering the system.

When situations arise where the GM wants to throw a "sensors" task at the players, he should tackle it like any other task throw in the game. Make up an appropriate throw and do it.

One could argue that the ship's computer is so augmented for this task that one need only make a 2D throw, no Computer skill needed, to make specialized sensor tasks.

I wrote these rules for people who want to focus more on sensors in the game--as an alternate rule. But, my opinion is that CT sensors are meant to something that is checked without a roll, and the GM simply gives the player the answer--like pulling information out of the library computer.

There are some "official" sensor rules, written for CT. Check the DGP book Grand Survey.

 

[kilemall]

My intent was not to go over a more intense die rolling regimen but work within the spirit of the OP to expand the list of sensors and spectra to create anomalies and roleplay options.

Yes my intended effect is more stealthy in the open then CT 'allows', I made that clear, but even within the frameworks of the published game there are areas where objects, particularly planets and large asteroids, can 'officially' have a masking effect in which the systems I am talking about adding on about would be paramount.

For instance the mass sensor in the missile supplement has a rule about asteroids masking ship mass at certain TLs.

Hoping to expand upon that here as the vast bulk of spectra one would want to deal with is in this excellent thread, however I can do that elsewhere.