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.
![Wink ;)](http://ufoai.ninex.info/forum/Smileys/default/wink.gif)
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.