The active sensor is tiny. The STO design for the Commonwealth (from the Colonial Wars campaign) for a 25cm spinal laser is 507 tons. Of that, the active sensor is 5 tons, the static mount is 12 tons, the reactor is 40 tons, the fire control is 50 tons and the weapon is 400 tons.

The one big question I have is how does the cost (not size) scale when you extend the fire controls up to the maximum allowed in the late game. In VB, late game sniper laser ships tend to have most of their cost in the FC, even when they pack a lot of lasers per single FC. Does only using integrated FC make STO defences cost-prohibitive when your enemy can shoot at you from a million km away?

One unit doesnt neccesarily mean "one object" though, right? Like a brigade HQ is 500 tons, but that doesnt mean its a 500-ton vehicle?

Modern AAA/SAM systems are mobile and, as others pointed out, mounted on multiple vehicles. Generally there are 1-3 weapon platforms, 1-3 loader platforms (for missile systems, for cannon systems there are 1-2 ammunition vehicles), a fire control vehicle, and a support/mechanic vehicle. These systems rely on external other units to provide up-to-date area surveillance information, which can also be mobile, so you could add a search radar vehicle to the total count. Similarly, for Theatre Ballistic Missiles and Artillery Missiles, the systems are roughly similar: you have multiple launch vehicles, equal number of loader vehicles, and a command & control vehicle, plus supply/support vehicles.

I don't know how feasible it would be to code something like this in C# Aurora. Once you design an ground-based STO weapon, the game automatically creates a unit that includes reactor vehicle, gauss cannon vehicle, beam fire control vehicle, and then the player can adjust their numbers for that unit? Or just design each vehicle separately and group them together, like any other ground unit? How would that fit together with static units, do they need separate components as well? Can the game easily check that all necessary components/vehicles are in a unit, without creating undue memory/CPU usage?

On one hand, being able to put ship component to vehicles would neatly sidestep any special rules issues like we had with PDCs. But I don't know how "bad" it would be under the hood, and I've understood that Steve's one priority for C# has been to streamline the code and make it more uniform, ie as few special cases as possible.

Quote from: sloanjh on October 17, 2018, 08:07:53 AM

In fact that could be a tech line - vehicle payload - that would have to be incorporated into mobile ground versions of naval components.  I would recommend the size/cost of the vehicle scale non-linearly with payload (e.g. payload^1.5) to represent the fact that (probably) a single 100 ton dumptruck is more than 10x the size/cost of ten 10 ton dumptrucks.

This would be inconsistent with how size efficiency works for all other purposes. We wouldn't have larger Trucks, Container Ships or Airplanes IRL if there was no benefit in doing so, like increased payload per investment or reduced running cost per payload.

A truck/ship/plane that's twice as long in all directions have 4 times the surface area ( resistance from air/sea/ground ) and 8 times as much volume. ( Very simplified but basic physics go in this direction ).

The formulas in Aurora are similar, larger engines or ships are more efficient than smaller ones on a per ton basis.

The real limit on ground vehicles is usually the weight limit of bridges, as well as the size of tunnels, roads and railcars. Also, STO are all static mounts, so for transport they are broken down into parts which would likely be either their own specialty vehicles or fit onto standard trucks. You would have a fire control vehicle, generators fitting into containers that power a laser in a container, which then feeds the mirror turrets on their own platforms.
There is no need to build everything into a monolithic platform on the ground, especially when you want to set it up in cramped underground bunkers.

Two comments:

Yes, you make an interesting point. I started with the relatively simply idea of a weapon on the ground that could shoot into space. Then I added reactors, then fire control, then active sensors and I will probably need ECCM too. It is is becoming more detailed.

[SNIP]

One option I considered was to design a 'weapon mount' using the ship class design interface and make that an option for mounting on STO units. The formation element could then be a single ship with multiple weapons and fire controls, or a ground unit, depending on the context. That could then appear on the naval combat window. However, I am heading back down the PDC route then and would face the question of why other ship systems can't be in ground units. Currently STO is similar to CIWS in that it is an integrated system where design is automated. Also, it isn't completely straightforward in terms of integration with the naval combat window. BTW I know that isn't quite what you are suggesting - just a different way I could utilise existing code and mechanics.

I know you know that isn't quite what I'm suggesting, but for avoidance of doubt (to much contract-reading lately ):

I think the difference here is "why do all the systems need to be on a single vehicle"?  If you just have the concept of how many tons a vehicle can carry, then the components can be distributed.  In fact that could be a tech line - vehicle payload - that would have to be incorporated into mobile ground versions of naval components.  I would recommend the size/cost of the vehicle scale non-linearly with payload (e.g. payload^1.5) to represent the fact that (probably) a single 100 ton dumptruck is more than 10x the size/cost of ten 10 ton dumptrucks.  Or maybe the techline simply has a maximum size.  This dovetails nicely with your "weapons mount" idea - it morphs into "static ground fitting" (which might have zero cost/mass, since it's already built into the component) and "mobile ground fitting" which is the vehicle chassis.  This also fits well with modern AA missile units - I believe theirs typically a launcher vehicle, separate radar/fire control vehicle, separate command truck, reload truck etc., some/most of which are specially designed units.

As for "why can't other ship systems be in ground units" - let them (by default)!  You can restrict which system types have ground versions through the tech design window, and from a technobabble point of view if they want to put something on a truck or on the ground they can do so - if it doesn't make sense then it just gives them no value in gameplay.  In particular, I think ground-based missile launchers should be allowed, and let the chips fall where they will (in terms of balance).  I'm putting this in the same category as fighter weapons - this is a core physics consistency issue, and once the door is open to forbidding ground systems because of balance then it opens up a host of other decisions about every other component.

The automated route I am currently heading down presents the player with a list of his STO elements and requests targeting type and the number of weapons per target. This will be acted upon in normal naval combat to generate the combat results. It should not be difficult to code and maintain the distinction between ground and ship in this scenario. I already have PD code which picks up the ground-based CIWS and could be easily adapted to STO-PD weapons. The STO vs ships is also straightforward with the automated targeting. This keeps the ground units distinct and relatively simple while giving them a real role in naval combat.

I think the area where your solution creates the greatest benefit is for manual targeting. I am bouncing back and forth on whether to implement this in addition to the automated targeting. In that case, I probably could add an interface to the ground unit that effectively creates a 'fire control' object that can display on the naval combat window.

I'm also advocating that if there's an automated mode for ground units, there should be one for ships.  If they're following the same mechanics this should be easy.

Gotta run to work

John