NathanKell

I'd rather not try to mess with barycenters until Principia, but I certainly hope that before long we'll have Pluto and Charon looking right. As to the asteroids, I'm not seeing any pull requests. Did you not create one yet?

I suggest deriving from the patch that is now in RSS itself. In fact check out both patches https://github.com/KSP-RO/RealSolarSystem/blob/master/GameData/RealSolarSystem/PhysicsModifier.cfg https://github.com/KSP-RO/RealSolarSystem/tree/master/GameData/RealSolarSystem♦

jhathawaytn: stock KSP bug. liveseaandsky: that sounds like kOS's PID controller doesn't play nice with ships without reaction wheels. RemoteTech had that issue a ways back. Ask them to improve the PID.

That's Kopernicus now.

Something like it ships by default with RSS now, and RealHeat the plugin does half the work anyway. 64K should probably do the same though

....wowsers. Pingopete: Are your cfgs synced with github? I was going to make a pass fixing some MM issues in them, but don't want to do it to out of date configs... :]

Answered on github.

Correct.

Here's a page that describes what you're asking for. Just change the rotational component to be what you see, landed, in "Orbit" mode on the navball, that's your initial rotational velocity. http://www.orbiterwiki.org/wiki/Launch_Azimuth

On 1, try adding a cost and see what happens. AFAIK PF only uses GetModuleCost, which increases cost beyond the base, so setting base cost to 801 should be fixing it (1 + resource maxAmount * resource cost). I find it very hard to believe that there's a bug in proc fairings regarding resources, since it doesn't deal with resources. That's simply stock behavior: stock sums up part.partinfo.cost + foreach module, module.GetModuleCost - foreach resource, (resource.maxAmount - resource.amount) * resource.unitCost. On 2, apparently I'm going nuts. Ignore me. (It must be some addon--perhaps B9 Pwings--applying an old-style DRE heatshield. I could have sworn I saw something in the DRE cfgs last night or the night before, but...it's not there now. >.>)

It would be much easier to write a small custom module for this than to copy the stock module entirely and then add the functionality (you can't add things the code doesn't support, so to make the sensor module handle it you'd have to make a new sensor module that copies stock but handles this too). Also, you'd have to figure out how to calculate the radiation level.

That's an issue with 10.1. It's fixed in git and the fix will be in 10.2 For ascent attitude control I don't have issues with MechJeb. Enable the limit-by-AoA function and you may need to manually set a tf. For remotetech, I encourage you to post an issue on the repo asking for RCS translation to be added to the flight computer. That's a fairly critical thing, really.

1. Click "Edit post" on your opening post. 2. Click "Go Advanced" 3. Make your changes. 4. Click save. The thread will still be open, just tagged differently.

Einkleinermensch: Yes! Go to the repo page on github, drill in to find the file, click the edit button (if you're not logged in, create a github account and log in first). Then when done editing type in a commit message at the bottom and click the button to start creating a pull request. Finish creating the PR and I'll review and merge it! Alpha_Gametauri: That sounds like installation troubles. Please do the following: 1. Create a totally clean install of KSP. 2. Follow the installation instructions in the OP exactly, including redownloading everything, which means you'll have Kopernicus, RealSolarSystem, and RSS-Textures folders in KSP/GameData (and a ModuleManager.2.6.6.dll file in GameData). 3. Start KSP. 4. If it still fails, post the output_log.txt (or player.log if on Mac/linux). YoungGun: Yep, known issue. Textures will be a bit stretched. Best solution is RVE. pozine: I'd tell you to post in the Kopernicus thread, but I guess you already did and it's solved?

Starwaster, couple issues with current DRE: 1. You added shielding to the Proc Fairing sides but didn't change their cost to account for it. That means fairing cost is negative. 2. You seem to have some legacy ModuleHeatShields being added, and that causes ModuleHeatShield to throw on fixed update. Verify that every ModuleHeatShield you add has the correct fields.

MelinsMaster: example here. https://github.com/KSP-RO/RP-0/blob/master/GameData/RP-0/CustomBarnKit.cfg

Just a note: that will only work if the engine module is a ModuleEngines, and it's not null-safe. Try thins. ModuleEngines e = null; for(int i = part.Modules.Count -1; i >= 0; --i) if((e = part.Modules[i] as ModuleEngines) != null) break; if(e != null) { // floats etc } replace the top line with that, and stick the code in the if block.

Please follow the installation instructions in the zips' readmes or the RSS thread. They're very explicit.

They're normal. http://forum.unity3d.com/threads/4-5-serialization-depth.248321/

Ah, the char thing? I'll make that change in master, since I guess I misunderstood how ModuleAblator charring works

It's definitely true that there's a bit too little drag high up...but if high up got draggier, Kerbin reentries would be even easier, so it's a tradeoff.

Let's tone it down a bit, shall we? 1. Just because you're not used to it doesn't mean you're dumb. 2. Just because you like something doesn't mean other people need to as well. While 1.0's aero can be gotten used to, and I would encourage those who want to help the OP (and anyone else) get used to it to do so with practical, helpful suggestions, even that doesn't mean that it's the One True Correct Choice Amen.

Ok, that's puzzling because it appears the patches were applied properly. However, just in case, open RealismOverhaul/RO_SuggestedMods/Squad/RO_Squad_Command.cfg and find the mk1pod bit. Scroll down and change charmin and charmax from 0 to 1 and save. Launch KSP again and see if that helps.

Whoah! Awesome!

Lexx Thai: Do you have other mods that mess with categories, like Filter Extensions? dlrk: that's best done with an MM patch: @PART[*]:FINAL { @MODULE,*:HAS[#name[ModuleEnginesRF],#pressureFed[?rue]] { %ullage = False } @MODULE,*:HAS[#name[ModuleEngineConfigs]] { @CONFIG,*:HAS[#pressureFed[?rue]] { %ullage = False } } } I think ? to start is safe, but if not, just duplicate the patch and use True once and true once (KSP is case sensitive).