NathanKell

It also depends on whether a texture uses an alpha channel (and will be compressed to DXT5) or does not (and will be compressed to DXT1). DXT5 takes up twice the space per pixel in RAM. Further, normal maps will not be compressed in memory (they will sit as RGB24 or RGBA32), and further-further unless you have ATM installed, tgas will not be compressed ingame, which means they too will stay as RGB24 or RGBA32, i.e. their uncompressed size on disk (note, even if you keep them on disk as run-length compressed, IIRC). The only *real* way to tell how much RAM FASA uses is start a stock KSP install, launch it, check memory usage in VAB. Quit, install FASA, retest. And yes, reusing textures is wonderful and should be done all the time, and frizzank, you're doing a BOSS job of that. Just adding more info. :]

If things are hanging, quit KSP and post log. Upload your output log (NOT ksp.log) to dropbox or something. Windows: KSP_win\KSP_Data\output_log.txt Mac OSX: Open Console, on the left side of the window there is a menu that says 'files'. Scroll down the list and find the Unity drop down, under Unity there will be Player.log Aka Files>~/Library/Logs>Unity>Player.log Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log

Touhou Torpedo had a Mk3 cockpit improvement pack, but he took all his packs offline. If you have it squirreled away somewhere though, do install it.

You'll need to reference two DLLs in your project: (KSP)/KSP_Data/Managed/Assembly-CSharp.dll and (KSP)/KSP_Data/Managed/UnityEngine.dll Note that you need to actually set that up *in* Visual Studio: on the Solution Explorer, right-click on the project and choose add reference, then browse to the file. Here's a good setup from the wiki; AFAIK it's still current. http://wiki.kerbalspaceprogram.com/wiki/Setting_up_Visual_Studio

About 8 threads down from this is KCreator's KittopiaTech Terraforming mod. That's the closest to what you're talking about, I think.

Apologies if I got confused; I was probably thinking of the final challenge thing and transposed that in my mind.

So first of all, the fact that it's unplayable, or that the game couldn't handle the distances, is news to all of us who regularly play RSS. Also I don't think anyone was seriously proposing making that the default mode for KSP; thankfully, such things as Mods! exist. Now as to GregroxMun's questions: Yes, I see no reason why replacing kerbal models with human models would be impossible. In fact, it's definitely on my list of things to do. Also, yes, it's on my list to make a planet-adding system. It's merely the next step for RSS-the-plugin's feature set (beyond moving-and-changing planets). As for the requirements: honestly, now that only one PQS stays loaded at a time, adding more celestial bodies has little more impact on perfomance than debris, I think. There's also the problem of texture memory usage, but (a) KSP is going 64 but ( it wouldn't be that bad to make a load-planet-textures-on-demand mod just like the load-part-textures-on-demand mod. RuBisCo: might as well call KSP "Orbiter with cartoon characters and unreal stats and limited accuracy!" Yeah, that's real productive. It's a sandbox game; some people really really like playing legos with real rockets. The great thing about a moddable game isn't just that you can play the way you want; it's that other people playing the way they want doesn't have to impact you at all. Also, this really fits better in General Add-on Affairs. So off we go!

No problem--done it myself any number of times

IIRC they've made clear that while the votes will influence the decision, they won't determine the decision. Or at least that was true for prior challenges.

The ATM configs are outdated for EVE Overhaul. rbray is aware and fixing. For now, open GameData\BoulderCo\ActiveTextureManagerConfigs\BoulderCo.cfg and replace it with: ACTIVE_TEXTURE_MANAGER_CONFIG { folder = BoulderCo enabled = true OVERRIDES { BoulderCo/Atmosphere/.* { compress = true mipmaps = true scale = 1 max_size = 0 make_not_readable = false } BoulderCo/Clouds/.* { compress = true mipmaps = true scale = 1 max_size = 0 make_not_readable = false } BoulderCo/CityLights/.* { compress = true mipmaps = true scale = 1 max_size = 0 make_not_readable = true } } }

1. I'm using the settings that DRE had when I started maintaining it. If there's consensus that the shockwave exponent should be raised for stock Kerbol-system play, I'm fine with that (I only play RSS anyway, it's not like I care ) 2. Yes, Squad made it physicsless. Physicsless parts don't get heat. I encourage you to use something like stupid_chris's Stock Balance pack to fix that. The only reason it was made physicsless anyway as as a hack to get around the joint issues between very heavy and very light parts (which became an issue in *stock* KSP for the first time with the ARM parts).

Note it says EC/s, which means 1EC = 1kJ.

Hmm. Good point about not having control. Might be worth ignoring it until someone rewrites (writes? ) a decent heating model, especially a decent one *in space*. And yes, LOCA sounds great

I'd say it's probably a refitted QE. Warspite?

Try this? http://forum.kerbalspaceprogram.com/threads/65862-WIP-Talisar-Aerospace-Current-project-Large-Upper-Stage-coop-with-Chaka-Monkey-ES

Just got made one.

Talked with TaranisElsu today. He's going to remove the tank-adding if RO is present. I'm also fixing RF so it doesn't create duplicate tanks. EDIT: To be clear, TaranisElsu brought this up with me. Full credit to him!

KSP is very CPU-limited. Any graphics card newer than the one in ferram's laptop is more or less overkill. This may change as rbray does more shader work, of course. But right now, KSP doesn't need much in the way of GPU.

So mods make things easy, huh? But, basically what Tangle said. Sandbox game. To mangle Rousseau, true achievement is completing the challenges you set for yourself.

I'd suggest leaving at as start once = false, and then have a public static bool notFixed = true then in the Start(), do if(notFixed) { notFixed = false; reload; } Then in the Switcher code, whenever it switches, do SpaceCenterFixer.notFixed = true; (or whatever your class name was; I forget >.> )

You could use the wet CoM but tweak the descent tanks dry.

Kerbin's orbital speed is 2.2km/sec. That means your peak (peak! not the one you get where the atmosphere is dense enough to make a difference) will be ~2000C. Even a Munar reentry is ~2700C. If you do your reentry right, that's not hard at all. On Earth, you're looking at shockwave temperatures of >8000C. From low orbit. Lunar reentries are ~11,000C. This is why the OP and the readme have a guide (right at the front!) for customizing difficulty.

ModuleEngineConfigs supports only one engine module per part. I know that's bad, and it needs to be fixed, I just, err, haven't yet. It should not be that hard to change it to support 2 engines per part, but no more than that would be easy, and there'd still be some hacks to get that to work. For now you can try duplicating the Effects and telling the Effects to use the exhaust transforms (1 each), and then use only one ModuleEnginesFX and have it use the gimbal for its thrust transform.

RL always first! Catch you soon. Lemme know if you want me to stop working on this btw!

You don't want corkscrewing. That's the opposite of stability. You want spin stabilized *along the steady flight axis.*