Making sense out of sensors.

This topic is as much a question as it is a suggestion/conversation starter. So ships are -4 to be detected when they have stealth coating on (p106) and +2 to be detected if they use active sensors (p143). But when it actually comes to the point where you're trying to detect a ship in the game they seem to have removed the task roll altogether.  And then you get stuff like this on p 147: Surprise Stealth is virtually impossible in space – a spacecraft shows up as a hot spot against the cold, so unless it is hiding behind an asteroid or other object, it is easy to detect. The only way to attack from surprise is to appear as a harmless ship until you open fire, or to jump in and attack without warning. If a ship has surprise, then its opponents do not act in the Combat Phase of the first round. The Spacecraft Operations section on p144 has some more rules for sensor operations. But again, no task for detection. It seems to be a given that you can see everything in range, but with varying degrees of detail.  So I guess my first question is, are we going with this idea that there is now no such thing as a "roll to detect" ships in space? That would mean that the "DM-4 to detection" from stealth and "DM +2 to detection" for using active sensors are really just left over from the play test document and really don't mean anything in Mongoose except when the sensor operator tries to get a +1 to hit for the gunners when attempting a sensor lock in combat. Even that task has been knocked down from a skill chain to a simple +1 if it succeeds.   I know we're avoiding making too many house rules, but it would be pretty good if we could bring back a roll to detect ships in space. It would actually give sensor operators something important to do rather than just trying to give folks a +1 to hit.  So the "states" of detection could look something like this ( pulled from play test doc and T20 ): Undetected . - Sensors have failed to detect the presence of the ship.  Detected - A scan using active or passive radar/lidar can detect presence and location of a ship. Attempting to target a ship that has only been "detected" is a formidable task beyond Adjacent range. Locked - A successful lock reveals information about the enemy vessel, such as power available, damage, weaponry, mass of their cargo, surviving crew and so forth. Ship may be targeted and fired upon.  Target solution - Once a lock has been achieved, a sensor operator may attempt to gain a target solution. By calculating the likely position of the enemy vessel, a sensors operator passes a targeting solution onto one attack. As different weapons have different firing profiles, a targeting solution must be calculated separately for each attack. This action allows the Sensor operator to aid one attack. ( or we could just stick with the +1 to hit per the current rules ) Moving up to the next "state" could require an education based sensor operation skill check with a difficulty based on the ranges from the chart on p 114. Passive or Active Radar/Lidar being used to detect ships, with the other sensors being used to gain lock or target solution.  Full - routine (+2) Limited - Moderate (+0) Minimal - Difficult  (-2) None - V.Difficult (-4) Other modifiers to this roll could include: + Ships sensor DM +2 if target is using active sensors or broadcasting communications.  +1 per point of thrust the ship used this turn.  +1 per energy weapon the target fired this turn. -4 if ship has stealth coating.  - effect of jamming attempt (for gaining target lock) + effect of jamming attempt (for detection) + 6 if target's transponder is active ("Squawking") Attempting to establish communications with a vessel would use the task difficulties for range given above, with some of the sensor DMs also being applied. Broadcasting would be picked up by any ship that could detect you. So the broadcasting ship makes a communications skill check as if the hearer was making an attempt to detect them.  Sending tight beam communications would require a sensor lock on the target you are communicating with.  I hope this suggestion makes sense. The rule's failure to accommodate stealth in space is really bugging me. 

Don’t really have time to fully scrutinize this, but I know we’ve been doing sensors rolls to detect system traffic and such. I’m inclined to think Pakkrat assumed there was a sensor roll involved, even if there isn’t as written . Arguably, a targeting solution should be much easier than getting any details about the ship in question, such as those supposedly provided by “Locked”; “I see a blip at <exact range and heading here>!” “What is it?” “Hell if I know! Should we fire on it anyway???”; friendly fire incidents happen all the time ... One of the issues that is often neglected is TL vs. TL issues; shouldn’t a TL14 suite of sensors with a net +2 to detect be able to detect a TL12 stealth job with a net +3? Isn’t that kind of the point with regards to TLs?

