Realistic Sensor Rules

[CRMcNeill]

I've never really liked how the RAW handles Sensors, for a variety of reasons:

-Makes no distinction between sizes of objects, or of sensor profiles.

-Doesn't take account the nature of passive sensors, specifically that they can detect active signals (sensors, communications and fire control) at much greater ranges.


I have some ideas, not in any particular order at this point, but here we go...

1). A ship should have a sensor signature equal to its Hull dice, and that value is added to the Sensor roll to detect / identify the ship. Active shields are also added to the Hull dice, as well.

2). A ship's sensor signature can be modified based on the hull's shape (ships with a less angular profile, such as an MC80 cruiser when compared to an ISD) will have a reduced profile (-1D), while other ships that have a size out of proportion to their Hull (such as a space transport with a large size but relatively weak Hull) would have an increased profile (+1D).

3). IRL, sensors do not simply detect out to a given range, then stop working. There is a gradual fall off of effectiveness as range increases, and the rules should reflect that.

I have some other thoughts, but its late at night, and I'd like to work up to this.

Thoughts?
_________________
"No set of rules can cover every situation. It's expected that you will make up new rules to suit the needs of your game." - The Star Wars Roleplaying Game, 2R&E, pg. 69, WEG, 1996.

The CRMcNeill Stat/Rule Index

[atgxtg]

Some of us messed around with sensor rules in the past.

Some things we did:

1) Sensor difficulty increased with range. Instead of the flat drop off. One method was to set the base difficulty for detection equal to the range. Another way to treat the listed ranges as short, and include medium (2x range +5 difficulty). and long (X3 range, +10 difficulty), and even allowing this to continue beyond long at +5 difficulty per multiple.

2) Giving each ship a signature rating that gets added to detection attempts. We based this on the ships size, rather than it's hull rating, since a small ship can have a higher hull (i.e. X-Wing compared to a YT-1300). I think it was alog function, with +5 per multiple of ten. Or the ships SPACE speed (all that thrust means a lot of energy).

The nice thing about a flat add as opposed to extra dice is that it is easier for the GM to keep things secret. The PCs can get a clue as to the existence of or size of a target by seeing (or hearing) the extra dice being rolled.

[CRMcNeill]

But length isn't the best indicator either. I figure Hull dice is the easiest since it is already in Dice form. To justify it, I would say that, whether the Hull dice reflects increased mass an armor or increased tech systems, it increases the ship's sensor signature.
_________________
"No set of rules can cover every situation. It's expected that you will make up new rules to suit the needs of your game." - The Star Wars Roleplaying Game, 2R&E, pg. 69, WEG, 1996.

The CRMcNeill Stat/Rule Index

[vanir]

IRL sensors don't exactly fall off gradually. The thing about sensors, eg. microwave radar sets is they're extremely conditional, these conditions are extremely varied, and most of the "detection" is in fact the processing capability of the set to interpret signals among signal noise. So that, for example, a set which detects a fighter sized object (say, 10 sq.m. radar signature), at 100km in a frontal aspect directly ahead (ie. moving towards each other), may detect only at 50km in a rear aspect (ie. when the target is moving away from you), then 80% of this gimballed in differential attitudes pointed away from signal noise, 60% pointed towards signal noise, 40% passing by any close reflective bodies (eg. at low altitude) due to the need to filter additional lobe echo (your own, surplus, extraneous radar emissions bouncing back and mixing into the signal noise in addition to the direct bounced signal transmission), and on top of this there's the fact locking him up for accurate weapons control data needs a strong, broadband kind of contact so further reduce best possible ranges by 80% again across the board there.

So your modern high tech fighter radar with an advertised range of 100km/10sq.m. turns into around 20km to paint a fighter sized target you're chasing on the deck if he's moving away from you and you're roaming around like an eagle looking for him. 16km if you actually want to fire a missile at him without pit bulling it. You'll probably see him with your eyes whilst your radar still says nothing but canyons and trees down there. Partly why they have IRST and EOS systems (electroptical) sensor enhancements in the latest fighters (Russians have been doing that since the 80s, mostly because their radars were never as good as the Americans).

On top of that you've got simple, basic rules modern fighter pilots are trained in (in the major powers, talking about pilot training in Russia or the US, not Iran or Pakistan), to help defeat radar acquisitions and locks. Notching is the main one for doppler radars, which is the universal kind (ie. lookdown/shootdown type). It's actually the processor that allows lookdown/shootdown rather than the transceiver, it filters signals that don't move in relation to the aircraft, so ground clutter and clouds, stuff like that gets filtered out, whilst other aircraft show up. So what you do is when you get a RWR horn go off, turn the plane perpendicular to the e/a (this is a Russian technique for defeating NATO radar locks), the doppler thinks you're ground clutter and you disappear off the screen.
Flying techniques like this are a form of ECM, so are hardware countermeasures like chaff, flares and jamming equipment (these can be extremely sophisticated). Manufacturers of radar sets try to build in counter-countermeasures (ECCM) to preserve signal locks in combat situations.

