Starwaster

I only see Kerbal Attachment System parts....?

It's never been movable. That's just the way it's designed, to take up the left side of the screen, just like the action group editor.

Change it and recompile!

Black definitely. It's just a texture. Kosmos has them for this mod. You could download it and install only the fairings. Heavier? Do you mean literally more massive? Sure but why? Unless its for the ablative material? Which brings us to heat shields themselves. If you mean actual functional shields for Deadly Reentry I have tried and tried to make them resist heat and they don't no matter what I do. It might be a problem in DRE or the fairing itself. It's very frustrating. Edit: the reason I was doing it was for a DRA 5.0 style Mars reentry vehicle.

Blasphemy!

Now see, if this were 2053 that wouldn't be a problem because you'd have a datajack and you'd be plugged in. You'd do your coding without your hands while simulaneously running a subroutine to nod your head enthusiastically periodically whenever your family speaks.

Because of the docking AP problems that I reported and because I'd tweaked the approach vector of the AP in 168 That's why I was asking if anything further had been done on docking since 170. You did see the post I made about it, right?

advancedRocketry is a little further up the tech tree. or is it advRocketry, I forget. ima try the sokar configs too if I ever get around to PLAYING again.

I don't think stock drag works that way? I dont remember where (FAR thread likely) but I thought stock drag just got applied to the rocket as a whole taking into account the drag values and mass of all the parts. Which is wrong obviously.

Has there been any undocumented fixes to the docking AP since 170? I'm stuck on 168...

I was going to say 'put space stations in orbit around every world' but you're making that seem mundane...

That is correct. Though at one point Squad said that nosecones were going to functionally improve aerodynamics in stock... in this last update. (or the one before? I forget which). Not that PFairings would necessarily be affected, though one would think if there were a way for nosecones to provide lessened drag that it could be adopted for fairings. But no such improvement is evident for nosecones at all. (though I did see a reference to cylindrical and conical drag models but it doesn't seem to actually be used in stock parts and I have no idea if the part variables involved are actually functional in any way. They certainly didn't help drag when I played with them) Edit: Oh, all that aside, PFairing's autostrutting can be used to make upper stages more structurally sound regardless of whether FAR is used and I've made some interesting heavy payload lifters by enclosing the payload top and bottom with fairing bases/sides and mounting four rockets, one to each fairing. Two of the four feed the other two (I refuse to use the 'A' word). Remarkably stable.

Eventually, yes. That sort of optimization is later down the road as I need to get back to Copernicus and start pushing parts out the door. I have another update or two here first.

Deadly Reentry will destroy your chutes if it's too hot outside to deploy them. I'm not sure if that is your issue or not since you say that it is your ships doing the blowing up.... You your ships? The whole ship? What does the report say after?

Did you try what I posted and Galane reposted?

It should be able to support adding in any shader. Currently the shaders have to be are added in as embedded resources. I'm not sure if that can be changed or not. Which means they're actually added when the dll is compiled as part of the dll. What would be ideal is if I could take any shader source, compile it and turn it into an asset package and have it loaded up when KSP starts up. Unity does support that but I'm not sure if it's possible for US to do with the tools provided....? (i.e. it's a Pro feature, meaning that the game has to be using the Pro license which KSP is but is the toolset available to us the same as what Pro users get?) BTW, the next update to this will fix a bug that is in the current download which is that realTimeReflections aren't properly turned off. But when I fix that bug another creeps in which is that the shader is not properly reflective on the launchpad or when first switched to.... It takes about a minute worth of updating before it kicks in. That's actually something that was plaguing me before and I thought I fixed it but apparently only replaced it with a different bug. Not really sure what's happening, as near as I can tell the update function is being properly called but just doesn't produce or apply the cubemap immediately. Either it's sitting there updating for the entire minute or just doesn't work the first time or something. And I can't programmatically determine whether it's worked or not, I only know by watching it in-game.

No versions removed that ability. It stopped working (properly) in 0.23. I don't think it stopped working completely though.... ? Just on the second reload? Anyway, it's not a change in MM that's responsible, it's a change in 0.23 If it's for development work and what you're doing works in 0.22 then test there where possible. Won't work because @NODE[namedthing] only works where nodes have a name property. @InputRates[Kethane] will fail in your example because no InputRates node is 'named' Kethane. Kethane is a property/variable of 'InputRates' I'm trying to think of a way you could test for that but I'm not sure what if anything will work in that situation... possibly something like @PART:HAS[@MODULE[KethaneConverter]:HAS[@InputRates[*]:HAS[#Kethane], @OutputRates[*]:HAS[#Oxidizer]]{stuff} But I'm really unsure of that. It's been awhile since I've sat down and done anything unorthodox with MM or even looked at the code so I'm not sure how it will behave if passed a wildcard for things that don't actually have a name property.... Also, FYI in your third section you're missing a set of brackets after @MODULE (inside the @PART:HAS[stuff]{}) so even if your conditionals had worked, the rest would have failed anyway. Just an FYI for future

Yeah I'm pretty sure I said no such thing.

I recommend looking at the Squad NTR file in the Real Fuels configs. (there's several configs I forget which set it's in though) REQUIRES Real Fuels but it's very easy to adapt. could copy the config to another file being sure to change the part name (says @PART[<something>] to whatever the name is of the rocket you're modifying). Change base thrust level and ISP accordingly. Has configs for LH2, CH4, NH3 and.... I think H2O. Though the H2O resource might be missing. But the engine is configured.

OMG it's a blinged out TIE fighter...

FYI that's 9.091 times the default of 22. I don't know what the bare minimum is to avoid unnecessary breakage. (originally this was to fix the problem of my nuclear rockets falling off of my ships when they were doing nothing more stressful that floating serenely through space in solar orbit)

No of course not. You have over 100km of atmosphere to get through now instead of 70. You need more dv which means more fuel bigger fuel tanks and better engines to lift the extra mass. There are different engine configurations available depending on tastes. One of those is the stockslike listed on front page.

gears and chutes work yes

I thought lander staging wasn't implemented yet; that the GUI options were just placeholders.... did I miss something?

How would it be cheating? Spacecraft IRL ARE heat shielded all over. However, the bottoms have either more shielding material (example: Apollo. Curiosity) on the bottom shielding with higher heat tolerance (example: space shuttle black tiles) on the bottom. In both cases, even the tops are shielded but have lesser/lighter shielding to lighten the craft. DRE doesn't really model that, though you could mimic that behavior in the case of addon shields like the ones for the Mk1-2 where you could add light shielding to the Mk1-2 capsule while having the heavier shield on the bottom.