Yeah it would make sense if TL was a part of the show. I'm pretty sure it was back in Mega Traveller. Compute model was also a big part of electronic warfare and stealth as far as I can remember.  The reason you need a lock on a ship in order to be able to fire at it is because in Traveller space combat if you aimed at where your target currently is you would miss. Even with a laser you need to lead your shots. So a good target solution would take into account your own ship's current velocity and bearing, the velocity and bearing of the target, as well as a prediction about where it is going to be based on where the sensor operator believes it may be changing course to. To give you an example of what I'm talking about, imagine an enemy starship 5000kms away. That's 4 squares or Medium range. And imagine that ship is moving three squares per round. Not really that fast. Divide 5,000,000m (range to target) by 300,000,000m/s (speed of light) to find out what fraction of a second it would take for a laser beam to reach the target at that range. You get about 0.016s. Now multiply the speed of the target - 3 squares per round is 10416 metres per second - by 0.016 and you get about 174m. So to hit a ship with a laser that far away and going at that speed you need to aim 174 meters ahead of it. Add to that issue the problem of trying to guess what kind of direction changes it may make while the laser is on it's way and you've got a pretty tricky shot. And that's an attack at a slowish moving target that isn't too far away. 

Vector math is trivial for a computer, special relativity included. Far more complicated is object recognition, detection of subtle signals, and other such things. As such, hitting is easy; understanding is hard.

Tenacious Techhunter said: Vector math is trivial for a computer, special relativity included. Far more complicated is object recognition, detection of subtle signals, and other such things. As such, hitting is easy; understanding is hard. Yeah I think that's the point. You really need to understand the target to be able to anticipate where it's going to be, and you'd get that understanding from a good sensor reading. Is the target thrusting in a particular direction? Is it venting gas from a hull breach? Little things like that could make a pretty big difference when we're talking about these kinds of distances and speeds.  Yeah a computer could do it. But if you think about it there isn't a single job on a starship that a computer or robot couldn't do. We're just trying to keep people employed here. Would be great if folks with sensor ops actually got to use their skill to make a difference. 

Tenacious, what you're saying only just dawned on me. I get where you're coming from. I actually copied and pasted two different sensor tasks from the Traveller Playtest doc. Maybe they should go side by side rather than be a part of a progression?  Undetected . - Sensors have failed to detect the presence of the ship. Detected - A scan using active or passive radar/lidar can detect presence and location of a ship. Attempting to target a ship that has only been "detected" is a formidable task beyond Adjacent range. Locked - Once a successful lock has been achieved, the target may be targeted and fired upon with the usual range penalties. Once a sensor lock has been achieved, the sensor operator my attempt the following tasks: Target solution - Once a lock has been achieved, a sensor operator may attempt to gain a target solution. By calculating the likely position of the enemy vessel, a sensors operator passes a targeting solution onto one attack. As different weapons have different firing profiles, a targeting solution must be calculated separately for each attack. This action allows the Sensor operator to aid one attack. ( or we could just stick with the +1 to hit per the current rules ) Scan   - Reveals information about the enemy vessel, such as power available, damage, weaponry, mass of their cargo, surviving crew and so forth. 

All this stuff aside, the main thing I was hoping to point out is that if you're trying to be sneaky and using only passive sensors to detect other vessels, your range is limited to Medium. That's the main reason I'm thinking that a special Modular Cutter module loaded with sensor and communication gear would work great as a scout. The Ares would be able to strike from a distance without needing to get up close to detect other vessels with her sensors.  

It’s certainly something that could be worked into the proposed Cutter Modules somehow. Charoux is probably the one doing the Forward Observer stuff anyway, and as the CEO, he’d likely be in the “Company Tent” module. It would make sense to put sensor packages in there for this purpose. The trick would be figuring out where the Company Mess would go if it’s not in there.