The Russian approach in the MiG Foxbat interceptor was to use an extremely powerful set that can literally "burn through" any airborne attempt to jam it. It's a high powered fricken Maser in that thing, known for literally frying rabbits at hundreds of metres during ground tests. In addition it uses multiple frequency signal transmission, piggy-backing signals so that trying to jam it is like trying to counsel someone with multiple personalities: fix one personality's problems and one of their other personalities still has problems and puts a horse's head in your bed. Then on top of that it doesn't use doppler so you can't notch it or try to trick its processor into thinking you're not an enemy. This reduces its lookdown capability but the Russians built it to intercept mid-high altitude targets so it didn't matter, ground clutter was never an issue. And it uses old valves rather than solid state electronics so there's no way to blow the rig on feedback or jamming noise (not even an EF-111 Raven will trouble this radar set or break its lock). End result: very sturdy ECCM. Interestingly, actual detect range for all that power is pretty low, processor dependent and we're talking 1970 technology here so it's only about 50km on a good day.

Because the range thing is so conditional.

There are a great many factors which can be incorporated into a "more accurate" rendition of fighter style sensor systems.

My advice is to quantify each sensor type. How does this particular sensor system work? The Electroptical window in the nose of an X-Wing? Use Russian MiG/Sukhoi EOS guidelines (I actually have the military flight manual for the Su-27SK in print, but general information can be found easily on the web).
Is it a microwave type transceiver system? Does it filter signals for clutter?
Wookieepedia mentions tachyon antennae, presumably these are emitted by ion engines and hyperdrives, or perhaps the power cores of starships.

I'd say design some types of sensor sets: EOS, Transceiver, Antennae, and then draw up some conditions and limitations for each. Then you simply decide which ones are on which starships and at which power.

For example, I rule fairly simple sensor systems are fitted to TIE to reduce weight and complexity (production cost), where sensors on a Z-95 are older and fairly low powered, but also a more comprehensive suite. So that a Z-95 has better ECM/ECCM functionality (which I translate into ad hoc difficulties during starship combat sensor-lock, which is part of the combat round sequence in our game and necessary to fire weapons at range greater than short). So even though the TIE has more range listed on his sensors, the Z-95 actually has better sensor performance over a wide variety of conditions than a TIE. The TIE is only good in a fairly straight forward, simple fighter scenario, so it encourages my starfighter pilot PCs to use their imagination during combat and try to really dictate the combat environment into their strengths and out of enemy strengths.

Better tailoring your gaming sensors system can really help with this. It's a good idea.

[CRMcNeill]

That sounds like a bit more work than I feel like putting into it at the moment. Generic rules for changing sensor profile based on target change would be a good optional rule, but I much prefer a system that doesn't require a mass re-edit of all existing stats.
_________________
"No set of rules can cover every situation. It's expected that you will make up new rules to suit the needs of your game." - The Star Wars Roleplaying Game, 2R&E, pg. 69, WEG, 1996.

The CRMcNeill Stat/Rule Index

[cheshire]

Well... ya asked for realism.

Though, yeah, as fascinating as that really is, I wouldn't want to be the one to put it into a game mechanic.
_________________
__________________________________
Before we take any of this too seriously, just remember that in the middle episode a little rubber puppet moves a spaceship with his mind.

[CRMcNeill]

Exactly. IMO, the ideal house rule is one that either fits seamlessly with existing RAW and stats, or at worst requires simple math to generate the appropriate numbers.
_________________
"No set of rules can cover every situation. It's expected that you will make up new rules to suit the needs of your game." - The Star Wars Roleplaying Game, 2R&E, pg. 69, WEG, 1996.

The CRMcNeill Stat/Rule Index

[atgxtg]

[cheshire]

Interesting point about hulls. I mean, a Blackbird is not going to have the same signature as an F16, even if they were just as sturdy as one another.
_________________
__________________________________
Before we take any of this too seriously, just remember that in the middle episode a little rubber puppet moves a spaceship with his mind.

[CRMcNeill]

For power output, I would use the Speed dice codes from the 1E stats and add them to the Hull dice, then apply a modifier depending on which speed class the ship is moving. As far as fixed values versus dice, my understanding is that even a slight change in viewing aspect can affect the strength of signal return, as hull design features will return differing signal returns depending on the viewing angle. The larger a ship is, the more complicated that sensor profile becomes. As such, dice values would be a better reflection of that random nature.
_________________
"No set of rules can cover every situation. It's expected that you will make up new rules to suit the needs of your game." - The Star Wars Roleplaying Game, 2R&E, pg. 69, WEG, 1996.

The CRMcNeill Stat/Rule Index

[CRMcNeill]

[atgxtg]

[CRMcNeill]

But nowadays, a GM can have a dice roller on his laptop or his cellphone. If the sound is turned off, the players won't even know you made a roll, never mind how big of one.
_________________
"No set of rules can cover every situation. It's expected that you will make up new rules to suit the needs of your game." - The Star Wars Roleplaying Game, 2R&E, pg. 69, WEG, 1996.

The CRMcNeill Stat/Rule Index

[Raven Redstar]

Good point. Or the GM can roll dice before the game to avoid those. Or just use the rule of averages and do 3.5 x die code + pips. It's pretty quick. Or just round up or down to 3x or 4x depending on the size or whatever. Just thinking of ways to be stealthy is all.
_________________
RR
________________________________________________________________

[atgxtg]