Starwaster

Well, what it is is that RealChutes now scales part of its safe calculation (supersonic component) by atmospheric density so that less dense atmosphere are safer to deploy in, for a given speed.

In theory it could be done as a simple animation, assuming that its drag cubes get correctly generated by KSP and assuming that its thermal properties are properly set up. Not saying it should be set up that way, in fact it would be rather crude and would carry its own set of issues, such as losing the ability to separate what happens to the ballute from what happens to its base part. (i.e the entire thing would heat up) Not to mention looking stiff and static...

@Deimos Rast Being compatible with RealChutes doesn't have to mean customizable in the editor though. If you're able to install this with RC and do a reentry with the parts as prescribed, then it's compatible. It doesn't have to support editing. IMO

There's an old doctor joke about a man who complains to his doctor that when he bends his arm a certain way, it hurts. So the doctor tells him, "Then don't bend your arm that way." The problem you are experiencing is just the editor. No, the editor does not accept those values and doesn't consider them legal. However, in flight mode, no such checks occur and those parameters do work just fine. To be able to use numbers that the editor considers invalid, you would have to modify the source code and recompile.

It's part of the Community Resource Pack and it's named LqdMethane. That's what Real Fuels uses. Try taking a look at the Stockalike Engines pack linked below: Generally, you'll configure your engine as usual (preferably with ModuleEngineRF) but then you'll also put a ModuleEngineConfigs in the part that will list all possible engine configurations where you can Isp as a modifier to the base Isp. (if the base were a kerosene burning engine then methane would have a modifier of about 1.03)

Oooooh crap, Sorry, I completely misunderstood. Somehow I thought you guys were talking about his problem with the MRM-2 coming off too easily. Going back and re-reading I'm not even sure how I came up with that notion. Very sorry for the confusion Is that with CobaltWolf's node_attach = 1.25, 0.0, 0.0, 1.0, 0.0, 0.0? Because that should work. If it's not then try rotating your model 90 degrees before exporting it. Or doing node_attach = 1.25, 0.0, 0.0, 0.0, 1.0, 0.0 (the second set of three determines what axis is pointing away from the surface)

@Joco223 No no no no no, the node size is the LAST digit, the seventh digit. If there is no seventh digit then the default size is used. (Also avoid size zero or Bad Thingstm will happen) Also, node_attach is only for surface mounted parts. Don't add node_attach unless you want it to be able to attach to surfaces. Looking at your MRM-2 part, its top node size is already appropriate for a 2.5m part. The node size is probably NOT why it is breaking off easily. The real reason is likely the fact that you have omitted two lines that govern how much force it can withstand (both shearing and torque) add this to your parts: (the lack of it means it defaults to 22) breakingForce = 200 breakingTorque = 200

I think you can still use the J docking port. The form factor of the J is the same isn't it?

Can the drag cube renderer be modified to compensate? Or will that always be an issue if nonuniform scaling is used?

AFAIR, It's the normals of the mesh itself that were screwed up in the case of the ADEPT heat shield. It confuses the drag cube renderer as to which way the surface is facing. There is a way to get the drag cube renders but I don't recall how. @NathanKell would know.

Doesn't matter that they face in the opposite direction. I do the same thing in my stockalike station hubs. (basically the stock hub but in 5 and 8 node varieties) Symmetry works for all 3 and 6 side nodes. (the image with the docking ports attached used symmetry)

Wait, those were the OLDD parts right? Whatever happened with doing the custom drag cubes for that? I'd bet money that the model's normals are screwed up and the drag cubes are not being properly rendered. His deployable heatshield has the same issues and needs custom cubes. (Which I did for DRE then promptly overwrote my work with bad cubes I'd made previously and lost all my good cubes)

I swear, this goddamn forum. I literally cannot click outside the quoted text in my previous message. Even after restarting my browser. @Nils277 When using stack node symmetry it depends on which way the node is facing. The second set of three coordinates defines the vector facing out from the node. (its surface normal) To enable stack symmetry you need to add a line saying stackSymmetry = 3 3 because it is the number of extra nodes to be placed. IIRC, the nodes all have to have similar names. like node_stack_side0, node_stack_side1, etc. Your parts will have four legs/wheels so the value for stackSymmetry = 3

What is the exact message? Does it say that the antenna was ripped off? If so then that's RT2 doing the ripping. AFAIK it checks to see if parts are shielded now. I suggest using the debug menu, going to the physics tab and enabling the option to display aerodynamic data. Then during flight, right click the antenna and check to see if it is experiencing drag during flight. When inside the fairing, it should not do that. (drag = 0). So, If the it displays 0 drag and RT2 is still ripping off the antenna then the problem is with RT2 If the antenna has a non-zero value listed for drag then it is considered exposed to the airstream. Obviously that shouldn't happen with PF, but maybe something about its placement is confusing to it. Try repositioning it elsewhere. And see if the problem happens regardless of whether the antenna is extended. Crash is an access violation (C0000005) - that's a fairly generic thing with a multitude of causes, software and hardware. But mostly software. In this case I'd say you're running low on available memory for KSP. Remember that regardless of how much RAM you have, KSP is limited to 32 bit right now so it may not see or use your full amount of memory. (basically it's limited to less than 4GB)

