NathanKell

I thought DasBananenbrot was making them?

Macs should be able to handle 4096, so find all 8192 textures and resize them to 1/2 in each dimension.

Use 1 tank per stage (via Stretchy or Procedural Parts). Then the whole stage will drain at once.

Since RSS doesn't actually touch engines at all, that's rather doubtful; it *could* be an interaction with something else and RSS and this, but it's much more likely to be an interaction with something else and this. Julexus Quandem: what other gimbal plugins, if any, do you have installed? What set of engine configs? Do you have any of the "Tweakable" plugins installed?

Works fine for me. Suggestion, use something more specific than POPULATION, like ASTEROIDGROUP -- who knows what other mod might want a POPULATION toplevel node.

Can't change size using NODE {} syntax. Only the old syntax.

Following this with interest! Reflection: http://forum.kerbalspaceprogram.com/threads/70089

You can use taniwha's mu importer/exporter for blender.

Dinker31: update to latest RCS Sounds (if you have it) and latest Real Fuels. Remove TweakableEverything if you have it (or anything else that modifies RCS). Aazard: It's absolutely not a misuse of time, don't worry; walking you through this stuff is both fine, and also very helpful, since once you learn how to do it you can apply it to any fixes that need doing. Actually, you need as many or as few cfgs as you want; essentially the game, on loading, reads all cfgs into one big GameDatabase, so it doesn't matter what's in what cfg or how many cfgs you have or where they are, all nodes get loaded. I generally try to keep like changes together (for example, all modifications to a spacecraft/LV might be in one cfg [FASA Gemini], or all fixes for a type of part from a mod [squad solar panels], that sort of thing). Built in range should vary depending on probe size, I'd say, anywhere from maybe 200km for a tiny probe to maybe 5000 or more for large ones. Similar for pods, I'd say; Mercury/Vostok equivalents would be 200-500km, Gemini is clearly a thousand or two. Beyond that you probably should be adding external antennas (c.f. the 4x high gain array on the Apollo CSM). I don't actually use KAS so I have no idea, sorry... Re: TAC, you might want to check with ANWRocketMan who is editing density and consumption stats for TACLS; that way the amount of resources you're adding will jibe with the life support duration you desire. 1-person pods generally have between a day and a week of life support (IIRC the max-duration Vostok flight was about a week), larger pods 2-3 weeks, but variable (something like TKS, which was really a mini space station, could probably have been provisioned for a month plus, whereas a ferry capsule like a notional "Apollo Block III" for Skylab servicing would have only a couple days). What I meant by that check is: the wildcard config you posted applied to all pods, whether or not other patches had already modified them. What I suggested was adding a check in that wildcard config (i.e. the @PART[*]HAS... line) that checks for things that would only be present if RO has already patched the part. For example, if you apply to all pods that don't already have ModuleSPU (!HAS:@MODULE[ModuleSPU] or whatever) that might be a good check. Posting now; I'll check your files in a bit when I get back.

Yep, Planetarium.GetUniversalTime() or words to that effect.

ialdabaoth: Sounds neat! Yes, I'll absolutely merge it in. One concern though: are you adding any way of setting tank.amount by tweakable, or are you using stock tweakables? Because the stock system is *not* fine-grained enough; it seems to mostly work in 20% increments.

SlimeCrusher: sounds like you need to send up more sounding rockets. Note that you *can* get into high space from a sounding rocket, if you had enough dV to get into orbit. What do you mean no gimballing? Did you download the gimbal plugin RftSEngines requires? What parts do you have available? Aazard: AJE should not affect placement. The only exception are the new parts it adds. You can make SSTOs in RO, it's just quite difficult (although not as difficult as real life!)

Of course--that makes total sense, and is much easier to implement. Actually you could do it exactly like how KSP handles CB rotation: assign an initial rotation and a rotation period, and determine rotation by initial + UT % period. You could store rotation rate in kph (or m/s, probably better since everything's in m/s) and then convert to period ingame based on CB.radius + altitude.

NavyFish: yup! Can stick it anywhere under GameData that's not a PluginData folder (GameDatabase loads all cfg, mu, dae, and images from GameData, as long as they're not in/under a PluginData folder).

rbray: you're welcome to grab the AtmosphereFromGround code in RSS if you like. Also, one thing about cloud speed / position. Might there be some way (or do you already do this?) to save the position of the cloud layers to persistence? It's weird to warp until you get clear skies, save, then when you launch KSP again it's back to cloudy.

Taki117: Are you using RedAV8R's FASA patches?

The heightmap, color map, and normal map of the moon that AndreyATGB provided don't actually match; looks like they're from different data sets. If anyone has matching color, normal, and heightmaps for the moon, please post! The Kaguya data is 5760x2880, which should be downscaled to 4096x2048, which should be sufficient for the moon.

This is a well-known error with people who make PlanetFactory systems but don't assign their planets unique IDs. FAR can't do anything about it, it's up to the PF system creator to actually give their planets unique IDs.

You can still get it from piwa's Saturn V. If that fails, I'll upload my copy.

Yup, that one. I'm thinking now maybe I should have been detecting ModuleAlternator instead, but it seems fine.

Proot: Yes. Here's a stripped-down RSS with a demo cfg. https://www.dropbox.com/s/y9hs9f3mukdmzn1/RSSCLEANv6.1pre.zip

It only works for stock MonoPropellant, so if you're using Real Fuels / RO and using a different fuel, no dice.

Rich: you definitely have my interest. Also, the nice thing about RSS support is that you won't need to edit/kerbalize any of the NASA assets--you can leave as-is.

Does work. Called TreeEdit.

Proot: it does indeed! You know that big glow on the horizon that planets with atmospheres have? You can edit density, height, and color (two ways). There's an ingame editor (left ALT + G) and various stats you can add to the cfg. https://github.com/NathanKell/RealSolarSystem/wiki/AtmosphereFromGround-RSS-Settings