I like this idea in principle - my concerns are around the implementation and the intuitiveness for players in terms of what refits will work in which shipyard. I can see a way to write the code to figure out what systems the shipyard could refit, although it could be open to abuse. In the examples above you are comparing relatively similar ships but if a shipyard can build an engine for a small warship, could it therefore swap the engines on a dreadnought? Is swapping the missile launchers on a destroyer the same as on a much larger warship. I guess this would be restricted by the size of the shipyard. However, in real life two ships could be radically different but share similar systems and upgrading those systems might require completely different approaches. In the New Jersey example above, any shipyard that could add a particular system to an Arleigh Burke might not be able to easily add that same system to the BB without additional setup work or training for that shipyard. In game terms, there would still have to some limits on the flexibility of upgrading within a certain shipyard and defining/coding those limitations could be tricky.
I agree on the potential for exploits/weirdness. The example that came to mind was the VLS cells in a Burke DD - to fit them to a BB you'd probably have to use strange techniques to cut big holes in the deck. After thinking about this though, I think that the same problem is probably already present with the current refit system - if one already had a class that looked like a Burke but had rail launchers rather than VLS (call it the Able class), then the current mechanism would allow you to cut holes in the deck of an Able to upgrade to a Burke. The difference is that you would now be able to also cut those holes in the deck of an old Kidd-class to do the upgrade (all assuming that VLS is cheap enough to not trigger a retooling, of course). The point I'm groping for here is that such major work would probably cost more than the retool limit, and if it doesn't it's already allowed using the current system. The sorts of changes that are allowed in a retooling feel more like e.g. adding Harpoon box launchers.
Maybe a simple way to account for the "additional setup work or training" that you mention would be to add a e.g. 50% surcharge to the cost or the refit if the target class can't be built by the SY. So if the Able-->Burke upgrade above cost 100 build points, upgrading a Coontz-->Coontz VLS or a New Jersey --> New Jersey VLS might cost 150 BP, since the SY is tooled to build Burkes but not Coontz VLS or New Jersey VLS.
BTW, this brings up a different suggestion that I've wanted for a while. It would be nice to be able to query "if I retool a SY to produce this class, could it also produce this other class" without actually doing the retool :-)
BTW, are you assuming this would work be alongside the existing refit system or replace it?
I think that, given the way I phrased it, any refit that can presently be done by a SY would be doable with the new system. So in terms of game play I guess this would be "alongside" (i.e. it's allowing additional refits) but from coding it would probably end up replacing the current system. If you jiggle with the definition, though, all bets are off - I'm neutral on the subject.
Note that this mechanism is definitely "alongside" the "what can the SY build" question. The "build" question involves two class types (the tooled class and the built class). The proposed "refit" question involves three class types - the tooled class, the "from" class (e.g. New Jersey 1950) and the "to" class (e.g. New Jersey 1980).
John
PS - Welcome Back!!
