MT ship combat sensors

[JFGarber]

Recent member, first post.

I have dusted off my old MT books, and am running a campaign for my 13-year old son and a friend of his. They areplaying Vargr corsairs near Corridor, and this Sunday afternoon we will play through the consequences of a series of unfortunate decisions. Their ship will face three SDB's.

There is a line in the RM (p. 92) that reads in part "...the sensing unit must forgo the firing of one weapon battery for every sensor task performed..."

I'm throwing that rule out. I can't see the reality of wasting one battery for every opponent in the battle. How do others handle this? Straight as written? Alternatives?

While I recognize that it's MTU, I don't want to veer too far from the fabric of the game design and break something that I regret downstream.

 

[Major B]

I'm throwing that rule out. I can't see the reality of wasting one battery for every opponent in the battle. How do others handle this? Straight as written? Alternatives?

While I recognize that it's MTU, I don't want to veer too far from the fabric of the game design and break something that I regret downstream.

JF, welcome.

I just went back and re-read that section of the RM. I've always played it the way you describe but I wanted to be sure before I posted a reply.

I picked up on one thing that I'd forgotted (or just never noticed) - it seems to me that the rule is saying that the time necessary for a sensor task impacts the amount of time left to fire weapons in a round. The first is free but every sensor task beyond the first deducts from the number of batteries that can fire in that turn, and since you need a successful scan AND a successful lock to fire...

That said, even after re-reading, I don't like it. Further, I don't think you break anything significant by separating sensor scans from firing. After all, each round is 20 minutes long.

 

[BardicHeart]

As I've been going over this, this is how I'm considering handling this.

The rules allow one free sensor task as written before you have to give up battery fire.

RM p92 Multiple sensor tasks take time; to reflect this, the sensing unit must forego the firing of one weapon battery for every sensor task performed (one sensor task costs nothing).

My modification will be as follows. One free sensor task may be performed for each Sensor Ops bridge crew with a sensor work station. Thus if the bridge crew includes 5 Sensor Ops with 5 work stations, they could make five free sensor tasks without giving up any battery fire. Large ships thus gain the advantage of being able to deal with multiple scans and targets more effectively because they have the crew to handle it. Small ships have less ability to deal with this because they lack the manpower.

Still considering whether sofisticated computers and software could allow for multiple sensor tasks at one work station.

 

[Major B]

My modification will be as follows. One free sensor task may be performed for each Sensor Ops bridge crew with a sensor work station. Thus if the bridge crew includes 5 Sensor Ops with 5 work stations, they could make five free sensor tasks without giving up any battery fire. Large ships thus gain the advantage of being able to deal with multiple scans and targets more effectively because they have the crew to handle it. Small ships have less ability to deal with this because they lack the manpower.

Still considering whether sofisticated computers and software could allow for multiple sensor tasks at one work station.

I like that but think it leaves something out. The time needed for the operator to process the information is just part of the equation - what about the ability of the sensor itself to gain resolution on multiple targets?

What do you think of making it a function of the number of operators AND the number of sensor suites available for use? One operator at one console with one sensor suite can acquire one target. Two operators with two consoles and two suites can acquire two targets.

This still gives an advantage to larger ships and sets up a more meaningful mechanism for determining how many sensors need to be installed in a ship design.

 

[BardicHeart]

So you'd have multiple Passive and Active EMS suites, correct? One per crew station? Works for me.

I also just realized that workstations are from T4... oops Still learning to keep all this stuff straight.

 

[Lycanorukke]

What do you think of making it a function of the number of operators AND the number of sensor suites available for use? One operator at one console with one sensor suite can acquire one target. Two operators with two consoles and two suites can acquire two targets.

Since I generally ran 'small ships' I usually only had one sensor/operator in use - but I worked it that you got your 'free sensor' plus an extra free 'scan' for every level in sensor ops of the operator. The idea was that while you could use the computer level as a DM, a human with skill was better at using tricks to speed things up, elimiate false readings and select optimal solutions rather than brute force computer scanning (in addition to making sensor-ops a useful skill).

Another idle idea - have the highest sensor-ops skill add the extra turns, and if there are additional operators free, use their sensor ops skill like the tactics pool except only for scans/locks. Having a good sensor operator is no longer optional for a ship expecting combat.

Eg: Ship with two sensor ops
Sensor op -3
Senor ops -2

The ship has 4 free scans (3+freebie), and a scan/lock pool of +2

 

[HG_B]

Still considering whether sofisticated computers and software could allow for multiple sensor tasks at one work station.

Considering what can be done at our current TL in this area, the rules as written are horribly antiquated. More on par with what was done in WWII. Currently, one console can combine many active and passive sensors to track/lock a score or more of targets and feed to multiple weapons.

 

[robject]

I'd think the simpler the rules in this case the better. Either require solution time to acquire a sensor lock or don't...

 

[BardicHeart]

Considering what can be done at our current TL in this area, the rules as written are horribly antiquated. More on par with what was done in WWII. Currently, one console can combine many active and passive sensors to track/lock a score or more of targets and feed to multiple weapons.

