turks

Please just calm down and let it be. Ragzilla coded a C# project so that people like me can just download this, which is even simpler than modifying a cfg! It is a bad precedent to allow a mod to install itself without user consent, even if it did literally nothing. What do you even have to gain by arguing here? You had an opportunity to be the adult and blew it.

Everyone who is defending ModStatistics because it's harmless, shouldn't you at least be ok with this mod because it is also harmless? Why is everyone making so much effort to defend modstatistics? What are you worried will happen if people install StillBetterThanSpyware? All of this yelling and screaming could stop if you just let this be, just let StillBetterThanSpyware exist and quietly do it's thing of being an easier way of removing a mod than going through 5 or 10 or 50 odd folders for other mods to make sure ModStatistics isn't there. If you're worried that making it opt in would mean nobody would use it, I think this whole rigmarole has proven that plenty of people are fine with it. When the dust has settled you might find making it opt in would have ended in more people using it.

I do think the hardest part of implementing this would probably be deciding when to join parts together for complex structures such as this, but it shouldn't be impossible. I assume this is joined together with docking ports? If so then the rules already outlined by myself and Syx would handle it properly. What I'm proposing isn't quite the same as this, since the objects remain separate in every sense except physics interactions, so there's no joining meshes to create a single object (which is super easy with rectangular prisms but maybe not so much with complex shapes). This can preserve destruction of individual objects, although doing so would necessitate recalculating the base structure for physics interactions.

Well, each part would be physically moved as part of a whole but could retain its own hitbox perhaps? I'm not sure how KSP handles physics but if all it needs it mass and center of mass (although you wouldn't get rotational inertia from that so I dunno) then it wouldn't be too hard to recalculate after a part is destroyed. If the rotational inertia is calculated by simply assuming a constant density of each part (probably how I would do it) then there'd need to be some new calculations to take care of that, but it shouldn't be too hard I think. The physics engine would basically be calculating this anyway in order to do its thing, this way it only needs to be calculated once then treated as a rigid body.

Apologies if this has been suggested already but I didn't see it in the already suggested list. I also feel like this is the sort of thing which probably would have been implemented if it was easy but no harm in checking right? My idea is to cut down on the number of physics calculations the game needs to compute for very large structures by having small and light parts be rigidly connected to any heavy parts they're connected to, such that they're treated as a single physics object. I'm not sure what the best ratio for deciding when this occurs would be (maybe 3:1 or 5:1) but it would be ideal to scale the effect so that it occurs more strongly the more parts are having physics modelling applied to them. The only downside I can see to this is that if a collision occurs the spectacular spray of debris would be much smaller, with larger chunks coming off. For the sake of some degree of realism (and also probably for stability of the game engine) this effect would have to not apply through docking ports or any kind of stage separation or struts. Any problems with this? I can't help but feel like I'm missing something obvious or else this is really hard to do for some reason.