It does support node symmetry actually. Look at how the multi stack couplers do it. I'd tell you how but my power is out. And maybe my entire PC as well. (It's been having shutdown issues lately and they're getting worse)

What I'm saying is use a larger shield for extra braking power. The shield itself is fine for small probes or even as a shield upgrade for a mk1

Well, IRL it would break down eventually. Forever is an awful long time To elaborate a little, You know how in stock you can't run a nuclear engine without radiators? IRL that wouldn't be so much an issue. You might want radiators to cool it AFTER the burn. Or throttle it back slooowly.

Does each fairing piece have the cargo bay module? And have you checked the offsets to make sure it isn't occluding anything? Or were you handling that in the fairing base with a single cargo bay module? (if so, again, check the offsets. The center of the bay should be halfway between the base and the top of the topmost fairing)

Why would common sense tell you that the way stock engines and fuel tanks deal with heat is in a realistic manner? Realistically speaking, most of the heat produced by a rocket engine exits out of the chamber and then the nozzle along with the propellants. Yes, the engine itself should heat up but the degree to which that happens in stock is unrealistic and unreasonable. IRL, rocket engines also have heat shields attached to protect the fuel tanks. Having heat dumped into your tanks is not a good thing, it is a bad thing, especially if those tanks have cryogenic fuels that you want to stay cold, like a 7-11 Slurpee. Fuel tanks also have insulation on them. (some have more than I think they should have given what some of those tanks were supposed to represent historically, but that's another discussion entirely)

What I meant was that realistically, a part situated like that would still get some exposure to hot gasses. Just not as much as if it was up front exposed to the compressed shock wave. But FAR doesn't affect occlusion at all as far as thermals go, so that part is all stock, and as long as it's perfectly lined up away from the shockwave then stock KSP will say it's 100% occluded. So if you're getting any heating at all it's not perfectly lined up. The Mk1 pod will start to be exposed somewhere between 5-10 degree angle of attack. (the crew cabin underneath is exposed as soon as there is any deviation at all. See below for explanation as to why it is so heat resistant) One thing that might be affecting you is what the navball marker says. On a suborbital trajectory, especially closer to the surface, there will be deviation between what the orbital retrograde marker says and what it says for surface mode. If it's not in surface mode when you hit atmo then change it! Other factors: The Mk1 crew cabin did not get any special config handling for Deadly Reentry and its skin can withstand a temperature about 500 degrees hotter than it should be able to. That will get fixed in a future update. The Mk1 pod has lesser heat resistance (lower max temp) when its ablator is gone. Putting some small fins on the Mk1 pod will help greatly in keeping it lined up and protected from reentry heating.; the ones with yellow trim work nicely. Edit: I'm doing your Mun reentry as you described. One thing I forgot to mention before is that a reentry in stock with 42km Pe is NOT steep. That's shallow as heck and it's dangerous because Deadly Reentry modifies the shield configurations to burn faster for more challenge. You want to reenter with an orbit of about 20-30km Pe. If you spend too much time in the upper atmosphere you will get heating over a lot longer. (heating is based on velocity cubed but drag is velocity squared... so you want to get lower faster so you can bleed off speed faster) Edit #2: That little shield under the crew cabin is definitely too small as I feared. On the trajectory you've been using it fails between 40-45. Even with a steeper trajectory it fails at around 30. There's too much mass and not enough drag. That's also something a larger shield would help with.

I'll play around with the design and get back to you. First I want to see how it behaves in stock. It might be that FAR just doesn't consider the Mk1 to be very well shielded from the airstream, and I can't say that I think it's wrong. I think you need a broader heat shield at the very bottom. Maybe one of the deployables linked on the first post. (the ADEPT shields, except they're a little broken and the patch I made for DRE isn't fixing it like they should. Still working on that)

Draw a Weapons Chit to determine the effect of the weapon on the Kerbal.

Oh SWEET! You created a miniature Neptune!

Your RealFuels installation is behind and needs updating. Using the very latest RealFuels version I am unable to reproduce your problem. I downloaded the CryoEngines parts pack and they work fine. No issues with the GUI. I am able to change engine settings such as fuel configurations and change gimbal settings. Clearly you do not have the most recent RealFuels or you do not have it properly installed. You have also been hacking on executables and plugins so this is the extent of how far I am willing to investigate this issue and will not be assisting further. Good luck!