Well ... you could just have lunch at your desk. I wonder if the command module "company tent" could have an extendable, telescopic design that unfolds once it has been deployed? A bit like this: Or this

It’s hard for something like that to also be armored... not impossible, though... It’s more about having a proper kitchen and dinner table for the entire party to grab meals at during extended stays.

Remember Universal Soldier? This piece of movie gold featured a truck with an armoured, extendable "command" trailer. I think that's the kind of thing we're after. ... without the truck part.  So in space it's being stealthy and snooping ahead with sensors and countermeasures. On the ground it unfolds to become a command station.  Probably putting this in the wrong topic. Should go in "Modular Cutters". 

Never actually saw it... ^_^;

Oh ... boy have you missed out ...  You can see the truck unfolding at 3:50 on this clip.  Universal Soldier Behind the Scenes. 

It is a good movie. Unlike the rest of the series.

Yeah the first one was pure 80s (early 90s?) action food. The rest were horrible.  I don't know if there are rules for "extendable" things, but I figured there were two ways we could go about it.  We could install one or more of these as a part of the module. So once it's put on the ground it would unfold from folding panels and assemble itself into a mini base.  Habitat Module (TL 8): A modular, unpressurised quarters for six people, capable of withstanding anything less than hurricane-force winds. Includes survival rations and enough batteries to keep the lights on and the heaters (or air conditioning) running for a week. Requires 12 man-hours to assemble, and can be attached to other modules to form a base. Cr 10,000. The TL 10 module is pressurised, and includes life-support for six occupants for one week (1000 person/hours). Cr 20,000. Could make it self assembling Self-Assembling (TL 11): The self-assembling upgrade can be given to tents, habitat modules and other basic structures. The structure is capable of expanding and assembling itself with only minimal aid, reducing the time needed to set up the shelter to a single man-hour. Cr. 5,000. And maybe this option too just for good measure.  Self-Sealing (TL 13): Structures can be made self-repairing and elf-Sealing at TL 13 for Cr. 2,000. Small breaches and rips are automatically fixed in seconds. Idea two looks a bit more like the Universal Soldier truck. This is where we have to get a bit fudgy and knock up our own rules for it.  I'd suggest that anything that "inflates" or "expands" take up 10% of it's expanded volume when retracted or deflated. That's based on the Collapsable  Fuel Tanks back in MegaTraveller that could be used to haul extra fuel in your cargo bay. When not in use they'd take up 1/10th the tons they could hold when fully inflated... if I remember correctly. So a 30ton collapsible fuel tank would take up 3 tons of cargo space when not in use. Also cost 500cr per Ton  ... again, if I remember correctly. Still looking for the actual stats.  Based on the same idea, a command module that expands the way the Universal Soldier truck does would take up 1 ton for every additional 10 tons of space added when fully expanded. So let's just say we want our 30 ton command module to unfold to have 60 ton of space once deployed. When it is all folded up it would take up 3 tons of space (+30tons/10) inside the 30 ton module.  This second idea really needs a Referee to give it the thumbs up though. The first option is pretty much ready to go. 

The problem is that those habitat things aren’t likely to be armored very much. I think we’d need to see an example of an armored & expandable module in order to justify the idea. Fitting more people isn’t really enough if we’re just exposing them to enemy fire.

Yeah. The habitat module is really just for "camping out". Folks inside the cutter module would be safe enough though. It'd just be the poor redshirts out in the plastic dome who get hammered.  The big limitation with the "extendable module" idea is that the extra space could only be for extra space. So it's for extra walking room only. Maybe with some folding chairs and tables you could turn that extra space into a mess or something. You couldn't really use that space for anything that actually takes up tonnage though. It would all have to be included in the "folded up" 30 ton space. Pretty sure that was the deal with the truck in Universal Soldier. The frozen soldiers were in the back, but once it unfolded there was more room in the back for folks to move around.  It recently dawned on me too - if you armour the module you would have to armour it based on it's "extended" tonnage, meaning that things like armour and hull reinforcement would cost more and take up more space. 

