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

Classic Traveller Sensor Rules

Originally posted by Sigg Oddra:
I do have quite a large jump flash when a ship enters jump - enough to damage nearby small craft if they aren't careful.
Very cool.

Tell me more about it, please! (your version of jumping in and out of systems)


I've played around a bit with changing canon jump definition. I don't work on it that much (been chewing on it for about a year and a half now), but I've got about 75% of a good idea to define jump a little differently than official Traveller.

It still takes a week, but there is no mystical, not-well-understood other dimension the ship passes through. The ship acutally stays in N-Space the whole time.

But, monkeying around with Traveller's command of quasi-gravity (inertial dampners, Contra-grav, and deck plates that produce 1G) and Einstein's theories, the ship makes its way through normal space FTL.

There's no "braking" under this method, though, so a ship has to "aim" for a star or a planet. The ship is constantly accelerating, FTL, throughout the entire journey, but needs a "cusion" to slow down. That cusion is the gravity well of a massive body. The ship falls into it like a drop of water into a lake.

And, the ship slows down again to STL speeds.

The ship's jump grid produces a field that monkies with the polarity of particles that both push and pull at the same time (not unlike like signs of a magnet repelling from each other, or the DGP defintion of how T-Plates work).

This field--the jump bubble--that creates itself around the ship actually condences the kilometer of space around a ship to .0001 meter or less.

The ship is then propelled down this trajorie that is constantly squeezing space just in front of the ship.

So the ship, from the observers inside the ship, is travelling at normal speed across a distance that the ship would usually take a week to cross.

Observers outside the ship, see it disappear (as it speeds off, FTL).

The ship never really leaves N-Space. It's just travelling FTL.

The massive push-pull of the jump grid, that is compressing space in front of the ship (and then letting it "unfold" again behind the ship), produces extreme gravity that breaks up any matter (floatsom, rocks, ice, whatever) that the ship encounters--hardly anything can survive that tremendous force.

The field is kept localized by another field, just a tad bigger, that keeps it from "spreading", keeping the extreme gravity maniuplation from screwing with the oribits of planets and what not.

Picture space as the sheet on your bed. You want to travel from your pillows to the foot of the bed, but that length is a parsec.

So, you go into your bathroom and get one of the rings that hold your shower curtain up. You come back to the bed and pull some of the sheet through the ring.

The diameter of the ring is the distance that your ship would need a week to get to the other side.

So, with the somewhat folded sheet, pulled through the ring, slide it down the length of your bed.

The whole time, the sheet is crumpling and folding in the middle of the ring, but this folding is not effecting the rest of the sheet.

And, the whole time, all your ship is doing is taking its week to cross the diameter of the ring.

Your ship is crossing the diameter of the ring, but the ring is sliding down the sheet while your ship does that.

At the end of a week, you pop out the other side of the ring, but you've traveled the entire lenth of the sheet.

Under this idea, starship captains usually pick a star and head for it, "slowing down" when they hit the 100 diam limit of the star. Then, they just move through N-Space to their destination.

More accurate calculations can get you to the 100 diam limit of a planet in the system.

Note that jumping out into deep space is not an option with this defintion of Traveller jump. When the jump is engaged, the exit point will always be the 100 diam limit of some massive body.

There's a limit to what science has allowed us to maintain the jump bubble (which also protects the ship from the extreme gravitational forces at work just outside the hull), and, given current technolgy, a week is all the jump bubble can be maintained.

