I think that more needs to be added to the equation.
Right now server admins can change the number of points that are added or subtracted based on block facings. This is good, but it really favors larger ships and punishes smaller ships. I think the NUMBER of groups and the size of the reactor also matters. For example, it might be possible for a reactor with 25 blocks to have 5 groups of a system (in any shape) with no integrity instability. Then a reactor of 250 reactors might be able to have 25 groups (in any shape) with no drawbacks. So I think the scale should be based on reactor size. But then each individual group would also be "rated", as it is now, by adding facings together and such, but the scale of what is considered "spaghetti" would change depending on the size of the reactor. For example, perhaps an equation is applied to all values that would increase penalties and decreases additions for more cubic groupings the larger the ship is. This way a small ship of 25 reactors might have 10 groups of lines, and thus suffers an integrity stability penalty, but a larger ship with a reactor of 250 power reactors suffer the SAME penalty with 50 groups of lines which are 2 wide apiece. (I did not work out the scale math there, but you get the drift). On a small ship, what is considered "spaghetti" is smaller than what is "spaghetti" on a larger ship, so the equation of bonuses needs to follow this scaling. I hope this makes sense.
So to sum up, if we want to discourage "spaghetti" ships, what can be considered spaghetti is relative to the size of the reactor. It is also expected that larger ships will contain more parts scattered about because granularity of appearance and functionality demands change. A larger system may very well simply have more thruster groups added for appearance compared to a smaller ship. It may very well have more guns in different locations.
But even so, then we must consider different systems. For example, a power core probably SHOULDN'T have 500 strands, should it? But a salvage array sure should expect to, right? So there needs to be modifiers for each type of system or block type. Perhaps integrity can be turned off completely for a block type. Or perhaps a granularity is set in how the integrity check is made for that system. For example, with salvagers perhaps any block of the same type found within 2 out blocks is considered to be touching facing. So a waffle of salvagers would appear to be, for all intents and purposes, a solid block of salvage modules. Since it would follow the same scaling as the base integrity, a person might then have some groups of salvage waffles in different parts of their ship for creative purposes, and this would be just fine too.
But all of this said, I have noticed that when attacking an enemy ship, something about integrity causes EXTREME LAG which makes the game unplayable. I do not know if it is the blocks having damage applied, or the changes to integrity calculations. So perhaps a simpler system is best. Maybe the game would use the total block count of the system vs dimensions, again following a scale based on reactor size. So if a system was too spread out and didn't have the block count to justify it, then it would suffer a penalty. But this could then be adjusted so it only affects ships that are "too spaghetti". There could be a minimum percentage of dimensions based on reactor size where it doesn't matter how few or many blocks there are in each system. So for example, let's say a reactor of 25 might allow a system to be spread out 25 blocks from each other, and could be placed in any order. A 250 reactor would allow up to 100. A 2,500 reactor might allow 400 distance between the blocks. Then as block damage occurs, the integrity calculation would not need to be recalculated until the reactor is rebooted. This would eliminate any combat lag that is currently induced by the constant recalculating of integrity, and would also make it possible to predictably avoid integrity damage to blocks (which is the other possible culprit of this kind of combat lag).
smaal ships suffer bad integrity when designed to look good
smaal ships suffer bad integrity when designed to look good
