NathanKell

Ah, cool! That sounds great! Let me know if I can help with anything else. Aaaand...whoops, forgot about the others: Mainsail is gas generator (the giveaway is the exhaust manifold around the nozzle; see this image of the J-2 engine (F-1 did the same). This (ducting the turbopump exhaust into the nozzle) is slightly more efficient than a separate exhaust, but still nowhere near efficient as a closed-cycle engine. Though given that nothing actually *flows to* that ring, maybe it's just for show and the Mainsail is actually staged combustion (RftS treats it as such.) It could also use a nozzle rework (the nozzle just looks *weird* IMO; probably would look best with the shape of the F-1). The Skipper appears to be closed cycle / staged combustion. Your best bet here would be model the tubing of the NK-33, I'd say. Also maybe thin out the nozzle curvature a bit to match the NK-33 (although the Skipper, like the LV-T30/45, is the *closest* to a realistic-shaped nozzle stock KSP has...barring the ARM parts obviously). Speaking of ARM: they're real engines: F-1B x2, J-2X, RS-25 x4.

theSpeare: you could always disable logging in the launcher...

Awesome! This just became a required mod for Realism Overhaul The LV-T30 and -45 are open cycle / gas generator engines. You can tell because of the exhaust pipe. For ductwork you could model them on the Merlin (you could even import the KerbX or LazTek Merlin mu for reference), or the Atlas sustainer (LR-105) for an old-tech gas generator engine. (Also the H-1 of Saturn IB, the RS-27A derivative used on Deltas...) It's considerably less clear what the LV-909 is. You could make a case it's expander cycle, like the RL-10, same for Poodle. The 909 could also be closed cycle / staged combustion (like, say, the Russian RD-0124). It's also possible the Poodle is pressure fed (like SPS, indeed any of the AJ10 line). Incredibly important for these, however, would be if you could vastly extend the nozzle lengths; vacuum engines have far larger nozzles than sea-level engines for their thrust (consider the Apollo SPS's nozzle: at 90kN it was twice as wide at the base as the H-1 which developed over ten times that thrust). The 909's nozzle should end up probably a full 1.25m wide (and the Poodle a full 2.5m wide), though maintaining the narrow throats...

Getting there! Nice texturing. I'd still prefer a more detailed RS-27A, but it's a big improvement on what you had before, so kudos!

RSS supports CelestialScienceParams nodes. They support all params, including multipliers. Also, if you don't specify things they don't change; therefore you could get away with the *only* thing in the Mun block being Mun { Orbit { referenceBody = Eve } } And it would still move.

Is it possible? Sure, read the last 10 pages of the thread. It's been updated for a while.

Awesome! Super useful.

Ah, ok! You should then put the images under a PluginData folder; anything in PluginData folders (or subfolders) isn't loaded on KSP startup.

It *may* be that confignode parsing has changed to no longer including ConfigNode.values with empty values, so you might have to switch from !foo to !foo = bar

Fleet: grab the ones I uploaded to GitHub, here. The MoonNRM.png should be correct. SpacedInvader: great! I'm sorry, I still don't follow what you mean for "scale" for normal maps. Is that something in your map generation tool? I've only used premade planet normal maps or hand-edited them, I haven't used a normal map creation program to know what you mean by scale. No worries; I've spent time working on the mesh caching; ready to test now. jsimmons: the fact that Kerbin's atmosphere ended at approximately the Karman line was an artifact of the fact that to roughly (only very roughly) match the pressure curve of Earth's atmosphere in KSP's legacy (single-scaleheight exponential falloff) atmosphere model we used a scale height of 7.5km, which meant (again due to the weirdness of KSP's legacy atmosphere model) things cut out at approximatley 104km (technically when e^(-alt/scaleheight) < 1E-6, or ~13.8 * scaleheight). That cutoff (~13.8 * scaleheight) is true for any planet using the legacy atmosphere model (i.e. Duna, whose 11.1km scale height led to an atmosphere cutoff of 154km, or stock Kerbin whose 5km scale height means 69km or so). Earth's atmosphere now ends at 180km because we switched to modeling atmospheres with KSP's new way of modeling them, pressureCurves (first with Starwaster's curve, in RSS v6, and soon eggrobin's updated curves). I selected 180km because that allows two things: first, it means that the transition from 0 pressure is gradual enough that even on an interplanetary trajectory you won't be hit with a "wall" of drag (as you would be in the old days), and second, that the 185km (100 nautical mile) "reference" orbit used for measuring the payload of launchers (and Apollo's parking orbit) would still be warpable. regex: Given that since I have to include cached meshes for scaledspace RSS v7 will depend more on just RealSolarSystem.cfg for each solar system, I think it makes reasonable sense to offload launch site settings into a separate file. Certainly it makes sharing it easier! (I want people to be able to swap launch site configs; I don't want that to depend on their version of RSS, or have the chance of breaking the whole RealSolarSystem.cfg). That said Starwaster has a reasonable argument in opposition, and it's *also* true that maybe we *don't* want people using *different* RSS.cfgs to be able to swap launch sites without switching system cfgs (and then have that break in-game). metaphor: I've played with 400 in the curve for Earth and had no trouble, so at least that. Yes, temperatureCurve works (check the current source). You might want to touch base with eggrobin, who has written Mathematica code to generate pressureCurves and temperatureCurves with correct tangents based on that sort of input. Your addon sounds quite cool! Starwaster: the current cfg in github has curves by eggrobin with proper tangents, with quite insane accuracy compared to the ISA (on the order of "a pascal or two at sea level" relative error IIRC).

Re: Mach_XXII's request, heck, can you just make *all* the stock engines without tank butts (they're not even thrust plates, they're literally the bottom dome of the tank above them, a tank butt). That would be quite literally amazing. I would no longer hatehatehate stock engines (well, also when combined with blackheart's retextures...)

