Starwaster

Unable to duplicate. ElectricCharge Rate is only listed once for me. Where are you seeing that? In flight or in the VAB when looking at its stats? Screenshot please so I have a better idea of what's happening?

Except that it lied. I checked after the game finished loading and I found some words without 'K' in them. I think I'll file that as a bug report.

Sounds like your DRE settings are too aggressive. What version are you running?

I have no idea what Planet Factory is or is not capable of; I don't use it. To otherwise do what you are describing with RSS, you will either have to create a new set of configs from scratch or start with one of the alternate configs on the front page. (there are several listed) Each planet's configuration can have axialTilt = <tilt value here> in it. See the RealSolarSystem.cfg file for examples. As stated before, inclination will be calculated from the provided axialTilt values for each planet and inclination altered by the RSS plugin to simulate tilt.

And I'd give you a cookie if I had any. Ahhhh, who am I fooling. I'm a mean greedy old man and I'd probably eat them all if I had any.

It's because when it enters that phase it reorients to prograde which may be different from the flight path it was handling previously. That in itself isn't a problem. What is a problem is that it's usually using a gimbaled engine for that sudden shift. And then it shuts the engine off because it finished fine tuning its apoapsis. So you have a sudden shift in angular momentum initiated by an engine that is now no longer available to finish the course change leaving you with only RCS and reaction wheels. Someone else asked that question not long ago and I'll repeat what I said then: I submitted some minor changes to Sarbian that were accepted and they eliminate MOST of what you're describing by having MJ continue following its flight plan instead of shifting orientation to prograde. And that works fairly well except that I missed that one spot during the fine tuning phase. I'm testing another minor change and if it fixes it and doesn't screw anything up then I'll submit that one too. (I'm not a regular contributor, just the occasional small changes here and there)

http://i.imgur.com/gYslqz3l.png Assembled craft in the VAB http://i.imgur.com/AW7KGF0l.png Just the propulsion unit with an inflated heat shield. Everything should be safe behind. The parts on the Cupola and the 8 canisters attached on the propulsion module are part of the mod BTSM. Thanks for any advice.. cd\ Maximum shielding distance is 10 meters to any part (whether it is attached to the craft you want shielded or not, meaning you are still shielded by jettisoned pieces until they drift more than 10 meters away)

You don't, not with either. RO doesn't do anything like that except through RSS, and RSS only simulates it through inclination changes, which with the default RSS, it is already doing as best as can be done with the current KSP code base.

That used to be true until Fine Print was made stock. Now we have 'keostationary' orbits.

Sorry, some of the settings were screwy on that last release. It'll be fixed on the next one (which I'm still plugging away on and have made some progress) In the settings menu (while in Flight Mode), click 'Enable Debug Menu'. I'm guessing here for 64k but it shouldn't be TOO far off from RSS settings: Set the first 4 options to 1 Set Multiplier to 2.41 - 8.3 (mainly to offset the excessively fast heat dissipation that stock KSP has) the ablation metric probably also needs adjusting (thinking 10x its current value) and can only be altered by editing the config files (EasySettings.cfg, DefaultSettings.cfg and HardSettings.cfg) Only do that last bit if it seems like the shield is lasting too long. It's to make the shield nose heavy if it flips uncontrollably. But if you're using the latest beta, you SHOULD find it a lot less flippy. I made some extensive changes to the inflatable's configs. If using stock / SDF drag then its values are more precisely calibrated than they've ever been before and if using FAR then it removes any last vestiges of stock drag (i.e. the animation2value module that modifies drag when inflated) (just realized that I need to make that change for NEAR as well) NEAR users click here for updated inflatable shield config

Having any axial tilt is impossible in KSP. The issue has been brought before Squad and last I recall was that they would look into it but who knows what will happen on their end.

It needs to be that way to simulate axial tilt. In truth, there is no real axial tilt possible in KSP. So inclination has to be adjusted to give the illusion of axial tilt.

If you're editing an element instead of inserting a new one, then yes, you need to use @

That's the whole point of Real Solar System. It scales up the planets, including their orbits. And relocates them. If you want a smaller star system, look on the front page, first post. There are alternate RSS configs you can use for different sized systems.

That was only an example. If you want another: Contracts. And aside from stock, there's mods. Modders do it too. We have to because that is the system that is in place for us to use. FAR uses body names in a table that it keeps for atmospheric composition per planet. Recent versions of Deadly Reentry do the same. (so that a reentry to Jool, a gas giant composed largly of hydrogen, is different from Kerbin) Who knows what else would break.

Hrmmm, I submitted some code awhile back to make it stay on the ascent profile... for the coast phase. The code is in the most recent dev version but I guess I didn't look at the fine tuning phase. Since I put that bit in, I'll take a look at it (funny, I thought I saw what you were talking about but it was only for a second and then it stopped doing it so I thought I imagined it...)

