NathanKell

That's what I thought you meant, just wanted to be clear that ZRM's does neither.

MedievalNerd didn't have time to add patches for Stretchy/PP and PF radius unlocking. Coming soon. For now, just edit the appropriate files and set the start limits very high.

RaccoonTOF: SFJackBauer's RealEngines has not been updated for some time, and I haven't seen SFJackBauer around much. coldblade2000, IIRC, is working on adding Engine Ignitor support. If you want to do up Block II configs for the parts, that'd be awesome. I'll combined yours and the EI configs and make an SFJBRE update. Semmel: http://forum.kerbalspaceprogram.com/threads/67668 Doesn't remove parts, though, but that could be done by making a script execute afterwards. That said, I agree RO needs docs badly. The closest we have is here: https://github.com/NathanKell/RealSolarSystem/wiki/_pages

It meas that that amount of heat will not be transferred to the part each frame. Non-ablative shields have high reflective values because that's the *only* way they shield from heat. Ablative shields have ablative shielding, so they don't need high reflective values. Check the difference in DeadlyReentry.cfg between the shielding applied to the Mk1 pod and Mk1 cockpit.

Correct. And you can't write a derivative of his code either; it's open to the extent you can see how stuff's done, not so you can copy or base off of it. That said his code neither supports the new EFFECTS standard (predates it), nor does it support multiple propellants. I would suggest, for the latter, copying how ModuleEngines[FX] supports PROPELLANT nodes.

Post your (ksp)\KSP_Data\output_log.txt (upload it to dropbox or something).