Once science makes a breakthrough (which doesn't look likely in the near future), a jump of a parsec could be cut down--maybe even to a few hours.

But, for now, jump takes a week.
 
Originally posted by Sigg Oddra:
I do have quite a large jump flash when a ship enters jump - enough to damage nearby small craft if they aren't careful.
Very cool.

Tell me more about it, please! (your version of jumping in and out of systems)


I've played around a bit with changing canon jump definition. I don't work on it that much (been chewing on it for about a year and a half now), but I've got about 75% of a good idea to define jump a little differently than official Traveller.

It still takes a week, but there is no mystical, not-well-understood other dimension the ship passes through. The ship acutally stays in N-Space the whole time.

But, monkeying around with Traveller's command of quasi-gravity (inertial dampners, Contra-grav, and deck plates that produce 1G) and Einstein's theories, the ship makes its way through normal space FTL.

There's no "braking" under this method, though, so a ship has to "aim" for a star or a planet. The ship is constantly accelerating, FTL, throughout the entire journey, but needs a "cusion" to slow down. That cusion is the gravity well of a massive body. The ship falls into it like a drop of water into a lake.

And, the ship slows down again to STL speeds.

The ship's jump grid produces a field that monkies with the polarity of particles that both push and pull at the same time (not unlike like signs of a magnet repelling from each other, or the DGP defintion of how T-Plates work).

This field--the jump bubble--that creates itself around the ship actually condences the kilometer of space around a ship to .0001 meter or less.

The ship is then propelled down this trajorie that is constantly squeezing space just in front of the ship.

So the ship, from the observers inside the ship, is travelling at normal speed across a distance that the ship would usually take a week to cross.

Observers outside the ship, see it disappear (as it speeds off, FTL).

The ship never really leaves N-Space. It's just travelling FTL.

The massive push-pull of the jump grid, that is compressing space in front of the ship (and then letting it "unfold" again behind the ship), produces extreme gravity that breaks up any matter (floatsom, rocks, ice, whatever) that the ship encounters--hardly anything can survive that tremendous force.

The field is kept localized by another field, just a tad bigger, that keeps it from "spreading", keeping the extreme gravity maniuplation from screwing with the oribits of planets and what not.

Picture space as the sheet on your bed. You want to travel from your pillows to the foot of the bed, but that length is a parsec.

So, you go into your bathroom and get one of the rings that hold your shower curtain up. You come back to the bed and pull some of the sheet through the ring.

The diameter of the ring is the distance that your ship would need a week to get to the other side.

So, with the somewhat folded sheet, pulled through the ring, slide it down the length of your bed.

The whole time, the sheet is crumpling and folding in the middle of the ring, but this folding is not effecting the rest of the sheet.

And, the whole time, all your ship is doing is taking its week to cross the diameter of the ring.

Your ship is crossing the diameter of the ring, but the ring is sliding down the sheet while your ship does that.

At the end of a week, you pop out the other side of the ring, but you've traveled the entire lenth of the sheet.

Under this idea, starship captains usually pick a star and head for it, "slowing down" when they hit the 100 diam limit of the star. Then, they just move through N-Space to their destination.

More accurate calculations can get you to the 100 diam limit of a planet in the system.

Note that jumping out into deep space is not an option with this defintion of Traveller jump. When the jump is engaged, the exit point will always be the 100 diam limit of some massive body.

There's a limit to what science has allowed us to maintain the jump bubble (which also protects the ship from the extreme gravitational forces at work just outside the hull), and, given current technolgy, a week is all the jump bubble can be maintained.

Once science makes a breakthrough (which doesn't look likely in the near future), a jump of a parsec could be cut down--maybe even to a few hours.

But, for now, jump takes a week.
 
As for Class III's and Class IV's being restricted...


Should these really be restricted? Why are we thinking of limiting the availability of sensor packages? Why would he empire want to restrict them? Even miliary grade Class IV's?

I'm thinking that the Class III's and Class IV's aren't restricted...they're just so damn expensive that most outfits won't buy 'em.

Planetary governments buy Class IV's for their military vessels not because they're economical, but because the best sensors available are desperately needed for space combat.

But, if some super-rich MegaCorp wants to outfit one of its ships with Class IV's, why should it have to demonstrate need and obtain a permit?
 
As for Class III's and Class IV's being restricted...


Should these really be restricted? Why are we thinking of limiting the availability of sensor packages? Why would he empire want to restrict them? Even miliary grade Class IV's?

I'm thinking that the Class III's and Class IV's aren't restricted...they're just so damn expensive that most outfits won't buy 'em.

Planetary governments buy Class IV's for their military vessels not because they're economical, but because the best sensors available are desperately needed for space combat.

But, if some super-rich MegaCorp wants to outfit one of its ships with Class IV's, why should it have to demonstrate need and obtain a permit?
 
--RULES UPDATE--


As I play with these sensor rules, some of the details start to shake out.

I'll include all this stuff once I do the final write-up (including the tonage and prices that we're working on).

High Guard notes that the ship's Navigator is many times the Gunnery Supervisor as well (one step above the Chief Gunner).

This makes a lot of sense. Sensors is the name of the navigation game, and what piece of equipment is more important to a gunner firing a light beam out at 500,000 km or more than sensors?

Given that, I'm going to update the way Sensor Ops skill can be obtained.

Right now, Navigation minus one and Computer minus two will net you the resulting Sensor Ops skill.

To this, I'm adding: Gunnery minus one = Sensor Ops skill.


In Book 2 combat, the Navigator will be at his post, interpreting sensor data, feeding it to the gunner. The gunner will be doing his thing, reading his board, programming the computer to make a hit on the target.

So, during Book 2 combat, if the Navigator leaves his post or is incapacitated, this makes it harder for the gunner to do his job.

These sensor rules will reflect this by stating: If a sensor operator is not working in-conjunction with the gunner(s), then they operate at one level lower (Gunner minus one, using the CT rule for a crewmember doing two jobs).

Note, that this will be moot unless the Gunner Interact program is working.

If the sensor operator is incapacitated or leaves his post, a character with Gunnery skill can take his place provided that character has Gunnery-2 (because Gunnery minus two = Sensor Ops).

So, if a ship's Navigator gets incapacitated (Crew Critical Hit on the Book 2 damage tables), then that post can be filled by someone with either Computer-2 or higher, or Gunnery-2 or higher (if no character with Sensor Ops skill is aboard the vessel, then no sensor rolls for detection or targeting are allowed...and no detection means no targeting...and no targeting means no firing of the ship's weapons).

