FieryBull

I'm excited about the development process. I always loved games where the developers take our input into account to further the game. Like Factorio and Minecraft. For me, new version releases bring about the same feeling as unwrapping gifts when we were young.

Both the HG-5 and the HG-20 have problems. I suspect it's a long lasting problem that was dismissed in 2019: HG-5 and HG-20 antennas incompatible with Procedural Fairings · Issue #554 · PorktoberRevolution/ReStocked (github.com). Yes, this "bug" was about procedural fairings, but I believe the same problem occurs with the stock fairings, and it was never fixed. Or maybe it was fixed at some point, I don't know since I haven't used Restocked between 2019 and now. According to an old developer article, the bays and fairings use the visual center to determine if an object is protected from the atmosphere or not: I'm assuming they're still using the same algorithm, I could be totally wrong. The issue is that both of those deployable antennas offers variants with a radial and axial version, and the game uses the complete model hierarchy to determine the center. In that situation, I think the variants weren't designed to have the centroid change drastically between alternatives. Here is what the 3D model with its full hierarchy activated looks like in its retracted and then extended state: If the variants were considered on their own, there would be no issues for the fairing containment, because the visual center would be correct. But the game seems to load all the hierarchy at once, and the center becomes the center of all of them, which is wrong for individual variants. In this example image, I chose radial as the variant, and this is roughly how the visual center will be situated. (because the game uses the center of all the variants active at the same time) For drag cube generation, a similar issue. A deployable antenna expects two drag cube, one named RETRACTED, and the other one named EXTENDED_A. When you have variants in addition, the game generates a drag cube for each variant. So for those two antennas, you end up with 6 drag cube: RETRACTED EXTENDED_A 0 1 2 3 The RETRACTED and EXTENDED_A cubes are generated with the whole model hierarchy active, which is wrong, since you have the drag of essentially 4 antennas instead of one. The numbered drag cubes are generated from the extended state of each individual variant. There is no drag cube generated for the individual variants in the retracted state, so it cannot possibly be correct. I suspect the module for deployable antennas wasn't designed for multiple variants. Here are the default drag cubes generated: The two big bounding boxes are the RETRACTED and EXTENDED_A drag cubes. The 4 other small ones are the variants cubes (0, 1, 2, 3). I'm showing the model before the deploy animation has played in the first picture, and after it has played in the second picture. So the first one is the retracted state, and the second image is the extended state. For this system to correctly work, the game would have to generate and use a retracted and extended cube for each variants. For example, we'd need 0_RETRACTED, 0_EXTENDED, 1_RETRACTED, 1_EXTENDED, 2_RETRACTED, 2_EXTENDED, 3_RETRACTED, 3_EXTENDED. But alas, the stock code doesn't support this. As it stands right now, the game seems to weigh both the drag cube of the antenna state (retracted/extended) AND the variant drag cube (in its extended state only). What can be done to fix the situation? I think custom code is needed if we really want a perfect solution. Otherwise, we need separate parts, we can't have axial and radial as variants in the same part. Okay, I'm done for now. Reading my post again, I don't feel like I've done a very good job trying to explain the problem, and I'm sorry for that.

That explains it. Thank you.

Am I the only one who can only extend/retract SCANsat parts while in the VAB scene? In the flight scene I can't. There also doesn't seem to be actions available to extend/retract. This is in KSP 1.10 using SCANsat version 20.2