Can you explain what you mean by “extended tonnage”?

Okay, lets just say we had a 30 ton module that was designed to unfold like the Universal Soldier truck, giving it an extra 30dtons of space.  That extra space is just space. Being extendable doesn't mean the modular cutter can haul around more gear. It just means that once it's unfolded there is more room to move around inside. Maybe that extra space could be used as a temporary garage for example. Or maybe as a meeting area. But when the cutter comes to pick up the module, it won't be able to if it's "unfolded" and full of stuff. The folks in that meeting will all have to get out, or the vehicles in that temporary garage need to be removed. Because when the cutter hauls it around, it's a 30 ton module, not a 60 ton one.  And if we wanted to armour that module, it would need to be treated as a 60 ton craft if we want the entire volume protected by the armour. 

O.K., yes, now I get what you mean by “extended tonnage”. You can’t bug-out if you have to fiddle with folding and moving extra vehicles; better to keep it self-contained.

Most of what we need should fit into a 30 ton module anyway right?

The G-Carrier may need to be moved to the Dropship from the “Company Motorpool”... that, or maybe the Grav-Bikes need to move there. Putting all the Grav Vehicles in the same place looks like a tight fit...

I don't think that'd be a problem. 30tons - 8 should leave us plenty of room for stuff. A trap door on the floor that drops the G-Carrier out would look super cool too. Or maybe we could just ditch the ATV, put the vehicles in the gun ship, and not worry about having a motorpool module? ATVs are cool and handy and there are probably going to be times when going with grav vehicles isn't an option ... but having a free module for others things may be good. 

Funny how we now have discussions concerning the Modular Cutter modules spread out over three different topics. Mostly my fault. Just going to point folks HERE if they want to talk about modules for the Modular cutter so that we can focus this one on " Making sense out of sensors ."

Finally found what I've been looking for on page 139-140 of the Main Rulebook.  "The encounter distance depends on the results of a Sensors check (modifi ed by the other vessel’s attempts at Stealth, if any). Civilian vessels and military craft not on manoeuvres broadcast an IFF beacon, which gives a +4 DM to detection attempts." Sensor  check Effect Encounter Range Combat Range Failed 1d5 x 500kms Short - Medium 1 1d6 x 1000 Medium 2 2d6 x 1000 Medium - Long 3 1d6 x 5000 Medium - Long 4 2d6 x 5000 Long - Very Long 5 1d6 x 10,000 Long - Distant 6+ 2d6 x 10,000 Very Long - Distant So going back to the sensor table: It looks like the only sensors that can detect a ship in space are your visual and thermal. I figured that they were only for gaining locks though? It's the active passive Radar/Lidar "detects physical objects". If you can use visual and thermal to detect objects why would you ever use your radar? I'm probably overthinking this. It's just that I'm trying to come up with ways to maximize our initial contact range with bogies in space so that we can get a head start in any fight. Our particle accelerators are really our main weapon. We want to get the PAs going at Distant range if we can. 

Not really about sensors - Its just that I'm trying to cut down on how much I spam this forum.  I put this little tool together. If you put your figures into the green fields it will tell you how long your trip will take. There's also a tool in there that will tell you how far out a planets 100 diameter point is so you can calculate how far it would be to fly out.  Space Travel Tool 

There’s a web tool out there that lets you pick a system, pick an Imperium date, pick a starting location/planet/space object, and then, accounting for the orbits of the planets, will calculate the in-system travel time to the destination location/planet/space object. I probably mentioned it in here sometime before, but I’ve forgotten where, and hell if I know where that site is now, but it’s out there...

Oh that sounds great! Looking for it now.