Starwaster

I'm mostly ok with them but there are some things that I'm used to doing with e-dog's fairings that I can't do with stock, like attach things to the fairing sides. That kills some of my favorite designs.

This space intentionally left blank. (because I can't delete it)

I tried to duplicate your craft as best as I could. I overestimated the size on the first try. The second time, it felt like it was too tail heavy and unwieldy. If it was even a few degrees off, the RCS was getting burned off and then it got harder to keep it oriented. So I suspect that you're right. It's possible to get it down safely but it has zero margin of error.

his physics globals were one of the first things I looked at. There's nothing wrong there.

Actually if you look at the RO configs carefully, for heat shields it inserts leaveTemp into ModuleHeatShield which doesn't do anything at all. In fact, it shouldn't even be necessary for heat shields since DRE's internal logic excludes parts with ModuleHeatShield and shouldn't cap their temps. Even so, I submitted a PR to RO to patch more sensibly

@Oksbad Periapsis 90 might be too shallow depending on the mass of that craft. Too shallow / too high and it can't generate enough drag and slow itself before its shield burns up. Try maybe around 60

This isn't tested but it should correct the problem I'm seeing. Though, keep in mind that this is likely affecting everyone so it might be something else. Make a file named RO_DRE_PATCH.cfg, edit it and then paste text from the bottom of this post into it: Also, question: At what altitude are you blowing up and what part is going first? And are you perfectly lined up retrograde? (I'm duplicating the reentry you described with a craft more or less like yours...) @PART[*]:HAS[#RSSROConfig[*],!MODULE[ModuleAeroReentry]]:NEEDS[DeadlyReentry]:FINAL { MODULE { name = ModuleAeroReentry skinHeatConductivity = 0.001 leaveTemp = True } }

For the most part things look ok; I did see a bunch of Procedural Parts errors but I don't think they're the issue here. Another thing I saw though something odd in some of the heat shield parts that governs whether or not Deadly Reentry is allowed to cut their max temps in half if it thinks they are too high.. those shields probably then don't have as high a heat tolerance as they should. RO overrides a lot of things so it could be in the RO files but I'm also going to look at the DRE shields again to make sure it's not something originating in DRE that's then carried over to RO. (which then clones some of the shield parts to make different sized ones) Edit: Oh, and regardless of whether I find anything, (forgot to say this before) that shield is kinda skimpy in size so you better be perfectly lined up into the airstream or things are gonna fry

The menu is non-functional in the current version of DRE (Also, some DRE settings are not properly overridden by their config files such as g-force settings) Other than that it should be functioning for you. Why don't you provide your output_log.txt (or player.log if Linux/Mac) file and from your Gamedata folder: ModuleManager.ConfigCache I'll look over those files and see if I see anything wrong.

There will be a build for pre-release. What I had wanted to do was fix UI issues then do a final update for 1.0.5 followed shortly by one for 1.1 Unfortunately I'm going to end up doing the updates without a functioning UI still. (not a huge loss, the menu options would have allowed changing certain settings in-flight that otherwise require cfg edit + restart of KSP). The main purpose of the update is to fix a bug preventing cfg settings from overriding the defaults. So that will happen for both 1.0.5 and 1.1 As to when: When I can get time to package the update and push it to the server. I wanted to do that last night but ran out of steam and fell asleep. So sometime today hopefully.

Elaborate please? How would I use asset bundles with the Unity editor to make use of the game's new UI? Or link to existing thread that details how is fine

The reason 1.8 was 'missing' parts is because it wasn't a full package. The way it was intended to be used was on top of 1.7, except that he also changed some part names which makes it desirable to manually delete the duplicated parts. It's not really an optimal way to have gone about things but the way it needs to be installed is OP say's that's not so

He could tell you, but then he'd have to wenk you.

On the subject of plugins: If you code plugins it is completely unnecessary to ever use the Unity3D editor or bother with asset bundles. I can't even begin to apprehend a scenario where the editor would be necessary or desirable in that regard over using an IDE to write my code, link to the KSP dlls relevant to my plugin and compile.

Win 64 lock is removed pending evaluation of stability. You'll find that to be the case with many of the mods that currently have restrictions on x64 KSP client as KSP 1.1 is evaluated. If you're using the prerelease version you'll see it comes with KSP 64 bit too.

I recompiled it. Due to 1.1 changes, pretty much EVERY plugin is going to require recompiling with updated references at the least, and possibly minor rewriting. Here's 1.1 compatible versions of SplashdownHandler and AnimatedDecouplers. You need to copy the contents into your GameData folder and let it overwrite anything it asks to. THIS IS FOR KSP 1.1 PRERELEASE ONLY! DO NOT USE THIS ON 1.0.5 https://www.dropbox.com/s/wmd9uqoq5j7akg9/SDHI-patch-1.1.zip?dl=1 Failure to comply will result in me posting something in Comic Sans! You have been warned

I'll do a pull request today with some numbers. Deployment speed also seems too fast, happening almost immediately, but it's set to 6 seconds in the config... wonder if there's a bug in the stock parachute code... Edit: Ooooooh ho. deployment speeds in the stock code are NOT in seconds ?!?? High numbers mean FAST deployment? That's kinda messed up when you're used to dealing with animation times.

Wow. Just fired up 1.1 with SDHI installed. Compiled both AnimatedDecouplers and Splashdown Handler for 1.1. No Real Chute; just the stock configuration. Did a launch abort test (Mode 1A in Apollo parlance), things decoupled properly, abort action group working ok. And then I popped my chutes. And the capsule went out of control, velocity readout said that I was doing over 243 million meters per second and the pod exploded due to overheating. Attempt #2, chutes destroyed because they deployed too high up. (their default deploy params are too early...). Heatshield convection numbers were 0, which leads me to think that the shield was probably thinking it was still shielded from aero... which would be an AD issue except that it didn't happen on the next attempt... Attempt #3 worked out ok. The pod sits a little too low in the water with the bags deployed so I'm going to bump its deployed buoyancy up a bit. I did not see a repeat of bag animation replaying when bumped by EVAed Kerbals (per our discussion on that matter). I might have seen some redeployment upon repeat splashdowns but it might have been my imagination too....

Some helpful tips to those using chutes over Duna (or worse, Mars) with heavy loads: Try configuring the chute as a drogue. That fits their use case scenario better than as a main chute. Set a target altitude and target speed you want to be at when you hit that altitude. Set the auto-cut speed to your desired target speed or lower. (can't be higher than 100 m/s) Let's say for example target altitude: 10000m desired speed 200 m/s autocut altitude 100 m/s (this assumes that you're descending the rest of the way on retropropulsion for landing) Obviously, your deployment altitudes need to be at least equal to or higher than your target altitudes and you need to be able to decelerate to a safe deployment speed by the time you hit your deployment altitudes.

A word on g forces and the human body: Fighter pilots routinely are subjected to forces exceeding 9g's which is possible both through training and the use anti-G suits that they wear. Astronauts also were subjected to high g's in the Mercury-Apollo years. And an army doctor by the name of John Stapp subjected himself to g's exceeding 40 g's one one occasion as part of high g testing involving rocket sleds. He didn't suffer any serious side effects though he was left with long term vision problems. (either because of the single 40g ride or cumulative effect of lesser rides)

Not everyone is as skilled as that; that's not a very compelling reason to be so dismissive of someone's feature request. And there's several solutions around the texture issue. There's room for optimization and reuse of texture sheets. The impact is pretty negligible.

For the same reason we have probe cores in the same form factor as the plane parts in the first place. It looks better and doesn't clutter up the plane with useless greebles.

he's probably talking about a K sized probe core...

@StahnAileron @Ohm Machre You don't need to manually add drag cubes to a part except in unusual situations involving animated parts or if the part has mesh normal issues. If parts flip that doesn't sound like they are dragless. Look elsewhere for the cause. Edit: on phone and getting out of the car as I typed that. So it was terser than I intended. Maybe there's something about the situation involving those tanks that I'm unaware of but if they were dragless then they would fall off without flipping. You need drag for that to happen.

No that just means its attachment rules don't allow attachment. Age of the mod is irrelevant. The only real problem this part has is its proprietary dependency on an unmaintained plugin for the wheels.