The ship's Navigator/Sensor Operator is an important position--just as important as the ship's Pilot or Engineer.
 
--RULES UPDATE--


As I play with these sensor rules, some of the details start to shake out.

I'll include all this stuff once I do the final write-up (including the tonage and prices that we're working on).

High Guard notes that the ship's Navigator is many times the Gunnery Supervisor as well (one step above the Chief Gunner).

This makes a lot of sense. Sensors is the name of the navigation game, and what piece of equipment is more important to a gunner firing a light beam out at 500,000 km or more than sensors?

Given that, I'm going to update the way Sensor Ops skill can be obtained.

Right now, Navigation minus one and Computer minus two will net you the resulting Sensor Ops skill.

To this, I'm adding: Gunnery minus one = Sensor Ops skill.


In Book 2 combat, the Navigator will be at his post, interpreting sensor data, feeding it to the gunner. The gunner will be doing his thing, reading his board, programming the computer to make a hit on the target.

So, during Book 2 combat, if the Navigator leaves his post or is incapacitated, this makes it harder for the gunner to do his job.

These sensor rules will reflect this by stating: If a sensor operator is not working in-conjunction with the gunner(s), then they operate at one level lower (Gunner minus one, using the CT rule for a crewmember doing two jobs).

Note, that this will be moot unless the Gunner Interact program is working.

If the sensor operator is incapacitated or leaves his post, a character with Gunnery skill can take his place provided that character has Gunnery-2 (because Gunnery minus two = Sensor Ops).

So, if a ship's Navigator gets incapacitated (Crew Critical Hit on the Book 2 damage tables), then that post can be filled by someone with either Computer-2 or higher, or Gunnery-2 or higher (if no character with Sensor Ops skill is aboard the vessel, then no sensor rolls for detection or targeting are allowed...and no detection means no targeting...and no targeting means no firing of the ship's weapons).

The ship's Navigator/Sensor Operator is an important position--just as important as the ship's Pilot or Engineer.
 
"So, what comes with the Class I?"

...overheard at a starport drydock.


CLASS I SENSOR SUITE

What comes in a Class I sensor?

I'm thinking that the Class I will contain two sensor clusters: An Active, and a Passive, EMS cluster (only).

Active/Passive EMS clusters will contain:
RADAR
RADAR direction finders
Radio direction finders
LADAR (tight-beam optical laser version of RADAR)
MADAR (tight-beam EM microwave, non-optical version of RADAR)
Laser Sensors
HRT - High Resolution Thermal Imaging

And, with these two sensor clusters, a standard Class I sensor suite can detect things like (this is for GM color): broadcast radio, radar signals, microwave/maser communications (if intercepted), heat sources and IR, all forms of visible light from stars to lasers, all forms of ultraviolet light, x-rays, and gamma radiation from nuclear explosions and stars. Plus whatever else a GM thinks can be detected with either an Active or Passive Electro-Magnetic Spectrum sensor cluster.

Heck, if a ship takes the time, I don't even see why something like what the Hubble telescope picks up (other galaxies and other star systems), but you definitely couldn't do this in a 1000 second combat round.

Still, if a PC ship took a few days, pointing its sensors in the right direction, this could be an ingenious way for a GM to start off an adventure...

