NathanKell

Yep, the linux zip comes with both executables.

It's for testing and in a bit I'll release another. Thanks to some truly excellent volunteering by folks (and a...rather late night last night) we're actually nearing ready, check out how many checked checkboxes there are! https://github.com/KSP-RO/RP-0/issues/154 However, we remain in dire need of science text! And all that takes is the ability to write a little bit! (And google what the results should be) We're good for the Geiger Counter in Earth space low, but otherwise we need logs. http://goo.gl/Pd0Qs2 And see https://github.com/KSP-RO/RP-0/issues/156 for a description and a list of the top-priority instruments.

For the record I don't get that problem...

I will verify things in my install, though I do first want to check and make sure you not only downloaded that new cfg but also downloaded the special "hotfix" dll for Kopernicus--simply installing Kopernicus 0.2 isn't enough, you then have to plop the hotfix dll on top (available here, click the dll and choose to download raw https://github.com/BryceSchroeder/Kopernicus/tree/master/Distribution/GameData/Kopernicus/Plugins ) The sun is indeed small, and needs its flare resized, I agree. Units in the right-click menu are in kW (1 EC = 1 kJ, 1 EC/sec = 1 kW) in Realism Overhaul. The capsule...I bet I know what's wrong. Is DRE installed or not installed right now?

You can indeed define it in a CONFIG node, and if it is not defined in a CONFIG node, then whatever value was loaded last will still be the one used. Basically, MEC works by forcing the ModuleEngines(whatever) module to reload itself based off the CONFIG node, so *anything* you can put in a MODULE ModuleEngines* node, you can put in a CONFIG node, and any settings that aren't in the CONFIG node will not be changed by PartModule.Load. Note that there are a couple exceptions, for example if IspV/IspSL are specified they'll override the atmosphereCurve node (if that too is specified) and that ignitions uses that funky "0 is unlimited, negative is techlevel" stuff rather than how ignitions behaves in a regular MODULE node.

FinnishGameBox: PM sal_vager or KasperVld or Supernovy and ask to have your name changed. Soooper-doooper-power moderators can do that. And thanks so much for all the work you're doing on RP-0 contracts! (And to nightingale for powering them! )

If it's like the others, it'll store the bounds of the part when the part is first loaded (and turned into a prefab), and then if the bounds change later you need to return the offset between your current bounds and part.partInfo.partPrefab's bounds.

That's really weird since I can't imagine what would be giving it the name Eeloo--it's not even derived from Eeloo, it's templated from Jool and renamed Uranus. I don't get the issue at all. Can you post your mod list, and upload zips of your log files (see here), your KSP/Logs folder, and your KSP/GameData/ModuleManager.ConfigCache file?

Awesome! And going by Boeing's history on S-IC, non-common-bulkhead would be true to form...

* Ground stations' radar * Inertial guidance (you know how fast you're going at the start, you have accelerometers to track all the forces applied sans gravity) * Alignment based on reference points (horizon, fixed-stars, etc)

63Hayden: Yeah, that doesn't sound like a bug, just the iron laws of physics. frisch: right there it says 0 MB free. That's your problem right there. Switch to Linux x64, use force-OpenGL mode, lower your RSS texture size, remove some part packs. 63Hayden: No problem! As to the solar power--it's a problem in both Kopernicus and RSS. Update to the latest Kopernicus hotfix (see thread), and remove the SolarPowerCurve from RSSKopernicus.cfg (or just replace it with this version https://github.com/KSP-RO/RealSolarSystem/blob/master/GameData/RealSolarSystem/RSSKopernicus.cfg ) As to the Mk1 capsule being all black, pics? Mod list? Because I sure don't get that one. :]

Real Fuels now does its own ullage/ignitions handling, so I would definitely not suggest running both EI and RF together.

It'd also be really, really nice if minimum as well as maximum zoom were fixed.

Yep. https://github.com/KSP-RO/RealismOverhaul/blob/master/ROMini.cfg

Nope, RF will just use whatever you specify. So if you tell an engine it has 1 ignition and uses ullage...it has 1 ignition and uses ullage. :]

Craft file? Parts used? I'll take a look.

From the RF thread: Thanks so much! First of all, RO does not support career "out of the box". Career mode requires the RP-0 mod, which is not quite updated for 1.0 yet. I suggest playing sandbox until then--certainly there's enough new stuff in RO (like real, aka not-throttling, engines! ) that just playing around in sandbox first is worthwhile. In terms of how to handle things, I recommend looking through the guides on the Realism Overhaul Wiki. Like real life you're going to want to design your LVs to have a sea level TWR of about 1.15 to 1.5, and you're going to want to fine-tune your final orbit with RCS.

Hi! Thanks! That's really a question for the Realism Overhaul thread, so I'll answer it there.

1. What RCS thruster(s) have you added? Are you sure that (a) the thrusters are oriented such that you _can_ get a roll moment from them, and ( they have a long enough lever arm to apply enough torque to be noticeable? 2. Can you try to narrow down the issue? That sounds like something breaking, but I have literally no idea what. Please create the minimum mod setup that gives you the issue, then post logs. This thread is your friend: http://forum.kerbalspaceprogram.com/threads/92229-How-To-Get-Support-%28READ-FIRST%29

It's CC-BY, so anyone can fork and release updates so long as snjo remains credited as original author.

The Pluto textures are custom textures made by dimonnomid, nothing in RSS has used stock KSP planet textures since, like v7 or so. And yes, we'll certainly update our Pluto textures as soon as we can.

Two things: 1. Please, everyone, calm down. 2. If you want to discuss coding standards, please take it to the Lounge. Let's get back on the topic of ModuleManager here.

eirinym that sounds like either an issue in RF or an issue in your data. Because thrust at sea level will always be thrust in vacuum * Isp at sea level / Isp in vacuum, by definition. Make sure that's the case for your data.

Temeter: Thanks, I'll check the mk2/mk3 adapter you mentioned and the passenger section. Yes, here's fine for RealPlume issues with RO itself. Thanks for those finds! The best is if you could make an issue for each on the repo, so we're less likely to lose track. 63Hayden: Um...RSS alone doesn't change part sizes or stats at all.

Nori, those are just tags. They only have the source. pack_rtr, you want the build server. On the left, Build History. https://ksp.sarbian.com/jenkins/job/ModuleManager/ Nori: HAS means "does this node have this thing" so no. Consider two things: @MODULE[foo] is just shorthand for @MODULE:HAS[#name[foo]] @MODULE[foo]:HAS[@MODULE[bar] means to find the MODULE with name == 'foo' that has a node inside it named MODULE which has a value inside that called 'name = bar'. I don't think that's what you want to be doing. Also, you can't have multiple pass specifiers (well, you can, but only the first one will be used). That is to say, :FOR[foo]:FINAL is exactly the same as just :FOR[foo] because the FOR pass for mod 'foo' comes before the FINAL pass. Just like FOR[foo]:AFTER[bar] will run on the AFTER pass for mod bar, not on the FOR pass for mod foo.