I think, with some small modifications to the above function, parse_ship(), and an additional structure to hold extra flag info, we could create a "hull scan" flag that could be put into the table for ships where you want to be able to scan the entire ship not just the subsystems. The resulting function could look something like:
if (cargo_sip->flags & SIF_HUGE_SHIP && !strstr(extra_flags[cargo_sp->ship_info_index].flags,"HULL_SCAN")) {
return player_inspect_cap_subsys_cargo(frametime, outstr);
}
Then, to enable a ship itself to be scanned rather then it's subsystems you would add an entry to ships.tbl like this:
$Extra_Flags: HULL_SCAN
I'm not completely sure that the ship_info_index is the right variable to use to compare against the list that would be stored in extra_flags though. Ideally the order of the ships in the two lists (one containing all the regular info for a ship type and the other containing the extra info) should be the same so they would have the same indexes. I'm assuming, from what I've been looking at in the source code, that Ship_info is the structure array that basically stores all the ships.tb info. The extra_flags structure would (at the moment) just contain a char [255] for storing the extra flag data. (Don't know enough about the bitwise shift operators to store the flags in an int as is done for the regular flags. A char string is a little easier to use since there is a function designed to stuff strings with data from a table. A char string could also be expanded as needed while an int has a fixed size.)
What I don't know is if this would affect network play at all. And none of this has actually been tested since I've been looking at an old original copy of the source code and don't have a current copy of the fs2_open code. (Assuming it can still be compiled with GCC.)