"During your 3 day journey to the system's gas giant, the Navigator used the time to collect update data for the Generate program. This has to be done from time to time. For the entire three days, the ship's extreme range sensors were pointed in the direction of this star system...and he picked up something strange...take a look at this dark speck here..."'


CLASS II SENSOR SUITE

The class II suite will include the same two EMS clusters (an active cluster and a passive cluster) that show up in the Class I suite, except these versions will be of higher quality and have extended range.


CLASS III SENSOR SUITE

Starting with the Class III suite, two new sensors will be added to the packaged.

Class III suites include the two EMS clusters (longer range than Class II's), but also a Neutrino Sensor and a Denistometer.

Neutrino Sensor: A neutrino is a nearly massless sub-atomic particle given off by high energy reactions such as fission and fusion, and because of this, Neutrino Sensors are effective at classifying starship power plants (even estimating their energy output given a good reading).

Since neutrinos are almost massless, they are extremely hard to detect and are rarely deflected or "reflected" by other matter. But, one kind of matter that does reflect neutrinos is the superdense material used in starship hulls. Passive neutrino sensors can sometimes pick up the faint outline of a starship's hull, caused by reflected neutrinos from the vessel's power plant, at a much greater distance than can any other modern starship sensor (which is why Class III and Class IV sensors are used on military vessels).

Densitometer: The densitometer is an outgrowth of gravitic technology and can detect and classify an object according to its density. Since all matter posseses a natural gravity, this passive sensor is very sensitive, dealing with very weak gravitational fields. Because artificial gravity from a starship can disrupt or distort densitometer sensor readings, the densitometer is an expensive sensor that requires its own gravity shielding (which is one of the reasons Class III and Class IV sensors are so enormously expensive).

The densitometer provides a three-dimensional density map of the object being veiwed, but target vessels who drop their artificial gravity fields are harder to detect with this sensor.


CLASS IV SENSOR SUITE

The Class IV sensor suites will include the same types of sensors as the Class III: Active/Passive EMS, Neutrino Sensor, and Densitometer. But, each of these sensor will be of the highest quality, providing the best performance and range.


I'm still working on the prices and tonnages for the four sensor suites, but this is what I've got so far in way of describing what the four classes have to offer a starship captain.

Again, this is all for color. When playing with the sensor rules, a GM or player only has to consider the ship's Active or Passive sensors (there is not a modifier, for example, for a sensor operator reading LADAR rather than RADAR results). This stuff is for GMs who want to add atmosphere to their descriptions of what the players are living through in the game.

Thoughts?
 
"So, what comes with the Class I?"

...overheard at a starport drydock.


CLASS I SENSOR SUITE

What comes in a Class I sensor?

I'm thinking that the Class I will contain two sensor clusters: An Active, and a Passive, EMS cluster (only).

Active/Passive EMS clusters will contain:
RADAR
RADAR direction finders
Radio direction finders
LADAR (tight-beam optical laser version of RADAR)
MADAR (tight-beam EM microwave, non-optical version of RADAR)
Laser Sensors
HRT - High Resolution Thermal Imaging

And, with these two sensor clusters, a standard Class I sensor suite can detect things like (this is for GM color): broadcast radio, radar signals, microwave/maser communications (if intercepted), heat sources and IR, all forms of visible light from stars to lasers, all forms of ultraviolet light, x-rays, and gamma radiation from nuclear explosions and stars. Plus whatever else a GM thinks can be detected with either an Active or Passive Electro-Magnetic Spectrum sensor cluster.

Heck, if a ship takes the time, I don't even see why something like what the Hubble telescope picks up (other galaxies and other star systems), but you definitely couldn't do this in a 1000 second combat round.

Still, if a PC ship took a few days, pointing its sensors in the right direction, this could be an ingenious way for a GM to start off an adventure...

"During your 3 day journey to the system's gas giant, the Navigator used the time to collect update data for the Generate program. This has to be done from time to time. For the entire three days, the ship's extreme range sensors were pointed in the direction of this star system...and he picked up something strange...take a look at this dark speck here..."'


CLASS II SENSOR SUITE

The class II suite will include the same two EMS clusters (an active cluster and a passive cluster) that show up in the Class I suite, except these versions will be of higher quality and have extended range.


CLASS III SENSOR SUITE

Starting with the Class III suite, two new sensors will be added to the packaged.

Class III suites include the two EMS clusters (longer range than Class II's), but also a Neutrino Sensor and a Denistometer.

Neutrino Sensor: A neutrino is a nearly massless sub-atomic particle given off by high energy reactions such as fission and fusion, and because of this, Neutrino Sensors are effective at classifying starship power plants (even estimating their energy output given a good reading).

Since neutrinos are almost massless, they are extremely hard to detect and are rarely deflected or "reflected" by other matter. But, one kind of matter that does reflect neutrinos is the superdense material used in starship hulls. Passive neutrino sensors can sometimes pick up the faint outline of a starship's hull, caused by reflected neutrinos from the vessel's power plant, at a much greater distance than can any other modern starship sensor (which is why Class III and Class IV sensors are used on military vessels).

Densitometer: The densitometer is an outgrowth of gravitic technology and can detect and classify an object according to its density. Since all matter posseses a natural gravity, this passive sensor is very sensitive, dealing with very weak gravitational fields. Because artificial gravity from a starship can disrupt or distort densitometer sensor readings, the densitometer is an expensive sensor that requires its own gravity shielding (which is one of the reasons Class III and Class IV sensors are so enormously expensive).

The densitometer provides a three-dimensional density map of the object being veiwed, but target vessels who drop their artificial gravity fields are harder to detect with this sensor.


CLASS IV SENSOR SUITE

The Class IV sensor suites will include the same types of sensors as the Class III: Active/Passive EMS, Neutrino Sensor, and Densitometer. But, each of these sensor will be of the highest quality, providing the best performance and range.


I'm still working on the prices and tonnages for the four sensor suites, but this is what I've got so far in way of describing what the four classes have to offer a starship captain.

Again, this is all for color. When playing with the sensor rules, a GM or player only has to consider the ship's Active or Passive sensors (there is not a modifier, for example, for a sensor operator reading LADAR rather than RADAR results). This stuff is for GMs who want to add atmosphere to their descriptions of what the players are living through in the game.

Thoughts?
 
Originally posted by Sigg Oddra:
If you have a jump emergence flash IYTU then yes, treat as going active.
I think I'm going to add a line in the rules about a ship being considered "Active" when it either jumps into, or out of, a system.

Ships can still be sneaky--it just requires that they jump into a system at least 2-3 light seconds away from another vessel. If you want to be stealthy, jump into a system at very long range and take your time approaching your victim.

Also--

A ship's transponder will consider most ships as "Active", and if you detect a vessel that doesn't have it's transponder "on", then he's probably up to no good.

No transponder broadcast = Red Flag.

It's Imperial Law to keep your ship's transponder broadcasting at all times, but I look upon this like the speed limit on a RL freeway. Just as speed governors on cars are illegal but there's a speed limit, ship's are required to keep their transponders broadcasting at all times but can turn them "off".

The reason they can be turned "off" is probably because of pirate activity. But, finding a ship with a transponder not broadcasting is a sure-fire way to get boarded (and fined) by a system patrol boat.

Heck, the GM could take this another step and set up "transponder traps" in the same way we have "speed traps" here in the RW.

"Pysadi? Naw, can't stand that piddly TL world. They don't have an inter-system Navy, and sometimes pirates make a run through that system...but the Pysadians sure don't have a problem using one of their three ancient patrol cutters to board ya and fine ya for being safe and runnin' with your transponder down."
 
Originally posted by Sigg Oddra:
If you have a jump emergence flash IYTU then yes, treat as going active.
I think I'm going to add a line in the rules about a ship being considered "Active" when it either jumps into, or out of, a system.

Ships can still be sneaky--it just requires that they jump into a system at least 2-3 light seconds away from another vessel. If you want to be stealthy, jump into a system at very long range and take your time approaching your victim.

Also--

A ship's transponder will consider most ships as "Active", and if you detect a vessel that doesn't have it's transponder "on", then he's probably up to no good.

No transponder broadcast = Red Flag.

It's Imperial Law to keep your ship's transponder broadcasting at all times, but I look upon this like the speed limit on a RL freeway. Just as speed governors on cars are illegal but there's a speed limit, ship's are required to keep their transponders broadcasting at all times but can turn them "off".

The reason they can be turned "off" is probably because of pirate activity. But, finding a ship with a transponder not broadcasting is a sure-fire way to get boarded (and fined) by a system patrol boat.

Heck, the GM could take this another step and set up "transponder traps" in the same way we have "speed traps" here in the RW.

"Pysadi? Naw, can't stand that piddly TL world. They don't have an inter-system Navy, and sometimes pirates make a run through that system...but the Pysadians sure don't have a problem using one of their three ancient patrol cutters to board ya and fine ya for being safe and runnin' with your transponder down."
 
Anybody besides me used these rules in their game?

If so, how'd it go?

I was just reading in Fire, Fusion & Steel how the two big factors in sensor equipment is signal power and antenna size. They figured a way to make the antennas smaller (listed in FF&S), and I felt even better about having the ship's powerplant letter code have such a big role in these sensor rules.
 
Anybody besides me used these rules in their game?

If so, how'd it go?

I was just reading in Fire, Fusion & Steel how the two big factors in sensor equipment is signal power and antenna size. They figured a way to make the antennas smaller (listed in FF&S), and I felt even better about having the ship's powerplant letter code have such a big role in these sensor rules.
 
Kenneth,

I'll try the rules soon, but you keep posting so much text that I never get down to testing it, cause I'm busy trying to digest all interesting speculation in this thread!

Seriously, they look good and I wish I could get some free time to test this.

One question, though, will you consolidate all the sprawling posts about sensor rules in a pdf/rtf document? It might make it easier for me to take them away and read them through before falling asleep, without having to take the computer to bed...
 
Kenneth,

I'll try the rules soon, but you keep posting so much text that I never get down to testing it, cause I'm busy trying to digest all interesting speculation in this thread!

Seriously, they look good and I wish I could get some free time to test this.

One question, though, will you consolidate all the sprawling posts about sensor rules in a pdf/rtf document? It might make it easier for me to take them away and read them through before falling asleep, without having to take the computer to bed...
 
Originally posted by Cymew:
One question, though, will you consolidate all the sprawling posts about sensor rules in a pdf/rtf document?
I will do that, eventually, but I'm notoriously "slow" about getting things in a final format (months--still haven't put together one for the UGM).

How about this--I'll pick out the most important posts in this thread, a sort of table of contents.

There are only three posts of rules in this thread. They're all labeled.

Just look for the three posts titled:



---SENSOR SUITE--- (rules page 1 of 3)

---SENSOR LISTING--- (rules page 2 of 3)

---SENSOR TASKS--- (rules page 3 of 3)


They're all on the first page of this thread.


Those are the only necessary posts, I'd say, to use the sensor rules in a game.

Four other posts that may be useful, but are not required to use the rules in the game are:


---RULES APPENDIX--- (page 1 of 1)

A LOOK AT THESE SENSOR RULES...

--RULES UPDATE—

"So, what comes with the Class I?"


All four of those posts are clearly marked at the top of the post as well.

Read the top three posts, and you're in business. Read the bottom four posts, and you've got 99% of the meat in this thread.

Hope that helps.
 
Originally posted by Cymew:
One question, though, will you consolidate all the sprawling posts about sensor rules in a pdf/rtf document?
I will do that, eventually, but I'm notoriously "slow" about getting things in a final format (months--still haven't put together one for the UGM).