You just keep turning out amazing stuff, don't you!? This is gonna be *so* useful. I'm always alt-tabbing to check out a plane's line drawing while recreating it... EDIT: Dang, misunderstood. Any way you could load images on the fly? That is, OnGUI read a list of all files under viewer/PluginData/ and then when one is selected read it into a Texture2D, and unload it when done? As it stands it looks like all images must be available before KSP starts, and all images will therefore take up texture memory (and be subject to ATM, too).

On the contrary, it's only for not RSS. It just uses the RSS plugin to make some atmospheric changes. Thesonicgalaxy, I'd appreciate it if you'd edit the OP to make that clear.

Yup, that would mean nothing gets applied to Laythe.

SpacedInvader: I'm currently dealing with the caching of meshes; generic loader is on hold for a bit, sorry. For release, if you want to just upload the files I'll pull them into the RSS repo (and keep the alternate versions there too, as is done now for Earth's normal map). I was definitely planning to release them with RSS if you're cool with that. The reason for the heightmap offset etc is as follows: It was my opinion that people probably cared considerably less about accuracy under water than they did for accuracy above water; therefore I decided that, instead of use 55% of the heightmap's height resolution for stuff underwater (i.e. 11km worth of 20km total displacement) and only 9km for above water, I would set my image levels such that only about 30 of 255 (IIRC) shades are used for below water displacement (thus leading to vastly-shallower oceans, but oh well) and the remaining 225 shades for the above-ground terrain, leading to an accuracy of 40m/shade rather than 78m/shade for above-ground terrain. So basically I already did what you were considering, just allocated a bit more color-pallete-space to the below-water terrain. The deformation level was set to maintain approximately-correct sealevel. Not sure what you mean by "what settings do {I} use" for normals... Nemrav: 1. Asteroids are actually just vessels, not celestial bodies. It would not, IMO, be the best idea to use them for moons. KSP asteroids are smaller (and have a density approaching LH2!) than real asteroids, anyway. 2. I do eventually plan to support all major bodies in the solar system; adding new planets has taken a back seat to fixing stuff nearer-to-hand though. 3. RSS will depend on Starstrider42's Custom Asteroids mod. And thanks. :] GregorxMun: Alt-N to load cloud editor; raise altitude of cloud layer; apply and save. (This is because of Z-fighting and is a known issue. rbray is working on it). Also the clouds have an issue where the 2D cloud layer is rendered much lower than it should be on RSS; you'll need to raise it to at least 10km to get something reasonable even up close, let alone for z-fighting issues. rbray is also working on that.

Yes, it is. But see my above as to why that fails.

Forum post makes sense; I was actually thinking github.

Because @foo will match the first foo that is found; and MM, when it edits a node, moves that node to the end of the list of nodes (which is a problem, see above). Thus each time you edit the first node, a new node will be first. WAIT. That would explain the problem with indexing! Since MM reorders nodes when editing them, indexing will fail after the first!

Challenge completed! Here's my electric STOL light plane. Stalls at 45kts (23.15m/s), cruises at about 60 (31m/s), max speed about 110 (57m/s). Uses Firespitter foldable electric thrust-limited to 5.5% Note that in the second pic I actually bounced on landing on the ledge right before the helipad; later I did land on the pad itself but didn't snap a pic. Doh!

Very nice!

Just to show FAR works at the other end of the spectrum too, here's my electric STOL light plane. Stalls at 45kts, cruises at about 60, max speed about 110. Uses Firespitter foldable electric thrust-limited to 5.5%

Visari: Challenge accepted. (I have flown sims for, jeez, 25 years by now, and have a full HOTAS setup, so...) Hmm. I wonder what would happen if I added a 175-degree gimbal range to simulate thrust-reversers?

Trueborn, since RSS is going around changing all sorts of things and therefore basically needs Custom Biomes to have working biomes at all, would it be ok if I bundled Custom Biomes with RSS so it worked with the supplied biomes out-of-the-box? (I promise to maintain your directory structure, and readme, and keep things up to date, obviously.) Also, do I need to include files for planets whose terrains aren't changed yet, for which the stock biomes would work?

blackheart612: there is no support for normal-mapped end textures in PP yet. Post an issue here: https://github.com/Swamp-Ig/ProceduralParts

At least I saw the above post before posting mine, which I was writing for the last hour off and on :]