Starwaster

@IronKerbal Use ModuleHeatShield instead of ModuleAblator

Yeah, see, that 90 degree hinge on the front fins is what I was talking about if it's just going to be a flapper. If that gets into a nose dive it's going to be damned hard to get out of... I suspect that's why the new layout for the Mk1 is slightly angled inwards towards the nose

The plugin is what does that. During startup, the code walks through all the parts and does sanity checking on max temps. But it exempts anything with ModuleHeatShield on it. So for something like a command pod you should probably think about adding that. If it's something that is meant to have a separate heat shield part attached to it then I give the command module itself a small percentage of the larger shield. That's what I did with the Mk 1-2 / 1-3. Which also emulates the Apollo capsule backshell which had about 1/10th of the shield thickness of the main heat shield. Things like shuttle tiles are handled with a little more complexity and you should check out the various space plane configs that DRE use. If you look at them you'll see another way of exempting the max temps but they still have sensible attributes.

@damonvv If you're making them only flappers (one axis only) then suggestion: Don't make them perfectly 90 degrees with respect to the hull. Note how there's a slight angle to them such that when they are folded upwards they angle back a bit. I think that would give a bit more control and help prevent situations where if they get into nose dive they might have a chance of getting out again. (something that always bothered me with the early design that he announced months ago)

@George the astronaut ok so that answer is probably not what I would have liked to give before waking up and having some coffee but this set of exchanges isn't working. Coming in here with 'it isn't working' isn't how you ask for help. The only information you've offered so far is that you can't change the tank type but that isn't really a problem because you are not meant to be able to change the tank type on every tank. It's only really needed for procedural tank types so you can custom design a tank for your specific needs. There are plenty of other tank types of assorted sizes to fit your needs. Default will do fine for most situations. I can design and assemble rockets that will put probes or crewed modules or station parts in orbit using only stock + RSS + Real Fuels + Stockalike Engines. Blindfolded with one hand tied behind my back and asleep. So if you want help you better start providing more information. Screenshots detailing what you're trying to do and where it's going wrong. (including the part PAW menu) and if there are errors involved, logs and ModuleManager.ConfigCache file. But if you keep just saying 'it doesn't work' then I'm going to start ignoring that. And if the only complaint is that you can't change the type of the tank then I don't care if you can do that or not because not being able to do that is the default condition. That is to say, it is by design that you are not able to change the tank type. Edit: Actually, make your log files available for download along with your ModuleManager.ConfigCache file whether or not there are errors. Do that before anything else so I can see what else you have installed and what versions are installed. Zip them up and put them on Dropbox. If you don't have a Dropbox account then make one at www.dropbox.com

Then you better stick with stock until you know what you’re doing

It is ok for a tank to not be pressurized (it actually says "highly pressurized") You only need highly pressurized tanks for pressure fed engines. You probably don't have any pressure fed engines unless you are using Realism Overhaul. If you are using Realism Overhaul then you will also have tanks which are highly pressurized. Again, not every tank is (AND THAT IS OK) and not every tank part can be configured to contain different tank types. (THAT IS ALSO OK) You should probably consider installing Procedural Tanks or ROTanks if you want to have more tanks that you can configure with different tank types.

10 seconds to enter the tracking station and look up the planets orbital and rotational data.

I already told you once that not every tank has multiple tank type selections meaning you can't change the tank type on every tank! THAT IS NORMAL.

I use FASA myself and it most definitely works with FASA. Did you install an engine pack with Real Fuels as instructed on the front page? (RealismOverhaul counts as an engine pack)

And to expand on @Cavscout74's answer; if the antenna is a relay antenna then it automatically routes signals through it. You don't have to do anything as long as it and other antenna are within range.

Then that tank part was not configured with multiple tank types. They don't automagically allow any tank type. Not by default.