How about this--I'll pick out the most important posts in this thread, a sort of table of contents.

There are only three posts of rules in this thread. They're all labeled.

Just look for the three posts titled:



---SENSOR SUITE--- (rules page 1 of 3)

---SENSOR LISTING--- (rules page 2 of 3)

---SENSOR TASKS--- (rules page 3 of 3)


They're all on the first page of this thread.


Those are the only necessary posts, I'd say, to use the sensor rules in a game.

Four other posts that may be useful, but are not required to use the rules in the game are:


---RULES APPENDIX--- (page 1 of 1)

A LOOK AT THESE SENSOR RULES...

--RULES UPDATE—

"So, what comes with the Class I?"


All four of those posts are clearly marked at the top of the post as well.

Read the top three posts, and you're in business. Read the bottom four posts, and you've got 99% of the meat in this thread.

Hope that helps.
 
WJP, I appreciate your responses to my questions earlier. Sorry I haven't gotten back to you sooner, but weekends are family time. (I use work time for Traveller! ;) ) I didn't realize that the 90 hex limit was canon, I agree that you should use it then.

One more detection question; I assume that a sensor operator can roll is one detection roll every turn. So if he missed a ship in the first roll, he has a chance of detecting them in the second or subsequent rounds? This could make detection of any ship just about automatic over a long period of time (after all every 36 rounds the Navigator should roll a 12).

