NathanKell

Thank you so much for this! Fixed. I'll release a point release shortly.

Hi prc--thanks! Your problem, I'm sorry to say, is that you missed a step. The RPL readme/OP direct you to download RftS Engines, rather than RealEngines. RPL only supports RftSEngines, and right now you are obviously using RealEngines. Since the tech tree is built for totally different engine configs, everything will be out of order.

SpacedInvader: All PQSMods are applied in order (note the "order" member in those export XMLs), with the final result of all previous mods being the input for the current one. Example: PQS has vertex at height 0 (obviously) Heightmap adds 50 (total: 50) Ridged Alt curve takes 50 as input, subtracts 5 (lowers it to 45) Vert Heightcurve takes 45 as input, adds 15 (to 60) SimplexAbsolute takes 60 as input, adds 5 (65) Final height: 65. All PQSMods are evaulated for all vertices, and they are evaluated "dumb"--that is, none actually know or depend on the existence of others; each takes its input as stateless. Note that AFAICT, PQSMods are always additive, not multiplicative; that is, though their input is based on the current vertex displacement (and might be different for different input displacements), the *way* they further displace a vertex is by adding or subtracting height, not multiplying height. I have not yet had a chance to check out Duna and do some tests. I will try to do so today. Regarding rebuilding terrain during the game. I would actually have to rewrite a good chunk of RSS to handle that, since as it stands everything is done at main menu, not least because all information is loaded when the game launches (i.e. it's in config nodes) rather than my reading files. That said I understand how useful that change would be, and wil look into it. BahamutoD: I, too, have not experienced that. Weird! Does it happen everywhere on Duna? SlimeCrusher: It may be that KSP resets some things on return to the main menu (or that RSS doesn't play well with returning to the main menu). I have not seen such problems myself, but...for safety I suggest not doing that. Only play one save per launch of KSP.

Use thrust limiter in VAB. Or use HoneyFox's Engine Thrust Controller to give a thrust curve like real SRBs have.

Regarding "autorecovery": You can directly steal the code I wrote for MissionController to do just that, actually. (In my case it was do those checks then give the player the recovery amount of money). Incidentally that will also teach you how to deal with prototypes, snapshots, and other on-rails versions of parts and modules.

In sandbox the antenna built into the probe functions; in career you have to unlock it. This implies to me that you've not actually added an "always on" antenna (like the DP-10) to your vessel. You need to do that. No antenna = no connection. If you've only added antennas and dishes that have to be turned on...how do you plan to turn them on without a connection?

Batsignal called me here. Uh, none of those craft you mentioned are using monopropellants; they're using storable hypergolics; NTO/AZ50 for Apollo, and NTO/UDMH for the Russians. Monopropellants would have a far lower Isp; hydrazine tops out at about 240s. It actually applies *worse* for nuclear engines, since (at 800s specific impulse) they're obviously using liquid H2, which as you point out boils off very fast; LOX actually is only mildly cryogenic and much easier to keep around.

Uh, yeah, sumghai left a message on the Firespitter thread requesting Snjo to fix the plugin so it would work with this stuff...at the moment it doesn't.

ObsessedWithKSP: As Kyle himself commented upthread it's actually supposed to be closed-cycle, so you don't get any exhaust there period.

Great work!

Thesonicgalaxy: did you see my info about the cfg file? Is that enough or do you need more?

Huh! I could have sworn that looked like an exhaust manifold for open-cycle (especially with those four vent-like things in the bottom), but...you're the expert on your own stuff.

Neat! (And you're most welcome, obvs!). One thing though--the "crinkles" on the foil look rather large. It gives the effect of a quite small tank, which, since those tanks appear about a meter long each, might not be what you intend? Maybe you could overlay that with a weaker, smaller set of crinkles?

"as added to the SDHI part"

Aw, flippety-flop. Fixed! Not even sure it warrants a point release, but why not. I actually spent a good few hours myself wondering why it didn't work. Then I figured it out, changed my MM files, but didn't change my readme (or at least, didn't change it all the way). BLARGH. You're most welcome! For inclusion, you do need to both credit me and link the source (or this thread, which has the source). Also, since it's SA, any changes you make to it must also be licensed as derivatives-allowed. EDIT: That said, please do keep it in the same folder I do (so people don't end up with multiple copies) and please keep it up to date (heh, not that I expect to need to update this ever, except if a new KSP breaks it.)

A note: coders (and other interested folks) please respond here about making a PQSMod that supports 16bit pixels (and other nice things).

That...would be what I was talking about.

This is a request for all the smart knowledgeable coders out there to share their thoughts/ideas on this. Not a "do it for me" by any means (although if you want to contribute code, awesome!) Basically, RSS needs better heightmaps. While a paging heightmap PQSMod would be the best solution, it's considerably more complex, so I'm looking into creating a 16bit-supporting one instead, and also (since I can load data directly rather than going via Texture2D) supporting resolutions >8192x4096. So what I'm currently interested in is this. Are there any high-performance compression/decompression algorithms I should consider using? Since heightmaps will tend to have some level areas, even lossless compression should offer an advantage--presuming the performance hit is not too high. (Further, is there a lossy algorithm that would not lose too much and thus defeat the purpose, where heightmaps are concerned?) Even if the maps need to remain uncompressed, going to 16bit gray will only double the memory requirements (and, if perhaps my code has less overhead than MapSO, it might end up better than that ratio). Another question: how should filtering be done? I presume I will need to filter *some* when getting pixels--we don't want nearest neighbor for heightmaps! However, something more intelligent than bilinear would probably be nice, as we *also* don't want to just blend the thing--sharp edges should be better preserved. Third question: am I forgetting anything obvious/dangerous that you ought to tell me about?

Aazard: Cool stuff! Grabbed, will examine.

Yes. It basically means I need to revert to 6-3, although that has its own problems (and, obviously, I miss out on volume clouds).

It's an issue rbray needs to fix; AFAIK we all get it with 7.x

No, it wouldn't. And it would only have exhaust once the engine started. It would have smoke then though. You're most welcome! Check out a video of the Merlin in action--you can see the turbopump exhaust there.

ObsessedWithKSP: Yeah, that's the exhaust for the turbopump, looks like, sure enough.

Conveniently/cheatily, DRE only checks whether the part's origin is shielded. So *probably* a 0.625m heatshield would shield a stack-connected pod above it.

regex (and others): I have added my post explaining (some) PQSMod values to the wiki. https://github.com/NathanKell/RealSolarSystem/wiki/PQSMods-supported-in-the-cfg SpacedInvader: The site Ralathon mentioned is what Ralathon used, I thought, and it is hosting a cleaned-up stitched-together version of the NASA data. My understanding is that deformity means full black = 0, full white = deformity. So if you have a deformity of 255 but your lowest luminosity is 100 and highest is 180, then the highest point will be 180m and the lowest 100m above sea level. I really, really doubt that KSP actually trawls through the entire image to grab its darkest and lightest pixels and then rescales everything. Regarding ModifierRequirements: what this means is that for the given PQSMod to be active, the PQS quad must have those things. For example, a vertexheightmap requires that the underlying PQS supports mapping coordinates, or else how to translate between a vertex and its corresponding heightmap pixel. It does not have anything to do with extra maps you need to supply; it has to do with how PQSMods relate to each other, and you can be sure that each PQSMod applied to a stock planet does have its requirements met. I have been somewhat busy the last few days; I will investigate the issues with Duna and try to get started rewriting my loader code. While I do not intend to take this on, it would "only" double the memory required per map to make a version of MapSO (and corresponding PQSMod) that supported 16bit heightmaps. Starwaster: rbray is working on volume fog.