NathanKell

Correct! 10char

Let's consider 5%. For your average 7000m/s Mun landing, that's 350m/s extra delta V. For thrust, 5% is as if you strapped not just one, but one and a half LV-909s to your Mainsail, without paying in mass. I think these would be great as tech upgrades. I even think, as NoMrBond and other suggested, it would be great if those fancy new Kerbal models were used so you have named scientists as well as named pilots. But I don't think they make sense, or lead to good gameplay, as pilot-related bonuses. Science *does* make sense as pilot-related, mind, I'm not saying pilots shouldn't matter.

Yep, let's allow skilled kerbals to fly lifting reentries. Oddly enough, that doesn't require doing all the bad things that we are talking about here. Instead it requires building a pod with an offset center of mass.

The Carpenter example (although that's a wee bit of an urban legend, one for which Carpenter was unfairly blamed, IIRC) would make sense if player control of the craft was mediated through the kerbal. It is not. I would like it to be, for the record, but the way to do that is to actually make the kerbal control the craft (and have the player give them tasks), not to magically increase or decrease the fuel supply. At one point that *was* Harv's plan, IIRC. The Gemini example makes no sense to me, since one already can fly lifting reentries, and "firing the retros at the wrong time" has nothing to do with whether you magically have more or less fuel on your craft, but with...timing when you fire the retros. Again, I support (allowing) the abstraction of vessel control, but Kerbal Experience is not that. Now, as to Skyrim: I support KerbalRPG, but see above: you need to *actually* abstract piloting, not fake-abstract it. Finally, I just want to note that *all* your examples have been of how *bad* piloting can screw you over, not how good piloting lets you do impossible things.

Github is free, yes, and a Pull Request is basically someone making a copy of your repository, making a change, and then sending that back as a suggested change, where if you like it all you have to do is click "merge," Here is a page describing how KSP handles textures. What happens is that all supported images in GameData are loaded, along with all CFGs and MU files and WAV files and...etc. The only exception is: if a folder is named PluginData, KSP won't look inside it. As each image is loaded by the KSP loader, it's converted to DXT1 or 5 (.dds is the file extension for DXT images btw). For RSS, I keep all textures under a PluginData folder, which means they are invisible to KSP's loader, and thus they are only loaded by RSS itself. This is so that I have complete control over how and when they are loaded, and whether or not they are kept in memory after their job (creating a heightmap PQSMod, say) is completed. Sarbian wrote a loader for .dds images. The advantage to them is that they can be loaded directly to the video card, rather than first being loaded into RAM, decompressed if PNG or compressed-TGA, then compressed to DXT1 or 5, *then* sent to the video card. There are even bugs with the stock loader, and it leaks memory, so avoiding it is quite useful, even apart from the fact that loading from DDS is about 30-100x faster than loading from PNG due to all the skipped steps. The downside is that that loader does not keep the texture "readable" in RAM, and thus cannot be used for the cloud mask, or for RSS's heightmaps or vertex color maps. However, for scaled space maps, which need not be kept readable in RAM, it works great. The tl;dr is this: Any texture used in a PQSMod must, for now, be kept as before: as a PNG that RSS loads itself. This includes textures that are used *both* as scaled space maps *and* for a PQSMod, like MoonColor. If it is *only* used as a scaled space map, like EarthSurface or Moon_NRM, then it can be taken out of PluginData and made a dds so KSP loads it normally (via Sarbian's loader).

Excellent! Sorry this was so drawn out...

Hah! I take full blame credit then

hcalves: are you on the latest (just released) FAR? Riddla: Unable to replicate. Try without B9?

Engines Thrust Thr(SL) Isp(SL) Isp(V) Gimbal S3 KS-25x4 3200 2900 290 320 3 Kerb. KR-2L 2500 1838 250 340 4 Mainsail 1500 1422 275 290 3 Skipper 650 563 260 300 2 Poodle 220 73 120 360 3 LV-T30 215 180 260 310 0 LV-T45 200 156 250 320 3 LV-909 50 14 100 350 2 Rock 48-7S 30 24 250 310 2 LV-1 4 1 100 300 0 LV-1R 4 4 260 280 8 Rock 24-77 20 18 265 290 8 Mark 55Rad 120 108 270 300 8 Aerospike 175 156 280 315 0 LV-N 60 17 220 800 1 KR-1x2 2000 1770 270 305 3 Solid Boosters Thrust Thr(SL) ISP(SL) ISP(V) SRB KD25K 650 613 245 260 BACC 315 290 230 250 RT-10 SRB 250 234 225 240 Sepratron 1 18 16 100 115 Note that these Isps are for use with FAR; if you're playing with the souposphere, you probably should bump them back up by about 10% (and then claim they're some kind of exotics, rather than standard nitrogen/hydrazine-based storables, for which these Isps make sense). That should make upper stage engines of limited use on the ground, but very helpful up high, give boosters a solid role (that was denied in .24/25 with the Mainsail buff), and let you use the radial engines as verniers (note high gimbal) so you can have gimbal roll control now that Harv made the gimbal work with it in .24+ Obviously how each particular engine is given a role will depend on taste; but you can see some examples: 1. Early engines have low Isp 2. Vacuum optimized engines have *crap* for sea level Isp; this is more than pure math would suggest, since they endure flow separation at sea level. 3. Even "sea level optimized" boosters do better in vacuum, though as the tech increases, the divergence between sea level and vacuum Isp decreases (since sea level Isp is highly dependent on chamber pressure but increasing chamber pressure doesn't help much in vacuum). 4. The aerospike is "just another engine" -- it has decent performance everywhere, but in any *given* area is worse than an optimized nozzle, and also worse than the super-high-tech x4 engine, which I have taken to be the SSME.

Community Resource Pack is a "kerbal" mod. It adds fun stuff for gameplay. Real Fuels is a realism mod. It adds real fuels at real densities and real performance. You're not going to have all that fun a time trying to make both work at the same time. Not sure what's wrong with that CFG snippit, though.

1. Please thank DYJ; this was just a quick patch I made because I use pwings exclusively and needneedneed them to work with latest FAR. :] 2. Please post your complete mod list with versions. I will try to replicate with just stock+FAR+pwings.

Stock issue.

The cloud speeds need to be turned down by 1/6.4x (or 1/10, which is what I did). I suggest you put it up on github so it can be a pull request. What (other) trouble with clouds is going on?

#1 would take a crapton of plugin work, because you would have to write your own part compilation system, I think. Unless you mean "make an MM file that does it for all known parts that use stock textures" which would be a lot of copypaste and also only work for known parts.

Yes, as it stands the 3d parts in the part list don't take extra memory, because you're just rendering parts that already exist. If you were to instead have a bunch of textures, that *would* increase memory usage.

By not using a mod that is incompatible with your KSP. That's like saying "hey, my mac game says it doesn't work on windows, how do I make it stop?"

When does your code run? Since all those fields get loaded by the module(s) in question, you probably will want to get the some_other_module PartModule on the part you're on and get the value from there, rather than going back to the original confignode it was loaded from.

I believe when alt = 6% of body radius.

Sounds neat! You might want to look into HoneyFox's Orbit Manipulator for the latter case.

That does not appear to be a complete output log. Seems cut off.

Please follow the guidelines in the How To Get Support (READ FIRST) sticky. You're partway there, but we also need mod *versions* (not just a screenshot of Gamedata) and we need the correct log. I will, however, hazard a guess that you're running out of memory (tracking can be inaccurate); the limit for KSP on OS X is about 2.8-3GB, IIRC. Either increase the scale factor in ATM, or selectively delete the parts you don't want from the various mods you want to add. Note: this applies to both of you, although cptbetty (welcome to the forums!) there's more extra info needed because less was supplied.

Sal_vager: I'll draw up a proposal, give me a bit of time though.

Yeah, this is also the fallacy of the aerospike. A nozzle being optimized for a given pressure (0atm all the way to supidly-high-dozens-of-atmospheres) does not mean it will produce the *most* thrust and be the most efficient at that pressure compared to all other pressures; it means that no *other* nozzle could be *more* efficient/produce more thrust at that pressure. Think about it like this: efficiency (aka thrust per fuel unit burned) is a function of pressure, modified by an efficiency function which itself is a function of pressure. You can never have better than 100% efficiency, however, and how much less-than-100% efficiency you get is itself a function of pressure (i.e. you can't be all that inefficient in vacuum no matter how under-expanded you are, but you can get near-0% efficiency at high enough ambient pressure because of flow separation and instability).

The How to Get Support sticky has lots of help on that front.

Normally the GUI is hidden when you're in Action Group Editor mode (rather than part-placing mode). The option can reenable display.