I'm again thinking of the situation where a ship is at the 100D limit of the planet. At 1g that is about a 4-6 hour trip to orbit. Just about everything should be detectable in that time, assuming the Navigator is rolling every 10 minutes (24-36 rolls). Is that what you want?

I'm thinking it is OK, but it's something to consider.

Keep up the good work!
 
WJP, I appreciate your responses to my questions earlier. Sorry I haven't gotten back to you sooner, but weekends are family time. (I use work time for Traveller! ;) ) I didn't realize that the 90 hex limit was canon, I agree that you should use it then.

One more detection question; I assume that a sensor operator can roll is one detection roll every turn. So if he missed a ship in the first roll, he has a chance of detecting them in the second or subsequent rounds? This could make detection of any ship just about automatic over a long period of time (after all every 36 rounds the Navigator should roll a 12).

I'm again thinking of the situation where a ship is at the 100D limit of the planet. At 1g that is about a 4-6 hour trip to orbit. Just about everything should be detectable in that time, assuming the Navigator is rolling every 10 minutes (24-36 rolls). Is that what you want?

I'm thinking it is OK, but it's something to consider.

Keep up the good work!
 
Originally posted by Plankowner:
One more detection question; I assume that a sensor operator can roll is one detection roll every turn. So if he missed a ship in the first roll, he has a chance of detecting them in the second or subsequent rounds?
Absolutely.

