NathanKell

KSP goes through GameData and loads every single file it finds (of a recognized extension) that is not inside a PluginData folder. That means you can place confignodes (i.e. FOO {} ) inside *any* cfg file, and KSP will load it.

I love this! Suggestion: you might want to do something similar to the G-force code I wrote for Deadly Reentry, i.e. have a cumulative "G damage" meter that sets how dim the screen gets, have it reset to 0 when Gs get low enough, and increment it based on something like the G-force cubed, per tick. That means it takes a few seconds even at 8Gs to black out, and some minutes at 4Gs.

For some *unfathomable* reason, Squad decided that the cost of a part as specified in a cfg is the cost 'wet' rather than dry. Which means every time a resource has less than its maxAmount, the amount less than maxAmount is *subtracted* from the part's cost. So you have to set cost (in the cfg) to be the cost dry PLUS the cost of all resources added.

Please follow the instructions here regarding posting a log. a modlist would also be nice, but you needn't add repro steps. My *hunc* is you're running out of ram, but the log will tell.

Low earth orbit is ~7.7km/sec. That means: dV expended - gravity losses - drag losses - steering losses + rotational boost = 7.7km/sec. Thus you can see that the vacuum delta V will depend on how much of that delta V was expended in atmosphere, and the delta V expended will heavily depend on the gravity losses you incur, the site you launch from, and (to a lesser extent) the drag losses and steering losses you suffer. From the Cape, the nominal vacuum delta V is around 9300; with high-thrust lower stages I have been able to expend only 8800m/s getting to a 185x185km parking orbit, but with a low thrust first stage it may be up to 9400+, yes. Higher TWR early on will drastically decrease gravity losses, but will (a) increase the mass and probably lower the payload fraction of your LV and ( may make your LV hard to control and © can make things dangerous due to high dynamic pressure. Note that there is no single correct ascent profile or correct amount of delta V required; PhD theses are written on this subject, and years of CPU-time expended to calculate it for particular LVs with particular payloads let alone general cases (not least because there cannot be a general solution since the inputs differ). Here's some info from ferram that might help, however--good rules of thumb. Note that, again, if you're optimizing for dV expended, you're not optimizing for mass of LV nor for cost of LV (and optimizing for one of the others means not optimizing for the other two...). As for best place to launch from, that depends on the orbit you want to reach. Kourou (CSG) is best for equatorial orbits, and one of the high-latitude sites (like Kodiak) is best for polar. See here for how latitude affects things.

Neither SAS nor Mechjeb (even with the optional FAR-compatibility dll) deal well with FAR control surfaces. You would be best served by making your rocket statically stable and then, instead of selecting +SVEL, just leave it uncontrolled: statically stable means the air itself will align it with +SVEL.

This is so cool! Kudos!

1 is because biome maps are 2048x1024, which means they are not very high resolution for the size of the planet. 2 seems to be a precision issue.

Love this so much! Also--can't wait to see the tweaks you make for small wings--as Agathorn implies, small sounding rockets are now how one starts an RO career, so itty bitty wingy is important. :]

My hero! I *just* kitbashed a 2/3, but this is so much better.

It's notionally my job to update the list. If I've missed people, sorry; but since the requirement, as I understand it, was to make swamp_ig's job of maintaining KAE easier, and since taniwha is now maintaining it, it should be fine if he says "don't bother."

Alas the partmakers involved have lots of (other) commitments. I hope it's still happening, but nothing's released as yet other than the excellent station parts from NoMrBond.

Mr. Peabo^H^H^H^H^H^somnambulist: I would guess that Kopernicus includes old code to change that and it no longer works in .90? Hmm.

I didn't see (or say) anything about the kerbal models being hardcoded. They're assets, they can be changed by code. However, the difficulty is one would have to reverse-engineer the animation system and create the same-named animations in new meshes. I haven't looked deeply, though. Pipcard, I wouldn't want to distract you from HOPE (I presume you are the same Pipcard from AH.com) but I do want to get RSS/RO (note: RO *does* rescale things properly) to the point where it can expand on Orbiter. I want "Orbiter with legos".

Moved to addon development, as you're developing addons. Best of luck!

zengei, you'll want to disable the MeshRenderer etc attached to the scaled space transform of the same name as the body.

Tweakscale issues are not going to be SXT's fault. SXT doesn't include a built-in scaling feature, it's a parts pack. Lack, I *definitely* took note of that new canopy (you can guess which I mean ). Sweet!

The updated way to mess with the camera and bounds is here: https://github.com/NathanKell/RealSolarSystem/blob/master/Source/CameraFixer.cs Snjo, hope that helps.

Looks like this still wasn't answered. No fuel tank is ever 100% full of fuel, but it's always 100% full of something. Indeed, since engines are either pump-fed or pressure-fed, it's very important there not be vacuum within the tank, so pressurant (helium, nitrogen, etc) is used. However, when in microgravity (and not under acceleration) the fuel mixes with the pressurant. If the pipe feeding the engine has too much pressurant and not enough fuel in it, or if the area around the pipe head in the tank (i.e. what *will* shortly be in the pipe), the engine will not start, because it can't run on pressurant, just fuel and oxidizer (or fuel alone, for monopropellant engines). This means that before you ignite an engine, you must "settle" the propellants by providing some small bit of acceleration from a source immune to ullage issues (i.e. solids, or RCS with tiny bladder tank that actually has a bladder wall between propellant and pressurant). You also need one of two things to be true to ignite an engine that does not have unlimited ignitions: you have an ignition left, or it's hot enough the propellant and oxidizer will start to react even without the benefit of an ignitor.

Sorry, was away for a bit. I'll look into this. It's odd, because I have been having no trouble myself.

We have asked repeatedly for the Winx64 build to not be shipped; I'm not sure why Squad does still ship it, especially now that it doesn't even work stock anymore (career is broken). To clarify and expand on what ferram4 said, it is absolutely not that we have a "burning hate for win64 support." We have a burning hate for not being able to provide it, since there is literally nothing we can do to fix KSPWinx64's issues, other than plead with Squad not to keep releasing it, and hope Unity 5 fixes the issues.

Known issue in stock KSP. TGA textures sometimes fail to load as of .25 and above, and, err, porkjet used TGAs for the spaceplanes...

Eskandare: Wow, impressive? So you can play career mode and upgrade your buildings? Tell us the secret! naturalbornidiot: posted an issue on the CKAN repo. orangejuice: just because a module doesn't already have costDensity in its cfg doesn't mean you can't add it.

Ralathon, you're missing that vertex color and biome maps are uncompressed (because KSP). Here's the memory usage for planets: Scaled space mesh: trivial Scaled space textures: these are the Color and NRM on disk (you can see the size) PQS heightmap: the size of the dds. PQS Vertex Color map: 6 times the size of the color dds file (or less than 6, if the color dds has mipmaps) Biome map: 6MB So let's consider the Moon, at 8192. MoonColor: 28MB (16MB if no mip maps) Moon_NRM: 28MB (16MB if no mip maps) MoonHeight: 32MB PQS Color: 96MB (the color map is loaded again to make it readable, and copied to MapSO for the vertex color map, then freed; the MapSO takes 96MB) Biome: 6MB Make more sense?

Nah, you can edit it with ModuleManager. Unless you load the cfg manually rather than checking the nodes in GameDatabase?