There is also a chance to refactor the struct. It would be possible to place the common elements in the beginning of the struct, with the specializations at the end in a separate struct. Then the common code can use pointers to the base struct, while the specialized code uses pointers to the specialized struct. This is a more significant refactoring job that just ignoring the unused members though.
I'm not sure why the UFO yard can't be handled by the existing struct though. We may need a new "building" type, but other than that I don't see a problem, TBH. Also we would need to modify the member
map to be a
baseBuildingTile_t * and dynamically allocate the array based on the required number of rows and columns. So a UFO yard could theoretically be a very large installation! Similarly, a SAM site may be a 3x2 or 3x3 base with only a few preset buildings inside it. That change will probably generate some serious errors, but thankfully those are the sort that the compiler is good at catching.
It's important to note that although this approach makes off-base and base installations identical to the code, this will be mostly hidden from the user. I would like to see the off-base installation management completely automated.