Starwaster

ok what is the REAL safe minimum orbit for Vall? I had a stable orbit at 15km and later 35km and both times when switching to other ships or space center, my vall probe 'crashed' into terrain. WHAT.THE.HELL. Edit: And again at 160km.

Don't do that. keep your dll in plugins. that it 'worked' is actually just coincidence. doing strange things will only confuse you later.

I'm skeptical that they really intended for die() to be used when Kerbals are in the capsules, unless it's placeholder code for later plans. That aside, there's a few thoughts that occur to me. #1 you aren't turning off MissingCrewsRespawn (per save file) #2 you might need to remove the dead crew from the capsule manually. But definitely #1. They WILL revive one way or another if you don't set that to False. That's no bug, that's by design.

http://forum.kerbalspaceprogram.com/threads/55219-Module-Manager-1-5-%28Nov-11%29 Put the dll in Gamedata (top level) The cfg that you're going to create can go anywhere in Gamedata or any of its subfolders. I tend to put things like that in a 'MyTweaks' folder. You could also put it in the RealSolarSystem folder on the reasoning that you would want the cfg gone if you ever uninstall the mod. D'oh, already answered! Sorry to hear about the champagn accident I'm thinking the moon could stand to be larger; it looks way too small. About reflectivity.... I don't suppose we could get at the actual shader files? I assume they're in those asset files but now that I think about it, nobody ever talks about those... at all...

Ok, I think I have this working using *.cfg fix only. I've done 3/4th of an orbit with a periapsis of about 20 million meters from the sun and an ap going out past our 'Pluto' I put in exp notation as suggested (though I'm not sure Nathan meant to try this in a cfg but I know from past experience that most module code seems to recognize it just fine) More importantly, this deletes the existing powerCurve. This is a ModuleManager fix which I think is not a problem for most of us here. It also requires Sarbian's MM Extensions OR that you be using ModuleManager 1.5 RSS.Solar.Fixer.cfg @PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel]:HAS[#resourceName[ElectricCharge]]] { @MODULE[ModuleDeployableSolarPanel] { !powerCurve{} powerCurve { key = 0E0 223.8 0 0//0 -0.5 key = 5.79091E10 6.6736 0 0//-0.5 -0.5 key = 1.08208E11 1.9113 0 0//-0.5 -0.5 key = 1.49598261E11 1.0 0 0//-0.1 -0.1 key = 2.279391E11 0.431 0 0//-.03 -.03 key = 7.785472E11 0.037 0 0//-.01 -.001 key = 5.874E12 0 0 0//-0.001 0 } } }

No, it's not stored in the saves. How each of you tried to implement your fixes (i.e. direct editing or MM, etc) might be why you're getting different results. One thing I found was that the old powerCurve data was not being deleted from the parts. The bad news however is that fixing that did not alter the outcome that I can tell.... still poking around at this.

I'm more concerned about the fact that he rounded. I was looking for at least 4 decimal places of accuracy!

You mean negative right? Either way I think I know what the problem is with them. Doing some testing right now. Will post more shortly.

Solar panels draining power... looking at the numbers in these power curves and they're quite a bit higher than Int32.MaxValue Exceed that value and you're going negative. If the solar panel code is using Int32 somewhere that could be why. Edit: Another thought (because I'm not sure I buy that they are using int32 in there) is it possible that the panels are just not producing enough at extreme range and we're just seeing normal drain from components?

Might be a problem with your save file. I had this problem with other parts before. One thing I had to do was edit the save file (it's just a text file, use Notepad++ on it) and remove a bunch of duplicate parts from the tech fields in the save file. And the same part was also scattered across several of those tech fields. In that specific case it happened because I added the tech requirements to all parts missing it before the specific parts pack was officially updated and the mod author then updated it. Because I'd used a blanket catchall that was different than the one that was officially assigned to that part the game ended up adding it to a second tech field which confused it because in the R&D it knew that I had purchased it but in the VAB it saw that I still hadn't.

I'm trying to tell myself that that's not very funny but I'm laughing too hard to hear myself.

No, nothing changed. That's how it works. There's another reason crew portraits don't appear but I forget why.

Well, the important bits. Soon even atmo color will be.

Considering that it's all configurable, I suggest that something like that would best be crowd-sourced.

banned for not being an amateur chaplain.

pre-1.3 versions liked to rickroll you.

banned for owning a Nexus

let's take a look at your output_log.txt file and see if there's any other errors before this happens.

Banned for eternal forests.

I generally get rid of the non-super stretchies.

That number at the end of the part name only exists in the craft file. In the save files it's saved as just the part name. (with underscores changed to periods)

You should also change the altitude of the chute. There's an altitude proprty for it and it won't open above that altitude. (in fact I wonder what would happen if you removed the pressure prop and just used altitude...) Also, if you have B9 Aerospace, slap some airbrakes on too. Every little bit helps.

Throttle limits are independent of autopilot control. They are supposed to apply regardless of whether or not autolpilot is engaged. Turn them off if you don't want them applied.

banned for not living in a rock.

request: those fuel tanks with the rounded edges + flat ends but without the 'bracing' all atound them.