Yeah, Chrome is pretty hungry about memory when you start abusing the tabs. I often have so many tabs open that not only do the tabs not display any text, but they don't display icons either. (too many tabs so tabs too small) What's really bad is that some of those tabs have been there for WEEKS! (usually NASA or NTR stuff) Not at this moment though. Right now I only have 17 tabs open.

All I can say is I think that was a bizarre thing to do considering that the next KSP update isn't even pushed out to the Experimentals group yet, which is the final stage before an update is released to the public. That's the point at which you can say 'soon'. If you want to add DRE support back in then pick one of the two configs below based on the size of the part you want to add shielding to. (where it says INSERT_NAME_HERE, replace that with the part name from the part's cfg file) These are Module Manager configs so make a config file for them and paste the chosen config text into that file. These will patch any part that you apply them to. (remember to replace INSERT_NAME_HERE with the part's name from the part's cfg where it says name = @PART[INSERT_NAME_HERE]:NEEDS[DeadlyReentry] { MODULE { name = ModuleHeatShield direction = 0, -1, 0 // bottom of pod reflective = 0.05 // 5% of heat is ignored at correct angle ablative = AblativeShielding //conductivity = 0.01 loss { // loss is based on the shockwave temperature (also based on density) key = 650 0 0 0 // start ablating at 650 degrees C key = 1000 64 0 0 // peak ablation at 1000 degrees C key = 3000 80 0 0 // max ablation at 3000 degrees C } dissipation { // dissipation is based on the part's current temperature key = 300 0 0 0 // begin ablating at 300 degrees C key = 500 180 0 0 // maximum dissipation at 500 degrees C } } RESOURCE { name = AblativeShielding amount = 250 maxAmount = 250 } } @PART[INSERT_NAME_HERE]:NEEDS[DeadlyReentry] { MODULE { name = ModuleHeatShield direction = 0, -1, 0 // bottom of pod reflective = 0.05 // 5% of heat is ignored at correct angle ablative = AblativeShielding //conductivity = 0.01 loss { // loss is based on the shockwave temperature (also based on density) key = 650 0 0 0 // start ablating at 650 degrees C key = 1000 320 0 0 // peak ablation at 1000 degrees C key = 3000 400 0 0 // max ablation at 3000 degrees C } dissipation { // dissipation is based on the part's current temperature key = 300 0 0 0 // begin dissipating at 300 degrees C key = 500 90 0 0 // maximum dissipation at 500 degrees C } } RESOURCE { name = AblativeShielding amount = 1000 maxAmount = 1000 } } You can put as many of those as you want into a single file and they can go anywhere in your GameData folder. If you uninstall Deadly Reentry you can leave the above configs alone because they only go into effect if Deadly Reentry is installed. So if KSP 1.0 were to magically appear tomorrow and you don't want the above patches to conflict with stock KSP then you probably are already uninstalling Deadly Reentry which will deactivate the patches Also note the commented out conductivity line. If these configs are going into a dedicated heat shield part (as opposed to being on a command module part like a Mercury or Apollo capsule) then you can uncomment that and it will insulate whatever is attached to it instead of transmitting a lot of heat to it.

Masochism?

I'm confused as to when in the history of the universe you're referring to. I know you're not talking about the Big Bang Theory because that doesn't involve mass coming from nowhere.

Are you volunteering?

Which heat shield specifically? Not all of them are ablative. Only ablative shields have resources. Others are like the shuttle heat shield (aka tiles) and do not ablate. And not which version of KSP, which version of Deadly Reentry. And please post a log as detailed in the linked thread below. http://forum.kerbalspaceprogram.com/threads/92229

I don't know what that means (no sign of heat shield). Need a lot more information I need a better description of the problem. Need DRE version, stock Kerbin or RSS. Are the shield parts from a different mod or the DRE shields. Might need logs too.

Thanks all for the condolences, Re: My cat, Melificent. She was a sweet beautiful girl and I wish we could have had more time together. (she had trust issues early in her life but when I took her to the vet a week ago she was the most cooperative trusting cat) Nothing has changed regarding how how occlusion is tested. In the situation you present, it's a simple raycast from the thermometer's transform (should be its center, more or less) along its velocity vector. If it strikes something then it is considered shielded. If a very small part is too close to the surface of what it is attached to then the raycast origin might be inside of the part that should be shielding it. So there won't be a raycast hit detected. I don't recall the thermometer ever having this issue so maybe something changed with the part itself. It's possible to compensate for and I'll look into it for the next update. (I'll update the necessary file as soon as it's fixed and post a link to it so you don't have to wait for the release)