They might not actually need a dedicated tanker vehicle. An cargo Starship empty of cargo might be able to do it. It will require a lot less delta-v to get to orbit. Enough so that it should have enough to refuel another Starship and still be able to land. Big 'if' there being that it depends on just how low they get the dry mass and how heavily loaded with cargo the Starship is that needs refueling. The mass estimates that Elon was throwing around the other night were quite a bit higher than I recall previously for dry mass. Speaking of his presentation, I only skimmed it. Did he address the issue of the forward fins and how many axes they would actuate on? Recent tweets seemed to hint that they would move on two axes instead of just the one axis that he had stated several months prior. (I really have some issues with the previous design in that if there is ever a mishap during reentry where it gets into a nose first attitude then they will be in some serious trouble without canards up front to provide proper pitch authority)

That sounds then like another KSP (or mod) window had focus. (to prevent click-through but the keyboard control gets locked too)

You can even set it above 200% but you'd have to change the limit by editing the setting config

Sounds like maybe input locks of some kind are getting enabled and then not being disabled. Either that or you have exceptions happening at the wrong time. You can check either one by pressing Alt-F12. Look in the console for exceptions. And there's also a tab in there that will let you check what input locks are enabled. There will be a set of them for having pressed Alt-F12 and there is also an option in that screen for turning off all input locks. Could even be a combination of the two where some exceptions are being generated which halted some critical code execution before input locks could be disabled. (these locks are there to prevent the player from doing certain actions when menus are active)

You mean Mk 1-3? Sounds like what I was saying; you're basically cutting its ballistic coefficient almost in half. Maybe by more than half depending on the mass of that adapter. This does't sound very unusual to me. It's basically the math behind inflatable decelerators (inflatable heat shields) which drastically increase the drag area. They decelerate much sooner before the craft would otherwise reach its peak heating.

Uh, ok. Am I supposed to do something with this information? It's kind of sparse. I know one parameter of your orbit and that's it. Are we talking a reentry from LEO or Lunar? What was its apoapsis? 1800 ablator would be the 3.75m shield... but what was attached to it? How much mass did the entire reentry vessel have? If it was a very light part (or set of parts) attached to the shield then the it has a low ballistic coefficent and will get lot more deceleration from drag so would naturally lose less ablator. All in all there's not a lot of information about your post.

Yes, it imitates the thin backshell protecting Apollo. In stock KSP it probably won't matter too much; you'll likely be doing ballistic reentries and with stock heating and aero you won't see heating on the pod itself when protected by a shield. For lifting reentries and/or situations where FAR and/or Real Heat are installed then you'll see heating of the pod. So it gets just enough to protect it when a full shield is attached. Probably not so much on its own.

They're all interconnected.... it's really not worth it to try to separate them. I did that awhile back but eventually gave up and just left the whole mod installed as is.

"Do as I say, not as I do."

That's interesting because there's supposed to be fallback patches to catch unhandled heatshields in any oversized star system (which RSS qualifies as) I haven't used that shield in my RSS install but looking at it in the cache I can see it has normal stats. I'll have to dig deeper but what I think is happening is that my patches are assuming that the shield is already being handled by something else and then it isn't. You say you're using SMURFF so can I assume you are NOT using Realism Overhaul? The only way I can see this happening is if Realism Overhaul is installed but is not handling the heat shield. (which it would not be since none of the Making History parts are currently supported by RO...) No... actually Realism Overhaul currently HIDES that shield. If you see it then you can't have it installed.... so the shield should be getting patched.... what is going on here? I'll try to look into it tonight sometime.

It's case sensitive and in PARTUPGRADE the field is techRequired not TechRequired TechRequired is the case you use in PART but in PARTUPGRADE it's a lower case t. Thanks Squad!

sorry for the necro: This is for anyone who stumbles across this thread with the same problem and the same error from that log: That error will be the result if ModuleScienceLab is referencing the wrong MODULE for ModuleScienceContainer. The field is containerModuleIndex and it must be assigned a numerical index for the container. Remember that the zeroth index is the first index so containerModuleIndex = 8 refers to the ninth MODULE. The problem is either because the original part config was written incorrectly or because a Module Manager patch deleted some MODULEs. (or otherwise changed the order)

Sixteen bytes and what do you get another mod crashing with a null reference!