Starwaster

BTW, I didn't mean to imply that either RSB or Stockalike Engines were deficient in their configs, it's more a case of them interacting in unexpected ways because the upper stages are configured with command capabilities which confuses Stockalike's conversion process. (it actually makes sense that they should have remote capability on those stages) Though RSB is a little spartan in its propellant quantities

For the most part I think it should but I haven't used the 64k mod. RO scaling might be a little overpowered but not by too much? Maybe some other 64k users can sound off here on their experiences with RO + 64k? Oh and I didn't say this before but RSB parts actually have too little propellant volume by about half the way you're currently using them (RSB + stockalike fallbacks)

Ok, I did a little digging: The only real support for the tanks is in RO. RF does not have its own support for those tanks (and of course, none for pretty much any engine) the RF Stockalike configs don't explicitly support RSB at all. Any support is via last ditch conversion where it looks for any LiquidFuel/Oxidizer resources and converts them to RF. Same thing for the engines and it defaults to Kerosene for both the tanks and engines. The parts you asked specifically about I think it's picking up as command modules so it does them as Service Module types and only does support for the Mono tanks. (and those processes are mutually exlusive so because it already handled the part as service module it skips the other resources. Final analysis is that the only reason they have any RF compatibility is because of RF Stockalike's fallback configs and it's not a really great or accurate conversion in part because of the way in which they were originally configured to begin with. If you want to use those parts without installing RO then you should at least grab the RO configs for them: https://github.com/KSP-RO/RealismOverhaul/tree/204a4b30888e1df73f35c8cdef6d6a6c4d2d1d61/GameData/RealismOverhaul/RO_SuggestedMods/RealScaleBoosters Easiest way to get them is to download RO then navigate to the RealScaleBoosters folder and copy the whole folder to your GameData folder. (downloading them direct from the Github repo means clicking each cfg link then right clicking the 'Raw' button and saving link as. Save them to a folder you create in your GameData folder to store them in.

Are you using them with stock sized Kerbin or RO/RSS?

Apologies if this is wrong... I'm not sure what you're really asking for? Edit: No, never mind that was definitely wrong, I see what you're asking for. You added the science converter and science lab; the converter is what does the actual research that you were talking about but it depends internally on the science lab which in turn needs a science container to store the data in: You copied and pasted from the stock research lab, yes? See this bit here? containerModuleIndex = 0 That number has to match the MODULE's index in the PART config. If the science container is NOT first then index = 0 is wrong. Look at the original config and see what position it's in. Whatever its index would be subtract 1 and change containerModuleIndex to that number. So if the container is the third MODULE then containerModuleIndex = 2

@Araym Just an FYI (because I didn't see it explicitly stated in the past several posts here) all part costs are assumed to be wet costs for the part + any resources. There is sanity checking to make sure that the cost of the part is not lower than the combined resource cost but that can be broken allowing for negative part costs. (too easily broken, due to what I consider a bug, but sadly, officially is considered not to be a bug)

I'm sure it would be technically possible but have you tried experimenting with the autocut speed? Try lowering below its default. The scenario you describe sounds like it could still have enough velocity not to trigger autocut if it's low enough. The suggestion you made has been made already and discussed in this topic nearly two years ago. I think it's safe to say the author has decided not to implement that or other patches dealing with third party plugins. Both Phineas and I contribute enough to these forums and to KSP players to be more than just 'some bystander' It's ok for other people on these forums to disagree with you and you should get used to that and not take it personally. Nobody here has acted as though you are insulting them. You should try taking your own advice in your last several sentences.

@pap1723 @TechTree { !RDNode,*:HAS[#id[massiveRocketry]]{} }

Ok, I have to accept that the only real way to fix the centrifuge is with its original files at the mesh level. (probably its collision mesh not its visual mesh since there's nothing visually wrong with it) This workaround is the best I can do: It works in that you will be able to put the centrifuge into the world without it crashing your game 99% of the time. If you try to enclose it with a stock procedural fairing then it will destroy the rocket. If you try to put it in e-Dog's procedural fairing then the fairing will be scaled up until it is bigger than the VAB itself. I haven't tried putting it in a cargo bay but I suspect it would react the same way as it does to the stock fairings So there it is, this is as good as it's going to get . // Insert this text into a config file named CentrifugeFix.cfg in your GameData\HabitatPack folder @PART[centrifuge1] { %PhysicsSignificance = 1 @MODULE[ModuleAnimateGeneric],* { allowAnimationWhileShielded = False } DRAG_CUBE { procedural = True } }

Give me a ping Cairan. One ping only please.

Yeah I saw that. One theory I'm toying with is that it's one of the third party recommended mods installing a copy of ModuleManager.ConfigCache with two PHYSICSGLOBAL nodes. It's not a really great theory because it would also (I think) have to involve a copy of its SHA file. It would also have to involve a pristine copy of KSP AND CKAN and it would have to be a very precise set of installed mods absolutely matching the list files in the SHA list installed by this increasingly hypothetical third part mod.. And the very first mod or altered file after that would force a reload by MM of all the configs and rebuilding of the cache. It's the unlikeliest set of circumstances but I just don't see how else it could happen. Edit: Or I guess it could be some obscure Module Manager bug that nobody's found yet...

Still not having any success and I don't see anything obvious in the logs directly relating to your issue. I see some issues with plugins not loading because they're not compatible: Gravity Turn can't be loaded. ModuleRCSFX also can't be loaded but that one is also unnecessary and should be deleted. Its functionality has been folded into the stock RCS module and it won't be updated. so you should uninstall that. (but as I said I don't *think* it's related to your issue) I'll try poking at it again later. My RSS install isn't quite identical to yours; I don't have TweakScale installed. How did you install RF, RO, RSS? If you did it manually, try uninstalling all of those and then use CKAN to install.

@Murdabenne you're reading something into my reply that's just not there if you think it's hostile.

This report isn't sufficient to reproduce the problem. I just created a simple rocket, saved it and loaded it and the autofill button shows up just fine. Needs repro steps plus log. If you're not sure where your log is (and you do have one unless logging was explicitly disabled) then see below:

Why should RC have configs for other mods like that? Even assuming that the part was meant to allow crew transfers.

A few things: Don't try to schedule it in two passes, pick ONE It's Default because that's the name of that REENTRY_EFFECTS node If Custom.cfg exists in your Deadly Reentry folder then this probably won't work unless the config file you put this in lives in a folder beginning with 'z' You're better off just using the in-game DRE menu and setting these fields there. //Overriding Deadly Reentry G effects on crew. @REENTRY_EFFECTS[Default]:NEEDS[KeepFit]:Final { @crewGKillChance = 0 @crewGClamp = 0 @crewGPower = 0 }

Found the cause of the original problem and it's the same damn cause as @yaume had a page or two back. The problem is that there were TWO PHYSICSGLOBALS nodes... but only one gets used and it would be the second one, which (like yaume's) has the stock values. That's two times now. Once is happenstance, twice is coincidence and three times is there's a bug somewhere. (Apologies to Moonraker... or was it Goldfinger??) Rather than waiting for an actual third incident I'm assuming there's an issue here to be found ... maybe with RO itself or one of the mods it installs. Maybe it was the cache file itself that was at fault. In the future I'll suggest deleting that and letting MM repatch and rebuild the cache.

Interesting. Must have been something changed in the physics section. Would you mind sending your latest ModuleManager.ConfigCache so I can see what changed?

It's YUGE! Mostly what did the trick is the PhysicsSignificance = 1 (which basically turns off advanced physics + no rigid body, etc) I've been experimenting with different drag cube overrides because I suspect things originally broke down when it was trying to render drag cubes and something about one or more colliders is screwed up. Also, remember when you originally said that you thought it was the looping spinning animation that might be at fault? Well, one of the animation does seem to be at fault but it was the inflation one that broke things. If I remove the animation module that references that animation, that also prevents the problem where your launch pad goes away, vessel goes away. Of course that renders the part unusable so that wasn't an option. So I'm back to seeing if I can fix it by defining a custom cube set. I don't see that as being able to fix the collider / mesh problem which is what that bounding box represents.

Yer boundin' box is broken! Gonna be tuff to fix, looks like one a them fancy import jobs...

Well, found out why it was blowing stuff up.... here's its bounding box as seen by MechJeb....

Might be premature to say that. I am having SOME luck... I've put one of these things into a sub-orbital arc and Valentina is about to try boarding it. What's that you say? What about Jeb, Bill and Bob? Well... they fell victim to a bizarre incident... the first test rocket kept exploding shortly after lift off in bizarro physics glitches where the rocket's tank reported it had collided into the fairing even though no parts had broken loose. So I left them on the launch pad and made a simpler craft and... when I went to launch it, I didn't get the usual message that a rocket was already on the pad and Valentina's rocket merged with the first rocket which then exploded. So I reverted AGAIN. After that, Jeb, Bill and Bob are just GONE. Valentina and their cousin Billy-Boblie are just all broken up over it. Eh, the point of all that is that my game is glitching in weird ways with no errors in the logs and I can only assume it's a side effect of me playing with the physicality of such a large part. It's stable on the pad but weird things happen when it's in motion I haven't given up on it but it's not very stable either.

Well I've got the centrifuge working in 1.1.3 There's a few changes going on here and I'm not sure which one did the trick. Either dephysicalizing it or procedural drag cubes..... will post more later.

@lurkoholic @autumnalequinox After the next Real Fuels update (IMNSHO) all fuel cells using liquid hydrogen / liquid oxygen should convert over to gas. The reason I say this is that cryogenic boiloff will produce gaseous versions of those resources if there are tanks to receive them. So, throw in a few sump tanks to catch that boiloff and use that for life support and fuel cells. The way things are now, quite a bit of waste is going on with fuel cells that use LH2/LOX. That's actually how Apollo's fuel cells worked except that the actual heat leakage only accounted for a fraction of the amount needed for life support and fuel cell consumption. (which is why they needed heaters inside the tanks...)

@sarbian @Sigma88 Sorry false alarm, took me awhile to sort it, there's a lot of cfg work going on in the mod and patches being carried in an earlier pass added modules that caused conditionals in the late pass cfg to fail so it never got to the inner part where I was doing a MODULE:NEEDS