Starwaster

Yeah, I know about that one. Not sure why it's happening. I think that stock KSP might be trying to destroy the part not knowing that I already did so. OR part.explode is being called multiple times... Might have to find another way to destroy it. (though if it's the second one then I could designate it internally as having been destroyed or about to be destroyed and then check for that when I go to explode the part)

Ok just took a look at @Tokamak's configs for the FLAT The three ports are configured with deployAnimationController = 1 which is not going to work. That number has to point at the index location of the animator module. 0 = first so 1 = second, which just so happens to be the second docking port and not an animator at all. Furthermore, he's using a modded animator and not the stock ModuleAnimateGeneric. That is also not going to work unless USIAnimation uses ModuleAnimateGeneric as a parent. The reason for that is because when ModuleDockingPort tries to retrieve the animator it's going to try to cast to ModuleAnimateGeneric which will fail big time. (checked USI while writing this. USIAnimation is written from scratch and uses totally different field names. CANNOT cast it to MAG) One of the following things has to happen here or this isn't going to work: Switch back to using ModuleAnimateGeneric or an animator derived from it AND fix the indexing to point to the animator Don't use deployAnimationController. This is probably a bad solution because then it will be possible to attempt docking of deflated FLATs. Which may or may not fail because of the closed shields getting in the way. And even IF successfully docked, inflation of the FLAT will not move any docked vessel. The FLAT will then be in danger of engulfing docked vessels or docked FLATs. Physics hilarity will ensue. (of course, one could just pin the blame for that on the player. When they stop doing that it will stop hurting)

@dlrk I can't do anything on only that log fragment. It doesn't mention DRE anywhere - I need to see the whole log.

@thiagohdf The example you gave doesn't seem to demonstrate the problem. You wanted to end up with a part with ModuleRCSFX and that's what you got. With all the configuration changes you wanted to add in.

That's good to know. I usually turn that off on my chutes

Deadly Reentry v7.5.0 Commented out StrutConnector fixes. (StrutConnector changes? Have to monitor strut situation and see if original problem still exists) Fixes to RSSROConfig handling Added ModuleTransform2Value (works like ModuleAnimation2Value except that the value depends on the state (active/inactive) of a designated mesh object) (all chutes use this now both stock and RC) Added framework configurng max/operation temp values inModuleAeroReentry This is marked as pre-release meaning it won't show up on CKAN yet. until I turn that off Download link to DRE 7.5.0 pre-release

It would probably conflict with what I've already done. I'll put something out later today; it'll just have to be without the spaceplane specific changes that I wanted.

Ok had to shut off phone as a movie was starting. Arming option is what you want but I'm not sure how that behaves if 'must go down' is checked, you're going up, arm and then going down but conditions no longer met... not sure if that's been checked out.

@doktorstick you have to enable the option where staging arms them. In your case I'm not sure it would have helped. More later

Right click the FLAT for the context menu. There should be three buttons for targeting (or controlling from) the port. That's how the part worked originally.

Except that what you would really be doing is 'blacklisting' part of the GameDatabase with a needless restriction just because Squad is using those nodes to write part of an external file? There needs to be a better reason than that. It needs to be demonstratably harmful and that neutering part of MM's functionality is more preferable than submitting a bug report to Squad to fix the behavior in question

Woefully inadequate information. Logs, logs, logs!

From a practical standpoint, yes. Impractically, can you achieve escape velocity before reaching altitude/atmospheric pressure that renders it impossible to deploy the chutes? (have to configure them for a high altitude and 'must go down' has to be disabled on that chute as well). There's other ways you might do it... (be orbital then set up an escape trajectory that carries you back into the atmosphere low enough to deploy the chute) If you can do that then you can fulfill that contract. The chute would almost certainly fail so you'd have to have a backup. Practically speaking though, it seems unlikely that you're going to fulfill that contract... but there's nothing hard coded there that would prevent it.

Sorry, but it's not going to happen. Consider that contract hosed. Looking over configurations, can maybe try releasing with configs pulled from latest stock chutes but I don't even know if those guarantee sane chute contracts.

Apologies for late reply and not sure how important this really is except as a point of trivia maybe but: Saturn tank thickness actually weren't uniform. It varied being thicker at the bottom. (Stress, again) not sure how much of that was actual wall thickness vs reinforcement. I'd post some links to relevant documents but I'm on my phone, at the mall wrapping presents for the cat shelter

@linuxgurugamer yes it's doable, mostly. Adding ablative to one side would require an extension to the stock ModuleAblator. And a thermal equivalent to drag cubes to be implemented. (Possibly the 'cubes' alone might be sufficient)

Depends on the craft. Lots of parts in stock have extremely generous maxTemp and one of the things DR does is scale them back. Make sure everything is shielded properly and you'll be ok. Probably. YMMV

Then come up with a better system, code it and do a pull request.

Maybe in the patch he's working on but he hasn't merged any of his changes into the repository yet. Which means that the boiloff code he's reintegrating isn't merged yet either

TF support code was removed. I'm assuming it will get added back in at some point but for right now there is no TestFlight integration at all. Edit: nvm; not merged yet

It's a little more complicated than that. Doing it based purely on volume might not be the best way but it takes into account structure requirements: Tank mass isn't just a matter of knowing how large the tank is: You also need to know how much mass the tank has to support. Both its own and the mass of the propellant. If propellant tank masses were only dependent on the tank's surface area then the mass ratio would follow curve as tank size increases but instead it's more linear. Short answer is that tank mass calculations are abstracted.

Ok guys, this has been said about 69,105 times already but Layered Animations is obsolete and no longer required or used by anything because the stock animator module provides that layer support. Previous page has a patch by @Deimos Rast to make Habitat Pack compatible with KSP 1.2.*

No pressure, Starwaster... No pressure

As you say, It would also help if they failed at a much lower temperature. Their current failure point is 2700 K. That's close to (but not quite at) Apollo's heat shield surface temperatures. Which is fine for an ablative shield that's getting reduced to char and shedding its heat through ablation. To keep radiators from being so OP they should have lower maxTemp and they should lose the thermalMassModifier as well. The combination turns them into heat sinks and not just radiators. Really, an across the board rebalancing of maxTemps needs to be done. Maybe not to the same level of Deadly Reentry or Realism Overhaul. Baby steps after all, but maxTemps really need to come down a bit for a lot of parts.

If it were not this way then radiators would be so OP as to render heat shields unnecessary. That's fact not speculation. They used to behave that way before and had to be changed I dont agree with the solution because external conditions should only affect how radiators shed heat not whether it can be moved around internally. If that were true irl then refrigerators, which move heat from a cooler part to a hotter one, would not be possible. They do that even if external temps are hotter than internal.