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

Computers/Fire control for medium range ships (600-2000 dtons)

McPerth

SOC-14 5K
Admin Award
Administrator
Moderator
Peer of the Realm
When designing ships, I've always had problem for non-capital ships over 600 (understanding as non capital those built under CT:LBB2 or MgT:CB rules).

Let's imagine I design a 800 dton ship. It's equiped with 8 turrets and intended as a corvette.

In CT:LBB2, computer requirements:
  • maneuver/evade (let's say 5): 2 slots
  • anti-missile: 2 slots
  • ECM: 3 slots
  • target: 1 slot
  • launch: 1 slot
  • Gunner interact (x8, less if you don't use it for sandcasters, if it has any): 8 slots

So, without return fire, predict, selective, multiple target nor double fire (all of them quite useful programs that affect all offensive fire), you'd need 17 slots. You can forfeit gunner interact, but then your gunners won't modify the fire (see that prediction is per target, while gunner interact is per turret), but you save some slots.

That means you mínimum computer size would be 5 (without Gunner interact), 6 (gunner interact to all turrets but 2, asume they are sandcasters, where gunenr does not affect) or 7 if you want all turrets with gunner interact (and you have 3 more slots for the other programs told above).

Now imagine a 2000 dton ship with 20 turrets, that could not have gunner interact for all of them even with a model 7 computer (the highest shown in LBB2.

See that this same ship in HG rules, having a computer 4 would have a +/- 4 to all rolls. And the computer is the same (same cost and tonnage needed)...

In MgT CB rules (quite similar), you face a similar problem, as Fire Control program taks 5 rating per level, and, model 7 being again the máximum shown, your maximum rating is 35, so, even having 2 Fire Control/3 programs running at once (not clear if legal), you'll have a +1 for 6 turrets, having them firing automatically (with no modifier) or any combination (and then no evade nor auto-repair programs running). OTOH your gunners will always affect fire (no program required).

In MgT:HG, again, your Fire Control program will affect all you weaponry1, but, unlike CB rules, those are core computers, quite more powerful and expensive.

Note 1: at least that's how I understood it, while it's not clearly written, but, at least, if it can modify one of your barrages, it can affect all the turrets invovled on it, usually quite more than what CB rules allow)
.

So, as I see it, in both cases you have a problem for those medium sized ships that are too small to design with HG rules, but too large for the computer capacity to be able to cover all the turrets.
 
Last edited:
Well, you're underutilizing your computer.

The LBB2 computer rules state that you only use the appropriate program during it's appropriate phase, and it can otherwise be in storage.

So maneuver/evade, anti-missile, ECM and launch would be in storage when it is laser fire or return fire time freeing up 8 slots during your 'busy' time, anti-missile and ECM would go active and drop some other programs when dealing with the incoming missiles, don't need gunner interact for the return fire phase, launch gets loaded for ordnance phase, etc. etc.

My problem is similar but on a larger scale- how do you fight a 10,000 ton ship with spinal mounts LBB2 style with a Model/4 computer?

Part of the answer is to treat batteries as one gunner interact per battery rather then turret.

You could do that in an LBB2/non-HG game by simply slaving X turrets to one gunner, say the gunner interact handles all the assigned turrets, and rolling one attack chance for all of them at once.

Another is doing a cost-effectiveness analysis- if the gunner is level 1 and you have predicts running with higher 'skill', drop the gunner interact for those to give room for the predict to run. Boosts your experts for overall higher chances of hitting, and is more bang for the CPU for the rest.
 
You only need gunner interact once, you do not need it per turret.

Perhaps for later versions, the CT/LBB2 rule clearly states a gunner for a specific turret.

<shrug> IMTU can be that way of course and I may have to to make the computer model rules work, but he's right far as what the rule actually says.
 
CT:LBB2, page 38:

Gunner interact: interfaces the experience of the gunner in a specific turret to the hit probability (...)

Bold is original, underlining is mine
 
This refers to there being a gunner in the specific turret, not requiring you to run a program for each turret.

What it means is the skill of the gunner in that specific turret gets to add his skill.

A gunner in a different turret would use his skill etc.

Your interpretation could be applied to most of the software - a target program needed for each turret, a predict program for each turret etc.
 
Well, you're underutilizing your computer.

The LBB2 computer rules state that you only use the appropriate program during it's appropriate phase, and it can otherwise be in storage.

So maneuver/evade, anti-missile, ECM and launch would be in storage when it is laser fire or return fire time freeing up 8 slots during your 'busy' time, anti-missile and ECM would go active and drop some other programs when dealing with the incoming missiles, don't need gunner interact for the return fire phase, launch gets loaded for ordnance phase, etc. etc.

You're right in this, but the fact that a ship with many turrets needs a large computer just for the Turret interact (fire control in MgT) remains.

What I wanted to point is that the system works for small ships (let's say up to 600 dton), as HG works for large ships, but there is this range where CT2 does not work, while is under HG scale...

My problem is similar but on a larger scale- how do you fight a 10,000 ton ship with spinal mounts LBB2 style with a Model/4 computer?

If you want to use this ship in LBB2 rules you have greater problems:

  • LBB2 only reaches to 5000 dtons
  • No spinals are defined in LBB2

Part of the answer is to treat batteries as one gunner interact per battery rather then turret.

You could do that in an LBB2/non-HG game by simply slaving X turrets to one gunner, say the gunner interact handles all the assigned turrets, and rolling one attack chance for all of them at once.

I see you make quite a mixup among LBB2 and HG...

Another is doing a cost-effectiveness analysis- if the gunner is level 1 and you have predicts running with higher 'skill', drop the gunner interact for those to give room for the predict to run. Boosts your experts for overall higher chances of hitting, and is more bang for the CPU for the rest.

Predict is usually better than Gunner interact, as it affects all turrets firing this target, but why do you want gunners with good skill if your computer does not allow them to affect the outcome?

BTW, as Guner interact is explained in LBB2, only lasers seem to be affected (logical that sandcasters are not, but it seems neither missiles are).

Buy another computer. If you need one dedicated to fire control, then get one of those.

I always considered this (as using more computers in MT to be able to process more CPs) as cheataing the system. After all, rules say you can have other computers, but as back-ups. I guess the fire control computer must be so connected to other systems (power, maneuver, etc...) that it must all be in the same computer.

In MgT:HG, is told there are many computers , on the line you say, and the core computer is just the coordinating one, hence their higher prices.

In CT:HG you can asume things are like in MgT:HG, but the computers are identical in Price (and size) to the ones for smaller ships.
 
You're right in this, but the fact that a ship with many turrets needs a large computer just for the Turret interact (fire control in MgT) remains.

What I wanted to point is that the system works for small ships (let's say up to 600 dton), as HG works for large ships, but there is this range where CT2 does not work, while is under HG scale...

I think it can work for the bigger boats, but you'll be buying Model 7s not 4s.

Assuming Wightman is right in his interpretation, definitely so.

Bigger HG ships with say 25 batteries of anti-missile/small ship laser? Eh, going to take some work.


If you want to use this ship in LBB2 rules you have greater problems:

  • LBB2 only reaches to 5000 dtons
  • No spinals are defined in LBB2

I made my intent clear with my project, full mashup of both. I expect many people don't believe me.


I see you make quite a mixup among LBB2 and HG...

That's not really the system I am working towards, just a quickie rule for those inclined to just stay within LBB2 bounds but add an easy fire control option.


Predict is usually better than Gunner interact, as it affects all turrets firing this target, but why do you want gunners with good skill if your computer does not allow them to affect the outcome?

Huh?

No, I'm saying that if you have the computing cost of Gunnery-2 or below greater due to per turret use of Gunner Interact, that you would be better off using Predict-3 and leaving the GI in only for Gunnery-3 or above.

Then your premier gunners get predict and skill bonus, and the poorer gunners get only the predict bonus which is still as good as what they were going to get with GI.

If Gunner Interact only requires one copy to service all turrets, this point is moot.


I always considered this (as using more computers in MT to be able to process more CPs) as cheataing the system. After all, rules say you can have other computers, but as back-ups. I guess the fire control computer must be so connected to other systems (power, maneuver, etc...) that it must all be in the same computer.

I agree, only one machine in use at a time. The firing weapons have to know their precise location in space in order to line up properly on the target, which means they have to be tied in realtime to maneuver and astrogation and engineering, even .1 second of communications latency in processing updates between the machines would throw off the calcs and likely generate a miss.
 
I agree, only one machine in use at a time. The firing weapons have to know their precise location in space in order to line up properly on the target, which means they have to be tied in realtime to maneuver and astrogation and engineering, even .1 second of communications latency in processing updates between the machines would throw off the calcs and likely generate a miss.

Absolute nonsense. There is always latency, and it must always be compensated for. Additional latency is readily compensated once accounted for. Want less latency? Put the computers next to each other. That's what the high speed traders do. Your 10K Dton ship is going to be a hive of latency.

They're computers, not Orbs of Turret Pointing. There are all sorts of issues that have to be dealt with (turret acceleration, friction, transit and seek times, etc. etc.) Adding a computer doesn't over complicate anything or break the 4th wall.
 
Absolute nonsense. There is always latency, and it must always be compensated for. Additional latency is readily compensated once accounted for. Want less latency? Put the computers next to each other. That's what the high speed traders do. Your 10K Dton ship is going to be a hive of latency.

They're computers, not Orbs of Turret Pointing. There are all sorts of issues that have to be dealt with (turret acceleration, friction, transit and seek times, etc. etc.) Adding a computer doesn't over complicate anything or break the 4th wall.

I'm well aware of latency issues and what can be done with linking, being quite familiar with Parallel Sysplex on mainframe computers, loosely coupled OR tightly coupled. I work with this feature on a professional basis, several LPARs across several machines, although I do not architect or manage the Coupling Facility.

It's one of the big reasons why the death of the mainframe has been greatly exaggerated.

https://en.wikipedia.org/wiki/IBM_Parallel_Sysplex

Before that, my site has had decades of experience with interface engines between disparate systems. So I was fiddling with linked AND virtual machine ship computer rules back in the 80s.

My sense of the problem set of fire control at 2 LS plus ranges is that you cannot even tolerate 100ms of update delay between machines. Big difference between that and sub-1-second financial transactions, which last I heard was something like 600ms between machines.

Your point about the larger ships being delayed simply pulling in engineering and sensor data and sending out fire control updates is well taken, but to me that makes the speed of the central system that much more crucial.

There is a faster technology to handle that situation, and that is to have your link be at the memory level. This is a sort of connection where one mainframe may have several Linux webserving LPARs needing to interact with the core z/OS LPAR that hosts the backend database.

In that case you use virtual adapters with shared memory on the same machine.

http://www-01.ibm.com/support/knowledgecenter/P8DEA/p8hat/p8hat_virtualadapters.htm

Not precisely helpful to our game scenario, but you take it one further, wed the two machines with shared memory and you get serious speed gains.

Burroughs did a lot of that sort of thing, frankenstein monster machines with CPUs and auxiliary processors we would bring online, then offline to be test and maintenance machines on a daily basis.

https://books.google.com/books?id=J...&q=burroughs auxiliary processor 5900&f=false

At that point though you are effectively creating whole new models of machines. Might as well trash the whole model table and restart, or perhaps define dedicated machines that are not general purpose but hardwired to their task, like a gunnery computer.

The other way I could see beating the latency issue is if quantum entanglement allowing for short range FTL communication becomes a thing.

Presently it is understood and experimentally tested that it cannot be, but that understanding could change.

https://en.wikipedia.org/wiki/No-communication_theorem
 
Now to the OP's original problem, let's assume that we have a Type C 'cruiser', a pretty typical machine, that needs to go to combat.

With the generic type you get a Model/5 computer, 12 CPU 25 Storage.

We can assume with the phasing that only the offensive laser fire progams are the stress point, that there is plenty of room for everything else (barring loading every single jump program 'just in case').

Predict-5 2
Target 1
Multi-Target 1
Select-3 1
Double Fire 1
Anti Hijack 1

There, 2 targets possible, with maxed out advantages and anti hijack constantly running so turncoat saboteurs cannot take advantage of the system being dedicated to firing.

That's 7, leaving 5 for whatever we do with Gunner Interact.

If we interpret it Wightman's way we run one instance of GI, done deal.

If we take it the OP way, there are only 5 slots available to support 5 gunners and 5 turrets, which may or may not be a problem.

One could easily see 2-3 dedicated missile/sand turrets that would use the launch program during the launch phase, have dedicated gunners firing and reloading them, and not require GI at all.

You could go my way, say 8 laser turrets, 3 are assigned to the top ace with Gunnery-4, 4 get GI too because they have Gunnery-2 skill, and the Gunnery-1 goes without GI and gets only the predict mod.

You could also drop the nice to have Select, M-T and DF. Probably a good idea to not be using DF past 2-3 shots anyway.

Might be tighter even if you rule that a Predict program has to be running per target.

Errata has no clarification.

My gut feeling is that the intent is one GI per gunner per turret, as the whole set of computer rules seems to be all about how you would like to do everything at once, but have to make wrenching resource choices.

For the 2000 ton ship, we can bump up to Model/7 and get 20 CPU program slots. That means with the above program mix you can get 13 turrets with GI.

I don't know what your ordnance/laser mix philosophy is OP, but it wouldn't be unreasonable to have at least 5 dedicated missile/sand turrets on such a ship, leaving just 2 laser turrets without GI.
 
The problem set of fire control at 2 LS plus ranges is that you cannot even tolerate 100ms of update delay between machines.

That's not the problem, in fact this is why latency is really not an issue, as long as it's predictable (i.e. you synchronize your computer and systems and the have an inherent knowledge of the latencies involved). If it's predictable it can be compensated for.

You may be targeting something at 2 LS, and that targets tangential velocity may be something like 16000m/s, thus a 100ms is 1600m. So, you may see that 100ms of latency messes up your firing solution by 1600m (clearly a miss).

But here's the trick. While your internal hardware may suffer ms latency (which can be compensated for), and while the target is moving at velocities where "ms matter", the nut of it is simply that the target can not RESPOND at ms intervals. While the weapons work in a world of ms, the ships don't fly or react in such a world. You can't maneuver a ship in 100ms. You can apply acceleration, but the sensors can see that.

This ships firing solution isn't based on a ms latencies, at a 2 LS range, it's based on predicting where the ship will be 2 seconds from now on 4 second old data. If you have 100ms of latency, then it's 2.1 seconds from now. And ships don't change course that much in 2-4 seconds. They're basically ballistic. And if you compare their current vector, with a projection of where they might be if they apply a few seconds of thrust, you'll get a window of where they will be.

Despite fiction stating otherwise, ships can not evade, not in the millisecond and seconds windows that matter for a light speed fire solution. They can pulse their motors, slightly changing velocity, but you can detect that, and expand the window. And BIG ships simply can't even get out of their own way.

But if they want to TURN, they have to MOVE the ship (using little, low G thrusters that the game doesn't even acknowledge), or perhaps gimbaling their motors (if in fact they even do that), and even then, they have to burning to do it. Moving the ship takes time. In the light speed world, it takes a LOT of time. If a ship isn't under power, then it's a dead duck if you have sensors on it, latency is extra meaningless in those scenarios. Remember, you can't just twitch an aileron and get quick motion out of a starship, you have to apply directional acceleration to turn and stop these things.

So, all of that inner latency in planning, staging, and executing the firing solution can be compensated for within that firing solution. 100ms old sensor data isn't old enough to really change the outcome, frankly. And once you're tracking, the math gets simpler and the solutions come faster.

The other way I could see beating the latency issue is if quantum entanglement allowing for short range FTL communication becomes a thing.

Presently it is understood and experimentally tested that it cannot be, but that understanding could change.

A good hand wavium as to why higher TL firing systems can be more accurate than lower tech level systems.
 
TAS form 3 - ship data sheet.

You either have gunner interact and check the box or you don't.

You do not need more than one gunner interact program.

If you have 4 turrets in a 400t ship the program allows the gunner in each specific turret to add his skill DM - that is how it works.

Another point of reference is Mayday, which has very similar computer rules to LBB2 combat and also has a gunnery (interact) program that you only need one of.
 
Last edited:
@whartung: Regardless the logic it can be to all your technical talk about computers (quite above my computer skill), fact is that no provision for multiple computers is in CT, and all the references are to "the" computer, hinting each ship has only one. Of course, you can house rule otherwise if you like (and if you find them more logical)...

TAS form 3 - ship data sheet.

You either have gunner interact and check the box or you don't.

You do not need more than one gunner interact program.

If you have 4 turrets in a 400t ship the program allows the gunner in each specific turret to add his skill DM - that is how it works.

TAS form 3 just points if you have it or not. You don't need more tan one but the same program may have to be run simulteneously for every turret, and the meaning of the words the gunner in a specific turret seem to me to mean a specific gunner (otherwise, I guess it should be something as each gunner in his specific turret or every gunner , or simply gunners, or the gunner in each specific turret, as you say.)

Another point of reference is Mayday, which has very similar computer rules to LBB2 combat and also has a gunnery (interact) program that you only need one of.

Mayday, page 10:

Guner interact: allows the onboard laser gunner (...)

It seems to asume only one laser gunner, not specifying anything in case of multiple ones...
 
The gunner in a specific turret gets to add his skill, the gunner in a different specific turret gets to add his to his turret weapons, it is pretty straightforward. You need one copy of the program.
 
The gunner in a specific turret gets to add his skill, the gunner in a different specific turret gets to add his to his turret weapons, it is pretty straightforward. You need one copy of the program.

So, as you say, when it says the gunner in a specific turret it means all gunners, each in his specific turret...

Then, if a policeman says he will stop the driver in a specific car to check its alcoholemia, it means he will stop all drivers, each in his specific car to check it...

I understand it means (in both cases) only one specific gunnre (or driver) will be affected. But you're the native English speaker, not me...
 
Last edited:
It is to stop a player/NPC trying to argue they can man more than one turret - the gunner must be in a specific turret.

Note that the spaces available for even the model 7 computer don't allow you to run every offensive, utility and defensive program (nearly all but not quite - you still must make choices). Lower models of computer must be even more trade offs. The model 1 and 2 computers would have difficulty running offensive and defensive programs at the same time (which may be important thanks to the laser return fire phase...)
 
Have to disagree Whartung, but then again you may have missed my take in previous postings on what a Traveller 'miss' is, especially generated by the evade program.

The ships are moving too slowly and predictably for misses to be anything but a matter of meters off, or hits that do not seriously damage.

Towards that end to execute successful evades I think the ships are maneuvering with heavy use of roll pitch and yaw plus some moves 'up' or 'down' relative to the plane between firing ships and the target.

Those are matters of meters to move rather then attempting to seriously alter the main heading or velocity, and well within the 4 second window.

Agility would be situations where the main M-drive is committed to evasion in addition to the attitude thrusters, providing 10m per second per G rating

A miss also doesn't have to be a clean miss, having the ship be on an unexpected roll spreading the hit across many more square meters of hull or hitting the edge of the ship such that sloped armor effects start occurring can avoid damage.

And of course we aren't even delving into EW/countermeasures, again you don't need to obscure or stealth, just throw off the solution by meters.

Under those circumstances I think the 100ms counts in large amounts.
 
It is to stop a player/NPC trying to argue they can man more than one turret - the gunner must be in a specific turret.

Note that the spaces available for even the model 7 computer don't allow you to run every offensive, utility and defensive program (nearly all but not quite - you still must make choices). Lower models of computer must be even more trade offs. The model 1 and 2 computers would have difficulty running offensive and defensive programs at the same time (which may be important thanks to the laser return fire phase...)


Have to disagree, I'll come back and do the math later, but I think using your interpretation you don't need anything bigger then a Model/5, ever, other then hull size requirements.
 
Back
Top