Only one scan is allowed per 1000 second combat turn.

Scan are usually performed with Passive sensors, but Active sensors can be used too (like RADAR). The problem with Active, though, is that you get a -2DM penalty when performing an Active scan (because Active sensors are more useful for pinpointing an object, not scanning wide areas) and your ship will be considered "Active" (giving the enemy a +6DM bonus to detect you...they'll see you.).


But...a ship CAN make several sensor rolls to lock on a target each round.

On lock attempt can be made per bogey detected with the scan. So, if five bogies have been detected, then five targeting rolls are allowed (one roll per bogey).

A -6DM (huge penalty) is assigned each targeting lock. The only way to avoid this penalty is to use Active sensors for your lock, and even then, you only get a number of Active targeting rolls, free of penalty, equal to your ship's Computer Model number.


============================================
EXAMPLE
============================================

So....

A Free Trader uses a Model 1 computer.

There are only two types of sensor rolls: A scan (detection task) and a lock (targeting task).

Each space combat round, the Free Trader can make one detection roll (one scan). If the Passive sensors are used for this, then the roll is as indicated in the ship's sensor listing. If Active sensors are used, then a -2DM penalty is applied, and the ship is considered "Active" to any enemies out there.

Let's say that the Free Trader picked up three bogies with his detection roll (his scan).

Then, three targeting locks are possible. If Passive sensors are used to lock onto the targets, then three rolls can be made, all of them at a -6DM.

If Active sensors are used for the targeting locks, then one of the locks is made normally while the other two would have to be made with te -6DM penalty (Computer Model 1). And, if Active sensors are used, then the ship is considered "Active".


This could make detection of any ship just about automatic over a long period of time (after all every 36 rounds the Navigator should roll a 12).
That is true...

....as long as a bogey is in range.

(And, it makes a lot of real-world sense...it shouldn't be easy at all to sneak-up close to a starship--not given their tech and the fact that there's not a whole lot to hide behind in space.)

Consider this...

The Free Trader will have Class I sensors (range of 15 hexes).

That means, considering likely bonuses for sensor op skill and such, it's real range is about 16-18 hexes...and detecting objects at that range (180,000 km) will only happen when a 12 is rolled on the sensor scan.

If an enemy hovers out at, say, 20 hexes, then it is very unlikely he will be detected (unless he does something stupid like go "active", giving the free trader a +6DM to detect him).

But, how does an enemy detect the free trader at 20 hexes?

Well, (1) he has better sensors. If he's got Class II sensors, then his range is 30 hexes (31-33 or so with bonses, provided a 12 is rolled).

So, if the enemy has better sensors, the free trader might be in trouble (depending on subsequent actions of the long-range enemy).

But...what if the enemy has Class I sensors too?

That can be tackled too, by a smart pirate.

If the pirate looks like normal shipping, then he won't draw attention to himself.

Transponders typically make all ship's "active" (they're broadcasting their IDs).

So, when the player's ship passes a typical other merchant vessel, it's really not even worth mentioning. It happens all the time at worlds with a lot of traffic.