Aazard: I would not suggest using the pfactory config. I would suggest *just* downloading RSS v6. That said, you shouldn't have any problems using the full pfactory setup (other than, y'know, it taking lots of RAM) since no custom experiments are written yet for anything beyond Mars. Again--if it works for you, it causes NO PROBLEMS to keep using it; but due to RAM requirements (and MedievalNerd's sanity) I would prefer to not have it required yet. I would definitely recommend Engine Ignitor, else you will find things far too easy, and remove one of the key advantages of solids (no ullage required). Note that most of ht elist is pulled from the second post in the RO thread, but instead of copy-pasting I would suggest choosing "reply to" and copying it with the links; your version in your post doesn't have links. andqui: use RftSEngines. It does work with RedAV8R's patches. He needs to update the OP. EDIT: ninja. RO should make appropriate adjustments to fairing base and side masses. And yes, the max and min widths should definitely be unlocked.

Excellent news! Been trying to either (a) motivate myself or ( convince someone else to do that for *months*. :] Here's ZRM's rewritten ModuleRCS for reference. https://bitbucket.org/dylanede/kerbcom-avionics/src/d4f0f57a8ef50337a2f60e05392634a8ce38916a/CRCS/MyRCSModule.cs?at=master NOTE IT IS NON-DERIVATIVES ETC. Got your RF code; will test.

Protip: rewrite ModuleRCS.

Correction to Starwaster's code so duplicates don't get added. @PART[B9*]:HAS[!MODULE[ModuleHeatShield]]:Final { MODULE { name = ModuleHeatShield direction = 0, 0, 0 // omnidirectional reflective = 0.25 // 25% of heat is ignored } } For ablative, you'd want to change the above module to look like the ablative version of the module (see DeadlyReentry.cfg where it's added to the Mk1 pod for example) and then also add a RESOURCE block adding AblativeShielding. I wouldn't expect RCS ports to survive; I rather doubt they did IRL. Zidane: will read. phoenix_ca: shockwave temperature (heat of the air outside your vessel) = ((actual shockwave temperature) ^ shockwaveExponent) * shockwaveMultiplier heatMultiplier = measure of how fast shockwave heat is applied. temperatureExponent = exponent to how much heat is applied densityExponent = how much heat is a applied is a function of (atmo density ^ densityExponent) startThermal = m/s speed where the orange thermal FX starts fullThermal = m/s speed when it goes to full stretngh gToleranceMult = multiplier to how tolerant parts are to gForce. Roughly equal to this * (sqrt(impact tolerance * 6)) Overjay: do you still need the .23 DLL?

Starwaster: Doesn't actually matter, since the engineconfig will always be applied OnStart anyway. It just has the wrong stats in the editor partslist. Plausse: looks good to me! Will add. Also, you don't need the commented out lines; that's a holdover from when they needed to be uncommented, but I never got around to deleting them after I commented them. Ooh, except Saturn V stage 2 should also be Cryo (unless it had a noticeably higher dry mass fraction than S-IVB, which I don't recall).

Oksbad: Launch from a different area on the planet. Sometimes you sink, sometimes you float above the terrain. Sometimes it's juuuust riiiight. Aw, thanks! :] jandcando: nope, updating this is safe. Also, as Aazard says, if you installed all required mods you should already have bigger parts. Heck, the MK1-2 pod is made four meters (if it's not, something's not installed right). Use the required Stretchy to make whatever size tanks you want, and follow the OP and use one of the two engine packs to get appropriately-sized engines.

By the end of today it will be outdated. I noticed one thing from FASA I was modifying the original of rather than copying.

I hope so. That's a lot of typing. ferram4: I'm seeing it on pwings too. I'll throw up some shots and check the log later today.

1. Look at what the batch file does. Now, do the things it does only to stuff in/below the Spaces folder. 2. Few words, heh. For all textures? Attempt: Textures are 2D images, with a resolution and a bit depth (number of bits per pixel). Usually 8 bits per channel, so we're either dealing with grayscale (8bit), RGB (red/green/blue, i.e. color, 24 bit), and RGBA (RGB + a grayscale channel, called the alpha channel, 32bit). Alpha is an extra channel that is used to convey more information, like how transparent that area should be, or how shiny. Textures exist for many different uses. Diffuse (color), specular (shininess), opacity/transparency, bump, normal, heightmap/deformation/displacement, emissive, etc. In KSP we generally only care about diffuse[+specular] and normal. Engines also have emissive maps, and PQS terrains have heightmaps. I *highly* encourage you to do a google image search for each of these map types, and see both examples of them, and examples of them in action. That will explain better than words. Diffuse defines the visible color you see. It's often combined (into a 4-channel texture) with a specular map to also control shininess, or with an opacity map to control transparency. Bump maps are grayscale maps that describe how "high" a given pixel is, with white as highest and black as lowest. Then "fake" 3d detail is added in the shader by using the bump map to "bump" the surface you see. This is done by changing how might light that area of the object reflects (because if there's a hill on a flat plane, the sides of the hill, being angled differently, will reflect light differently). The line perpendicular to the surface, btw, is called a normal (so if you were looking from above at a flat plane, the normals would all be pointing at you; the normals of a sphere look like hair sticking straight out all over it, etc.) Normal maps are basically a better version of bump maps. Instead of the lower-quality, automatic changing of normals, the normal map actually encodes the normal at each pixel, and the shader reads that. In essence you generate (fake) geometric detail from the texture map. Often used when you make a very high-detail model, "bake" its normals into a texture, and apply it to a lower-detail model. Heightmaps are like bump maps except rather than doing shader tricks, the geometry itself is deformed. Emissive maps control whether that pixel of an object "self-illuminates", i.e. glows. Now, how this figures into KSP. Unity/KSP will load *all* image files in GameData (except in PluginData folders) automatically. It will then, with two exceptions, compress everything into DXT1 or 5. If the file has 3 channels, it is compressed to DXT1 at a ratio of 1:6; if it has 4 channels, it is compressed to DXT5, at a ratio of 1:4. In essence this means that 4-channel textures take up twice the memory of 3-channel textures of the same resolution. The exceptions are: TGAs are left uncompressed (ATM fixes this problem) and mbm textures flagged "uncompressed" are left uncompressed. This matters because you *don't* want KSP to compress normal maps, that makes things look weird. mbms have a flag in the file to notify KSP, but other file types don't; this is why ATM requires all normal maps to either have NRM in their filename, or be specified in a config (the NORMAL_LIST{} node in ATM config files). Generally, stripping alpha from a texture will have the memory it takes up ingame, but will also remove the specular effects (bad, but ok) or remove the opacity map (VERY BAD, for example making parachutes into solid cones).

Visari: 1. Sorry, quite right, first to reenter safely from orbit. August 10 1960 (Discoverer 13) was the first successful reentry and recovery. 2. Nope. 12 April 1961 was Vostok 1; 5 May 1961 was Mercury Redstone 3 / Freedom 7. MR-3 was pushed back a month to fly another booster development flight for Redstone.

BigD145: learn to read the forum first. TheGlitchDoctor: it's a known issue with spaceport. If a connection is running too long, spaceport kills it, even if you're still actively downloading. This kills large downloads. Fix: use a download manager that allows downloading in multiple parts and restarting. Regarding whether to use this pack: While it's debatable whether you'll want to use the part changes in this pack (it strips alpha, so parts may look different; but you'll also cut your RAM use for those textures with stripped alpha in half, irrespective of ATM), you *definitely* should use the IVA reduction, since there's tons of duplicate textures in the stock IVAs.

Here are my notes: *The changes to Explorer will collide with RedAV8R's FASA realism patches. I suggest you change only the science stuff and require the realism patch. *Looks like you're still modifying RT2 stuff which will collide with brooklyn666's changes *Speaking of, as mentoned upthread, need to include an updated RT2 settings file. *You have duplicated stuff in Squad/Science and RT (sciencedefs_all) (NOTE: This might be why some fixes upthread are failing--there are two copies of the file, so changing one is not enough. Just delete one and change the other). *There is a *folder* called Explorer1_RPL.cfg - intended? *Stretchy cylinder and conics should be in the starting node(s), along with all fairings. Here is an updated tree.cfg that moves all procedural fairings to a starting node. NOTE: *After* you start your RPL game and select the tree, exit KSP and replace the tree.cfg in your new savegame folder with this. Here is a MM patch (stick it in RPL tweaks) that moves all stretchies and pwings to the starting node. In both cases you will have to go back to the starting nodes and "buy" all the newly-added parts. EDIT: Visari, re: firsts. From memory, so YMMV *First in high "hang time" orbit (Molniya, early 60s?) *First in geostationary orbit (65? Syncom) *First to recover something from space (59? - Corona/Discoverer) *First in polar orbit (59? - Corona/Discoverer) *First hypersonic (X-15) *First suborbital (Vostok skipped it; had Shepard flew a few weeks earlier, US would have claimed first man in space. Also X-15 flights) If you want more satellite firsts, you can trawl through Gunter's Space Page (here's a link to 1958, other years at bottom) that lists all launches every year. Click on the payload and it'll tell you what it did.

NavyFish: weird. 2 things to try. First, make sure you have 1 and only 1 module manager dll anywhere, and it's at least version 1.5.6. Then replace your fixer with this: //Starwaster/NathanKell @PART[*]:HAS[@MODULE[ModuleEngines],@RESOURCE[ElectricCharge]]:Final { @RESOURCE[ElectricCharge] { %isTweakable = false %hideFlow = true } } @PART[*]:HAS[@MODULE[ModuleEnginesFX],@RESOURCE[ElectricCharge]]:Final { @RESOURCE[ElectricCharge] { %isTweakable = false %hideFlow = true } } If that *still* doesn't work, just edit the actual part cfgs of the parts giving you trouble, and make sure their electric charge blocks look like RESOURCE { name = ElectricCharge amount = 0 maxAmount = 0 isTweakable = false hideFlow = true }

You do have the B9 fixes for .23 right? Ooooh, it only fixes engines and not ModuleEnginesFX. I bet you're using HotRockets. Take that MM snippet, duplicate it, and change ModuleEngines to ModuleEnginesFX.

Sauron: a couple suggestions. First, could you rename this Realism Overhaul instead of RSS? The 6.4x scale RSS config, for instance (let alone the kerbal-scale real solar system) users don't necessarily go for realistic parts. Second, per suggestion from Aazard, could you add a public google spreadsheet where parts needing patches can be listed, along with people who volunteer to do the configs? This would not be for "parts RO needs" per se, but more like "look at this cool engine design blackheart made--will someone volunteer to do an RO config for it?" Now, as to engine lists, you could look at Encyclopedia Atronautica (astronautix)'s engines list or this site which has tables for the LF engines of most space powers (probably more accurate ones than astronautix, too). Regarding adding RF support to a tank, see this helpful guide by TaranisElsu. It's for MFT, but works for RF as well. Tank type choice: first, select the construction of the tank. Normal, balloon, or service module. *If normal, use Default or Cryogenic. (This is the normal tank that most rocket lower stages will use). *If balloon, use Balloon or BalloonCryo (this is the "stressed skin," "must be kept pressurized" type of tank that early Atlas and Centaur used. Fragile, but much higher propellant fraction and lower dry mass.) *ServiceModule is used for service modules and upper stages where tanks need to be pressurized (and plumbed for O2, H2O, and electricity, in the case of spacecraft service modules). It is insulated, too, so there's only one choice here. The only methalox engines I'm aware of are those you mentioned, the notional Mars Direct ones (way over-specced, IIRC), and the Russian conversions (see here). I find nothing wrong with adding speculative engines; heck, you can increase an NTR's techlevel well beyond what we have...

Aazard: the blanket method is a problem because there might be pods (as FASA pods did for a while) that use a monopropellant resource in their reaction wheels as a way to get around the bug where RCS defined in the pod doesn't work. That master list is actually a great idea! Sauron just created a topic in General Addon Affairs about this, and I'm going to suggest adding a public Google Drive document where we can list parts/packs etc and people can sign up. And it's great you're willing, and you'll certainly have work aplenty. Oksbad: Known issue, due to larger radius and limited resolution of the PQS mesh. Not sure excatly why it happens, though, since the PQS should be generating mesh colliders.

You keep saying "star fix", I keep thinking "with a sextant."

http://wiki.unity3d.com/index.php?title=XKCDColors

DaMichel: yeah, I'll have to do a check to see if I can find a good, fast filtering algorithm. Haven't been to VTerrain since I was doing my thesis; it seemed a bit outdated then but maybe it's been updated. comham: yeah, although there the heightmap resolution is already sufficient...