As I continue to read more about the various versions of Traveller, I'm quickly learning that what can be done in the real world doesn't always have any bearing on what is possible in Traveller. That's just part of the game. However, I think your point about WW II is very key. Having read various versions of the starship combat rules, it seem much of it posulates battles fought with the same general tactics from the Age of Sail thru early WW II. That is, lines of battleships square off and slug it out, boarding actions, etc.

Now speaking personally, I think its a bit silly, but on the other hand it offers more drama and opportunity for role playing (as part of a boarding party or defending against such for example, allowing me to involve the whole troop of PCs). But that was how Traveller was designed and its part of the "flavor" of the game. I'm very reluctant right now to make many house rules as I'm still absorbing all the printed rules and trying to make sure I have a strong grasp of that.

I do like the compromise Major B and I came up with... extra sensor tests mean extra equipment and personel, which seems to fit with the "setting" and shouldn't unbalance things... I don't think.

 

[HG_B]

As I continue to read more about the various versions of Traveller, I'm quickly learning that what can be done in the real world doesn't always have any bearing on what is possible in Traveller.

Right. That's part of the problem. Lack of tech vision on the part of the authors. Maybe Marc was a liberal arts kind of guy rather than a Science guy.
Anyway, for the players I have (and have had over the years), using items supposedly several TL's above the present that are in fact, a couple behind current day doesn't cut it. So, I make it more realistic.

 

[BardicHeart]

I may write up my own house rules at some point once I feel I have a strong grasp of the MT rules. Course I'm also trying to find time to go over the TNE and T4 rules... and then will order T5... so I've got a lot to catch up on.

I don't fault Marc or others, predicting tech advancements isn't an easy thing to do (I still chuckle over a few of Bill Gates famous pronouncements... such as 486kb ought to be enough RAM for anyone :rofl: ). Given that much of it was written in the early 70s, I'm kind of surprised at the parts that came close to being right. Ultimately though, I keep in mind that Traveller is just a game and still one of the best Sci-fi games around (in my opinion anyway). I enjoy it for what it is, including the "flavor" in presents. Meanwhile I'm just enjoying reading things when time allows (working full time, plus writing a book, doesn't leave a lot of free time for Traveller and there is so much to read an catch up on).

 

[HG_B]

I don't fault Marc or others, predicting tech advancements isn't an easy thing to do

No prediction needed. They were way behind current tech when the rules in MT were written.

 

[aramis]

No prediction needed. They were way behind current tech when the rules in MT were written.

They might have been behind current tech, but not many in the civilian world really had a lot of access to the information when MT was written.

People forget how much easier it is to find information now than in 1986 (MT was an 87 release, figure most of the work was done in 86 due to production lead times).

The rise of the nets in the early 90's started increasing crowd-sourcing... and then in the mid 90's, the rise of the web made it orders of magnitude easier.

And being able to search the information people were making available... it's very easy to forget just how much access to information has changed.

 

[E.D.Quibell]

They might have been behind current tech, but not many in the civilian world really had a lot of access to the information when MT was written.

People forget how much easier it is to find information now than in 1986 (MT was an 87 release, figure most of the work was done in 86 due to production lead times).

The rise of the nets in the early 90's started increasing crowd-sourcing... and then in the mid 90's, the rise of the web made it orders of magnitude easier.

And being able to search the information people were making available... it's very easy to forget just how much access to information has changed.

I completly agree.

Just to add to Will's post please remember that Wikipedia is only 10 years old.

It's only in the 21st Centry when access to information across a vast array of topics has been at people's finger tips, so to speak, and it's only in the last 5 or so years that colletions have started to be digitised and the data within made available to a wider audiance.

Best regards,

Ewan

 

[HG_B]

They might have been behind current tech, but not many in the civilian world really had a lot of access to the information when MT was written.

Popular Science & Mechanics (among many other common pubs) covered this type of stuff VERY often. The mil was constantly blowing its own horn also. Air War board game (TSR?) came out in '77 and had very good spec info on MANY modern fighters.

Face it, it was written the way it was because the authors weren't science oriented. The data was VERY public as to general specs.

 

[aramis]

Popular Science & Mechanics (among many other common pubs) covered this type of stuff VERY often. The mil was constantly blowing its own horn also. Air War board game (TSR?) came out in '77 and had very good spec info on MANY modern fighters.

Face it, it was written the way it was because the authors weren't science oriented. The data was VERY public as to general specs.

No, you're applying a lot of mismemory.

I had subscriptions in the 80's to Pop-Sci and Pop-Mech, and Sci-Am, and read dad's ChemEngrProc... sensor acuity was one of those areas that,. while they oft mentioned new types of sensors, they seldom gave POD % nor maximum ranges.

Sure, in 1991, it mentioned the sensors on the F14G could maintain 24 locks and track 60 additional targets... but it never mentioned how long it took to acquire targets nor locks. The data provided wasn't good enough to model them with for game purposes. I know, I tried.

Likewise, they chose to ignore vector movement for playability reasons, not because they weren't science minded. Read the designer's notes.

The only set of sensor rules with sufficient background data to be truly useful and valid are Bruce A. Macintosh's (IIRTNC) Definitive Sensor Rules... which were written by an astronomer who also is a gearhead... and he had lots of data that most of us don't.

 

[HG_B]

No, you're applying a lot of mismemory.

Nope. I went over one of the articles with a friend in the A.F. around '79-81.