The pirate locks sensors at range, and then goes about his business, moving opposite the free trader as the free trader journeys from orbit to 100 diams.

At about 200,000 km, the pirate can switch off his transponder and start doing whatever he needs to in order to track or attack the free trader.

Remember, a ship can track another out to 90 hexes after detection.

If the free trader didn't have a lock on the other merchant vessel it saw (no reason it should), then the pirate has a lock on the free trader, but the pirate is also now out of the free trader's detection range.

These are the types of things these rules add to the game.

Playing something out like that would be fun!
 
Originally posted by Plankowner:
One more detection question; I assume that a sensor operator can roll is one detection roll every turn. So if he missed a ship in the first roll, he has a chance of detecting them in the second or subsequent rounds?
Absolutely.

Only one scan is allowed per 1000 second combat turn.

Scan are usually performed with Passive sensors, but Active sensors can be used too (like RADAR). The problem with Active, though, is that you get a -2DM penalty when performing an Active scan (because Active sensors are more useful for pinpointing an object, not scanning wide areas) and your ship will be considered "Active" (giving the enemy a +6DM bonus to detect you...they'll see you.).


But...a ship CAN make several sensor rolls to lock on a target each round.

On lock attempt can be made per bogey detected with the scan. So, if five bogies have been detected, then five targeting rolls are allowed (one roll per bogey).

A -6DM (huge penalty) is assigned each targeting lock. The only way to avoid this penalty is to use Active sensors for your lock, and even then, you only get a number of Active targeting rolls, free of penalty, equal to your ship's Computer Model number.


============================================
EXAMPLE
============================================

So....

A Free Trader uses a Model 1 computer.

There are only two types of sensor rolls: A scan (detection task) and a lock (targeting task).

Each space combat round, the Free Trader can make one detection roll (one scan). If the Passive sensors are used for this, then the roll is as indicated in the ship's sensor listing. If Active sensors are used, then a -2DM penalty is applied, and the ship is considered "Active" to any enemies out there.

Let's say that the Free Trader picked up three bogies with his detection roll (his scan).

Then, three targeting locks are possible. If Passive sensors are used to lock onto the targets, then three rolls can be made, all of them at a -6DM.

If Active sensors are used for the targeting locks, then one of the locks is made normally while the other two would have to be made with te -6DM penalty (Computer Model 1). And, if Active sensors are used, then the ship is considered "Active".


This could make detection of any ship just about automatic over a long period of time (after all every 36 rounds the Navigator should roll a 12).
That is true...

....as long as a bogey is in range.

(And, it makes a lot of real-world sense...it shouldn't be easy at all to sneak-up close to a starship--not given their tech and the fact that there's not a whole lot to hide behind in space.)

Consider this...

The Free Trader will have Class I sensors (range of 15 hexes).

That means, considering likely bonuses for sensor op skill and such, it's real range is about 16-18 hexes...and detecting objects at that range (180,000 km) will only happen when a 12 is rolled on the sensor scan.

If an enemy hovers out at, say, 20 hexes, then it is very unlikely he will be detected (unless he does something stupid like go "active", giving the free trader a +6DM to detect him).

But, how does an enemy detect the free trader at 20 hexes?

Well, (1) he has better sensors. If he's got Class II sensors, then his range is 30 hexes (31-33 or so with bonses, provided a 12 is rolled).

So, if the enemy has better sensors, the free trader might be in trouble (depending on subsequent actions of the long-range enemy).

But...what if the enemy has Class I sensors too?

That can be tackled too, by a smart pirate.

If the pirate looks like normal shipping, then he won't draw attention to himself.

Transponders typically make all ship's "active" (they're broadcasting their IDs).

So, when the player's ship passes a typical other merchant vessel, it's really not even worth mentioning. It happens all the time at worlds with a lot of traffic.

The pirate locks sensors at range, and then goes about his business, moving opposite the free trader as the free trader journeys from orbit to 100 diams.

At about 200,000 km, the pirate can switch off his transponder and start doing whatever he needs to in order to track or attack the free trader.

Remember, a ship can track another out to 90 hexes after detection.

If the free trader didn't have a lock on the other merchant vessel it saw (no reason it should), then the pirate has a lock on the free trader, but the pirate is also now out of the free trader's detection range.

These are the types of things these rules add to the game.

Playing something out like that would be fun!
 
Back
Top