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

Simple Sensor Rules for CT (work in progress)

(DM's APPROPRIATE TO SENSOR TASK ROLLS)


Let's open the floor now to you. I'll list what I think are appropriate DMs to the sensor rolls, and we can discuss them.


===============================================
DM's

+DM.....Sensor Ops skill (or Computer Model number--player's choice).

-2.....Target at 250,000 km or greater range (as with CT to-hit DM).

-5.....Target at 500,000 km or greater range (as with CT to-hit DM).

-3.....LADAR vs. sand from sandcaster (as with CT to-hit DM).

+2.....A Sensor Detection (Scan or Lock) was obtained on the object the previous turn (Sensor tasks are rolled every turn).

+/-DM...Target Size DM from Book 5 (typically, this will be a -1DM because most vessels range from 100-1000 tons).

-3.....If target employs EM masking.

+2.....If target used Active sensors during it's previous turn.

-2.....If target is "coasting" (not using the M-Drive).

-4.....If target is "running silent" (cold mode with all systems powered down and power plant operating at minimum levels).

+1....If target's bow facing sensing ship when target is using the M-Drive.

+0....If target's port, starboard, dorsal, or keel is facing sensing ship when target is using it's M-Drive (this is the "default" target profile for these sensing rolls).

+2....If target's aft is facing sensing ship when target is using it's M-Drive.

+2....If target is being "handed off" from another sensor system on the ship--or from a friendly vessel (A ship may want to cease using it's Active sensor, for instance, passing off a lock made with the Active sensor to the Passive Array).

+DM.....Radar Cross-Section. This is based on Book 5 Hull Configuration. +1DM for Needle. +1DM for Wedge. +1DM for Cylinder. +2DM for Box. +0DM for Sphere. +1DM for Dome/Disc. +2DM for Close Structure. +3DM for Slab.


===============================================
SPECIAL NOTE

The TL of the vessel can be used in place of the governor attribute on the UGM sensor task roll.

For example, a character with EDU-12 and Navigator-1 attempts a sensor roll. If on a TL 13+ vessel, the navigator will want to use the ship's TL in place of his EDU-12 when governing the roll.

Likewise, the ship's Computer Model number can be used in place of Sensor Ops skill on sensor tasks.

Taking our navigator above, his expertise with sensors is Sensor Ops-0 (which is Navigation-1 minus one level). This navigator will probably want to use the ship's compuer in place of his own skill when reading sensor data (making sensor tasks)
 
(DM's APPROPRIATE TO SENSOR TASK ROLLS)


Let's open the floor now to you. I'll list what I think are appropriate DMs to the sensor rolls, and we can discuss them.


===============================================
DM's

+DM.....Sensor Ops skill (or Computer Model number--player's choice).

-2.....Target at 250,000 km or greater range (as with CT to-hit DM).

-5.....Target at 500,000 km or greater range (as with CT to-hit DM).

-3.....LADAR vs. sand from sandcaster (as with CT to-hit DM).

+2.....A Sensor Detection (Scan or Lock) was obtained on the object the previous turn (Sensor tasks are rolled every turn).

+/-DM...Target Size DM from Book 5 (typically, this will be a -1DM because most vessels range from 100-1000 tons).

-3.....If target employs EM masking.

+2.....If target used Active sensors during it's previous turn.

-2.....If target is "coasting" (not using the M-Drive).

-4.....If target is "running silent" (cold mode with all systems powered down and power plant operating at minimum levels).

+1....If target's bow facing sensing ship when target is using the M-Drive.

+0....If target's port, starboard, dorsal, or keel is facing sensing ship when target is using it's M-Drive (this is the "default" target profile for these sensing rolls).

+2....If target's aft is facing sensing ship when target is using it's M-Drive.

+2....If target is being "handed off" from another sensor system on the ship--or from a friendly vessel (A ship may want to cease using it's Active sensor, for instance, passing off a lock made with the Active sensor to the Passive Array).

+DM.....Radar Cross-Section. This is based on Book 5 Hull Configuration. +1DM for Needle. +1DM for Wedge. +1DM for Cylinder. +2DM for Box. +0DM for Sphere. +1DM for Dome/Disc. +2DM for Close Structure. +3DM for Slab.


===============================================
SPECIAL NOTE

The TL of the vessel can be used in place of the governor attribute on the UGM sensor task roll.

For example, a character with EDU-12 and Navigator-1 attempts a sensor roll. If on a TL 13+ vessel, the navigator will want to use the ship's TL in place of his EDU-12 when governing the roll.

Likewise, the ship's Computer Model number can be used in place of Sensor Ops skill on sensor tasks.

Taking our navigator above, his expertise with sensors is Sensor Ops-0 (which is Navigation-1 minus one level). This navigator will probably want to use the ship's compuer in place of his own skill when reading sensor data (making sensor tasks)
 
(OTHER IDEAS AND NOTES)


-- I don't want to bog the game down with too many DMs, and I'm wondering if I already have too many above. Are they all needed?


-- A ship must conduct a Sensor Scan to detect a bogey before a Sensor Lock can be made on that target. Sensor Locks are required before any ship's weapons can be fired at the enemy vessel.


-- The first thing done on any phase of space combat are the sensor rolls (followed by movement, then laser fire, then return laser fire, etc. as per the official combat sequence).


-- The Navigation program is required to operate sensors? Because Computer space is so limited on most civilian ships, then maybe sensors are "built in" to the various maneuver programs? Maybe sensors are just a function of the ship's computer, but I'm thinking if the program is damaged, then sensor tasks are not possible...or possibly hindered?


-- The ship's Computer Model number is the total number of Sensor Locks the ship can maintain at any one time. (If so, then is the multi-target program useless when used with a Model 1?).


-- A ship is allowed a number of sensor scans equal to the ship's computer model number. So, civilian ships with Model 1 computers will have to take more time (two turns) to first scan then lock on a target. The Mercenary Cruiser can do 5!

But, if a ship does more than one sensor task (sweep) in a turn, it must forego the attack of one turret (because sensor sweeps and locks take time). So, the, the Merc Vessel could attempt 5 sensor locks if it wanted to, but 8 turrets. If all 5 sensor locks were attempted, only attacks from 3 turrets would be possible.


-- The sensor scan/lock task is performed every turn (maintaining a lock over 1000 seconds), but there is a bonus DM to the roll if a lock/scan was successful the previous round.


-- Jammers. I'm thinking that a sensor task is made normally when a ship wants to jam a target. The total of the roll becomes the target number that the jammed ship must overcome (on it's own sensor roll) to "punch through" the jamming.

Also--jamming can be used as a defensive measure to break target locks on your vessel. Ship's cannot attack you with weapons without a lock, and if you successfully jam them, they will loose their lock--buying you time as they forego an attack, instead trying to re-attempt the lock and push through the jamming.


================================================

OK, that's all I've got on this for now (that's what I came up with today).

Thoughts on any of this?
 
(OTHER IDEAS AND NOTES)


-- I don't want to bog the game down with too many DMs, and I'm wondering if I already have too many above. Are they all needed?


-- A ship must conduct a Sensor Scan to detect a bogey before a Sensor Lock can be made on that target. Sensor Locks are required before any ship's weapons can be fired at the enemy vessel.


-- The first thing done on any phase of space combat are the sensor rolls (followed by movement, then laser fire, then return laser fire, etc. as per the official combat sequence).


-- The Navigation program is required to operate sensors? Because Computer space is so limited on most civilian ships, then maybe sensors are "built in" to the various maneuver programs? Maybe sensors are just a function of the ship's computer, but I'm thinking if the program is damaged, then sensor tasks are not possible...or possibly hindered?


-- The ship's Computer Model number is the total number of Sensor Locks the ship can maintain at any one time. (If so, then is the multi-target program useless when used with a Model 1?).


-- A ship is allowed a number of sensor scans equal to the ship's computer model number. So, civilian ships with Model 1 computers will have to take more time (two turns) to first scan then lock on a target. The Mercenary Cruiser can do 5!

But, if a ship does more than one sensor task (sweep) in a turn, it must forego the attack of one turret (because sensor sweeps and locks take time). So, the, the Merc Vessel could attempt 5 sensor locks if it wanted to, but 8 turrets. If all 5 sensor locks were attempted, only attacks from 3 turrets would be possible.


-- The sensor scan/lock task is performed every turn (maintaining a lock over 1000 seconds), but there is a bonus DM to the roll if a lock/scan was successful the previous round.


-- Jammers. I'm thinking that a sensor task is made normally when a ship wants to jam a target. The total of the roll becomes the target number that the jammed ship must overcome (on it's own sensor roll) to "punch through" the jamming.

Also--jamming can be used as a defensive measure to break target locks on your vessel. Ship's cannot attack you with weapons without a lock, and if you successfully jam them, they will loose their lock--buying you time as they forego an attack, instead trying to re-attempt the lock and push through the jamming.


================================================

OK, that's all I've got on this for now (that's what I came up with today).

Thoughts on any of this?
 
I would like to compare notes with you on this, and today I will print this thread out and give it the real once over. This looks cool, and it does need to be done for sure.

I will post later on tonight with observations.
 
I would like to compare notes with you on this, and today I will print this thread out and give it the real once over. This looks cool, and it does need to be done for sure.

I will post later on tonight with observations.
 
Originally posted by WJP:
Active sensors are better suited to Sensor Locks than Passive sensors, and Active sensors typically provide more detail about a detected object than a Passive Lock will provide.
Click to expand...
I'm thinking there should be a +1DM or a +2DM when attempting a Sensor Lock with an Active sensor.

This will make Active sensors better at "Locking" onto a target than Passive sensors.


Likewise...should we provide a mirror DM for Passive sensors when attempting Passive Sensor Scans since Passive sensors are better suited to scans rather than locks?


DM
+2....If attempting a Sensor Lock with Active Sensors.

+1....If attempting a Sensor Scan with Passive Sensors.


Just an idea.
 
Originally posted by WJP:
Active sensors are better suited to Sensor Locks than Passive sensors, and Active sensors typically provide more detail about a detected object than a Passive Lock will provide.
Click to expand...
I'm thinking there should be a +1DM or a +2DM when attempting a Sensor Lock with an Active sensor.

This will make Active sensors better at "Locking" onto a target than Passive sensors.


Likewise...should we provide a mirror DM for Passive sensors when attempting Passive Sensor Scans since Passive sensors are better suited to scans rather than locks?


DM
+2....If attempting a Sensor Lock with Active Sensors.

+1....If attempting a Sensor Scan with Passive Sensors.


Just an idea.
 
(CUSTOMIZING THESE RULES...notes for the GM)


The GM's ability to choose the sensor quality for a starship's sensors (pick a difficulty level associated with sensor tasks) goes a long way towards the GM customizing sensors on ships to suit his tastes.


Although one of my goals in designing the rules was to use existing CT ship stats (the PowerPlant number...the Computer Model number) without having to implement other stats for a ship (many sensor rules use a "signature" number for a ship, for example, and I didn't want to have to go through all that in order to use these rules), a GM can, if he wants, easily modify these rules.

The first tool a GM has in modifying these rules to suit his game are the DMs to the sensor tasks.

A GM could, if he wanted, apply a different DM depending on what type of actual sensor was used.

I'm keeping these rules simple, to where it is not necessisary to know which actual sensor was used for detection (something in the Active Array detected....or something in the Passive Array detected...), but a GM could use DMs to differintiate between the various types of sensor.

For example, one of the DMs I listed above was a "-3DM when LADAR is used against a ship that is defended with sand from a sandcaster".

Since LADAR is basically a laser, I used the same DM that a Beam Laser has against sand.

Other DMs could be specified if a GM wants to get into the detail associated with specific types of sensors...

...Oh, you're using HRT? Well, that's got a -2DM required for 50,000 km and over....

...Oh, you're using passive EMS? Well, if the star is anywhere in the arc of the sensing unit, there's a -3DM applied to the roll....


Again, I'm not going to go into this kind of detail in these rules. But, if you want to go into that kind of customization in your game, and you don't mind the extra paperwork (keeping track of which ships have what type of sensors), then this system is easily customizable in that direction.


So, the first tool a GM has in customizing sensors for his game is SENSOR QUALITY: Picking the difficulty task associated with the sensor roll.

The second tool a GM has in customizing sensors for his game is to implement specific DMs for specific types of sensors--as I have discussed above.

The third tool a GM has in customizing sensors for his game is this...

Change the PP number for a given sensor (SENSOR POWER), or change he SENSOR SENSITIVITY for a given sensor (Computer Model number).

So, a Type A Free Trader, with a Type A Power Plant and Model 1bis computer *COULD* also have better sensors installed.

When making sensor scans, consider the PP to be Type C instead of the actual Type A PowerPlant (these would be high-powered sensors for this vessel).

Maybe the sensitivity for these upgraded sensors is 3 (instead of 1 associated with the Model 1 computer).

Again, what we're talking about here is bookkeeping. A GM interested in modifying these sensor rules this way would have to keep track of what type of sensors are available on different craft.

I never intended these rules to go into that kind of detail. I don't like that kind of bookeeping myself (but I sure as heck might put some unexpected sensors on a typical craft in my personal game as the point of an adventure...that would be only altering one ship--not many. I can deal with that bookkeeping.).

The point of all this being: If you're the type of GM that likes more detail in a game, then you can certainly customize these rules and get that kind of detail out of the sensor rolls.

You could even implement uncertain tasks (as is done in MT) where the GM rolls the exact same sensor roll as the player (but secretly). If the both rolls succeed, then the sensor roll is a smashing success. If one succeeds and one fails, then the GM will limit the info the player gained using the sensor task. And, if both fail, the GM can describe the little that the player learned form the roll--if anything.


Another idea is to implement a type of "task quality" system, where rolling the sensor roll exactly gives some data, but if the roll is succeeded by 2, better data is available. And, if the roll is suceeded by 4, more data than normal is described by the GM.


What I'm going to do is present these sensor rules in a simple format.

You've got two choices of sensor task to choose from: You'll roll either your Active Sensor or your Passive Sensors.

And, you'll roll either Sensor Scans or Sensor Locks.

And, if you know your ship's powerplant and model number...and the distance to the target vessel, you'll be able to make a sensor roll without ANY other DMs.

Those that want to get more detailed than this, though, can easily do so.
 
(CUSTOMIZING THESE RULES...notes for the GM)


The GM's ability to choose the sensor quality for a starship's sensors (pick a difficulty level associated with sensor tasks) goes a long way towards the GM customizing sensors on ships to suit his tastes.


Although one of my goals in designing the rules was to use existing CT ship stats (the PowerPlant number...the Computer Model number) without having to implement other stats for a ship (many sensor rules use a "signature" number for a ship, for example, and I didn't want to have to go through all that in order to use these rules), a GM can, if he wants, easily modify these rules.

The first tool a GM has in modifying these rules to suit his game are the DMs to the sensor tasks.

A GM could, if he wanted, apply a different DM depending on what type of actual sensor was used.

I'm keeping these rules simple, to where it is not necessisary to know which actual sensor was used for detection (something in the Active Array detected....or something in the Passive Array detected...), but a GM could use DMs to differintiate between the various types of sensor.

For example, one of the DMs I listed above was a "-3DM when LADAR is used against a ship that is defended with sand from a sandcaster".

Since LADAR is basically a laser, I used the same DM that a Beam Laser has against sand.

Other DMs could be specified if a GM wants to get into the detail associated with specific types of sensors...

...Oh, you're using HRT? Well, that's got a -2DM required for 50,000 km and over....

...Oh, you're using passive EMS? Well, if the star is anywhere in the arc of the sensing unit, there's a -3DM applied to the roll....


Again, I'm not going to go into this kind of detail in these rules. But, if you want to go into that kind of customization in your game, and you don't mind the extra paperwork (keeping track of which ships have what type of sensors), then this system is easily customizable in that direction.


So, the first tool a GM has in customizing sensors for his game is SENSOR QUALITY: Picking the difficulty task associated with the sensor roll.

The second tool a GM has in customizing sensors for his game is to implement specific DMs for specific types of sensors--as I have discussed above.

The third tool a GM has in customizing sensors for his game is this...

Change the PP number for a given sensor (SENSOR POWER), or change he SENSOR SENSITIVITY for a given sensor (Computer Model number).

So, a Type A Free Trader, with a Type A Power Plant and Model 1bis computer *COULD* also have better sensors installed.

When making sensor scans, consider the PP to be Type C instead of the actual Type A PowerPlant (these would be high-powered sensors for this vessel).

Maybe the sensitivity for these upgraded sensors is 3 (instead of 1 associated with the Model 1 computer).

Again, what we're talking about here is bookkeeping. A GM interested in modifying these sensor rules this way would have to keep track of what type of sensors are available on different craft.

I never intended these rules to go into that kind of detail. I don't like that kind of bookeeping myself (but I sure as heck might put some unexpected sensors on a typical craft in my personal game as the point of an adventure...that would be only altering one ship--not many. I can deal with that bookkeeping.).

The point of all this being: If you're the type of GM that likes more detail in a game, then you can certainly customize these rules and get that kind of detail out of the sensor rolls.

You could even implement uncertain tasks (as is done in MT) where the GM rolls the exact same sensor roll as the player (but secretly). If the both rolls succeed, then the sensor roll is a smashing success. If one succeeds and one fails, then the GM will limit the info the player gained using the sensor task. And, if both fail, the GM can describe the little that the player learned form the roll--if anything.


Another idea is to implement a type of "task quality" system, where rolling the sensor roll exactly gives some data, but if the roll is succeeded by 2, better data is available. And, if the roll is suceeded by 4, more data than normal is described by the GM.


What I'm going to do is present these sensor rules in a simple format.

You've got two choices of sensor task to choose from: You'll roll either your Active Sensor or your Passive Sensors.

And, you'll roll either Sensor Scans or Sensor Locks.

And, if you know your ship's powerplant and model number...and the distance to the target vessel, you'll be able to make a sensor roll without ANY other DMs.

Those that want to get more detailed than this, though, can easily do so.
 
BTW, this step will be very easy in starship combat.


Originally posted by WJP:
(SENSOR SENSITIVITY)


Each Array, whether Active or Passive, will have a sensitivty equal to the starship's computer model number.

The sensitivty of an Array denotes the number of Range Bands counted before a -1DM is applied to the sensor task roll.
Click to expand...
If you're using Range Bands in your starship combat encounter, then simply divide the number or Range Bands by the computer number of the sensing ship.

You can do the same thing if you're using a hex map or square grid (graph paper) to plot starship movement. Simply divide the number of hexes or squares by the computer number.


If you're not using a hex map or square grid, then you're probably using Range Bands to keep track of distances in a starship encounter. Either way, it's easy to find the Range DM as just mentioned.


If you're playing more of a loose game (as in High Guard), where specific range is not being counted (then you're probably not using the starship combat system in LBB2), but you can still use these sensor rules: Pick a distance to the enemy ship in km, divide by 10,000 km, then divide again by the computer number of the sensing ship. This will first convert the distance to Range Bands, then it will convert the Range Bands to a DM used to lower the sensor task.


My guess is, though, if you're using these sensor rules, you're using Range Bands to determine distance in a CT starship encounter.

Range Bands / Computer Number = DM to senor task.


You could, as well, use these sensor rules with a different starship combat system for Traveller--you'll just have to adjust the math a little.

Computer Number x 10,000 km is how far the sensor can detect before a -1DM is required on the task roll. If you're using Range Bands that are 30,000 km, then you'll have to adjust your math accordingly.
 
BTW, this step will be very easy in starship combat.


Originally posted by WJP:
(SENSOR SENSITIVITY)


Each Array, whether Active or Passive, will have a sensitivty equal to the starship's computer model number.

The sensitivty of an Array denotes the number of Range Bands counted before a -1DM is applied to the sensor task roll.
Click to expand...
If you're using Range Bands in your starship combat encounter, then simply divide the number or Range Bands by the computer number of the sensing ship.

You can do the same thing if you're using a hex map or square grid (graph paper) to plot starship movement. Simply divide the number of hexes or squares by the computer number.


If you're not using a hex map or square grid, then you're probably using Range Bands to keep track of distances in a starship encounter. Either way, it's easy to find the Range DM as just mentioned.


If you're playing more of a loose game (as in High Guard), where specific range is not being counted (then you're probably not using the starship combat system in LBB2), but you can still use these sensor rules: Pick a distance to the enemy ship in km, divide by 10,000 km, then divide again by the computer number of the sensing ship. This will first convert the distance to Range Bands, then it will convert the Range Bands to a DM used to lower the sensor task.


My guess is, though, if you're using these sensor rules, you're using Range Bands to determine distance in a CT starship encounter.

Range Bands / Computer Number = DM to senor task.


You could, as well, use these sensor rules with a different starship combat system for Traveller--you'll just have to adjust the math a little.

Computer Number x 10,000 km is how far the sensor can detect before a -1DM is required on the task roll. If you're using Range Bands that are 30,000 km, then you'll have to adjust your math accordingly.
 
(Quick Example of using these rules)


TL 13 FREE TRADER
POWERPLANT: A
COMPUTER MODEL: 1

STANDARD PASSIVE ARRAY
FORMIDABLE ACTIVE ARRAY


===========================================

The GM wants to have a pirate corsair attack the player's Free Trader.

The GM knows the range of civilian craft is about 150,000 km. He makes a secret sensor detection roll to see if the players pick up the intruder yet--at 180,000 km.

The GM decides, since the passive sensors are always "on", and the navigator on the bridge of the ship will not always be focussed on the passive sensor readings, to do the roll just using the ship's TL as the governor stat and the ship's computer model number as the sensor ops skill.

Basically, if a detection is made, it will be a warning "beep" on the navigator's panel, which will draw the navigator's attention (and successive sensor rolls will be made using the Navigator's EDU and Sensor Ops skill level--at the player's option).


The GM uses the ship's Passive Sensor Array because (1) they have greater range (the task to use these sensors is easier than the task to use the Active Sensors shown above), and (2) the Passive's are always "on".

Since the Free Trader sports a model 1 computer, the penalty for range on any sensor task will always be the number of Range Bands between the Free Trader and any target.

So, your sensor roll is easy....


2D for 15+

(2D +10 -18 +1 for 8+)


Obviously, the corsair is out of sensor range for the Free Trader.
===========================================
 
(Quick Example of using these rules)


TL 13 FREE TRADER
POWERPLANT: A
COMPUTER MODEL: 1

STANDARD PASSIVE ARRAY
FORMIDABLE ACTIVE ARRAY


===========================================

The GM wants to have a pirate corsair attack the player's Free Trader.

The GM knows the range of civilian craft is about 150,000 km. He makes a secret sensor detection roll to see if the players pick up the intruder yet--at 180,000 km.

The GM decides, since the passive sensors are always "on", and the navigator on the bridge of the ship will not always be focussed on the passive sensor readings, to do the roll just using the ship's TL as the governor stat and the ship's computer model number as the sensor ops skill.

Basically, if a detection is made, it will be a warning "beep" on the navigator's panel, which will draw the navigator's attention (and successive sensor rolls will be made using the Navigator's EDU and Sensor Ops skill level--at the player's option).


The GM uses the ship's Passive Sensor Array because (1) they have greater range (the task to use these sensors is easier than the task to use the Active Sensors shown above), and (2) the Passive's are always "on".

Since the Free Trader sports a model 1 computer, the penalty for range on any sensor task will always be the number of Range Bands between the Free Trader and any target.

So, your sensor roll is easy....


2D for 15+

(2D +10 -18 +1 for 8+)


Obviously, the corsair is out of sensor range for the Free Trader.
===========================================
 
Since we see that 180,000 is 15+ on our sensor roll, it's easy to know where the max range of the sensor is.

With the Free Trader's Computer of Model 1, we know that every 10,000 km of range (closer) will increase the chance of detection.

Just by glancing at this, we instantly know...


170,000 = 2D for 14+
160,000 = 2D for 13+

150,000 = 2D for 12+ (The max range of this sensor)

140,000 = 2D for 11+ (14 Range Bands)
130,000 = 2D for 10+ (13 Range Bands)
120,000 = 2D for 9+ (12 Range Bands)
110,000 = 2D for 8+ (11 Range Bands)
100,000 = 2D for 7+ (10 Range Bands)

90,000 = 2D for 6+ (9 Range Bands)
80,000 = 2D for 5+ (8 Range Bands)
70,000 = 2D for 4+ (7 Range Bands)
60,000 = 2D for 3+ (6 Range Bands)

50,000 = 2D for 2+ (100% detection)


We see at a range of 5 Range Bands, the Free Trader will absoltuely detect any and all objects within 50,000 km around the ship (barring any other DMs to the sensor roll).
 
Since we see that 180,000 is 15+ on our sensor roll, it's easy to know where the max range of the sensor is.

With the Free Trader's Computer of Model 1, we know that every 10,000 km of range (closer) will increase the chance of detection.

Just by glancing at this, we instantly know...


170,000 = 2D for 14+
160,000 = 2D for 13+

150,000 = 2D for 12+ (The max range of this sensor)

140,000 = 2D for 11+ (14 Range Bands)
130,000 = 2D for 10+ (13 Range Bands)
120,000 = 2D for 9+ (12 Range Bands)
110,000 = 2D for 8+ (11 Range Bands)
100,000 = 2D for 7+ (10 Range Bands)

90,000 = 2D for 6+ (9 Range Bands)
80,000 = 2D for 5+ (8 Range Bands)
70,000 = 2D for 4+ (7 Range Bands)
60,000 = 2D for 3+ (6 Range Bands)

50,000 = 2D for 2+ (100% detection)


We see at a range of 5 Range Bands, the Free Trader will absoltuely detect any and all objects within 50,000 km around the ship (barring any other DMs to the sensor roll).
 
If you want to keep things really simple, you can forgo using any other modifiers to the sensor roll--just the sensor power (PP code), target range, and computer number were used above.

NOTE that I didn't use the UGM task roll on those numbers above.


If I were to use the UGM task roll on those tasks above (using the ship's TL as the governor stat), the tasks would be altered slightly to these....

(Note that this will increase range slightly and increase the range of 100% detection).

(TL 13 Free Trader)

170,000 = 2D for 12+
160,000 = 2D for 12+

150,000 = 2D for 12+ (The max range of this sensor)

140,000 = 2D for 10+ (14 Range Bands)
130,000 = 2D for 9+ (13 Range Bands)
120,000 = 2D for 8+ (12 Range Bands)
110,000 = 2D for 7+ (11 Range Bands)
100,000 = 2D for 6+ (10 Range Bands)

90,000 = 2D for 5+ (9 Range Bands)
80,000 = 2D for 4+ (8 Range Bands)
70,000 = 2D for 3+ (7 Range Bands)

60,000 = 2D for 2+ (6 Range Bands) (100% detection)
 
If you want to keep things really simple, you can forgo using any other modifiers to the sensor roll--just the sensor power (PP code), target range, and computer number were used above.

NOTE that I didn't use the UGM task roll on those numbers above.


If I were to use the UGM task roll on those tasks above (using the ship's TL as the governor stat), the tasks would be altered slightly to these....

(Note that this will increase range slightly and increase the range of 100% detection).

(TL 13 Free Trader)

170,000 = 2D for 12+
160,000 = 2D for 12+

150,000 = 2D for 12+ (The max range of this sensor)

140,000 = 2D for 10+ (14 Range Bands)
130,000 = 2D for 9+ (13 Range Bands)
120,000 = 2D for 8+ (12 Range Bands)
110,000 = 2D for 7+ (11 Range Bands)
100,000 = 2D for 6+ (10 Range Bands)

90,000 = 2D for 5+ (9 Range Bands)
80,000 = 2D for 4+ (8 Range Bands)
70,000 = 2D for 3+ (7 Range Bands)

60,000 = 2D for 2+ (6 Range Bands) (100% detection)
 
You must log in or register to reply here.

Similar threads

Mythic Mountains
CT Only: Looking to publish, for free, a retroclone of Classic Traveller
2
Replies
30
Views
2K
kilemall
kilemall
Tobias
CT Only: Robot Designations for new House Rules
2
Replies
22
Views
1K
Tobias
Tobias
sekalo
Wounds oppose to hit points
2
Replies
21
Views
808
Tobias
Tobias
C
CT High Guard: point blank range
Replies
19
Views
1K
Tobias
Tobias
Enoki
Insurance and Traveller
2 3
Replies
52
Views
1K
kilemall
kilemall
Back
Top