NathanKell

Aazard: It's an IRC channel on esper.net, yeah. Here's a webchat interface

Sounds like either an install issue or a UI issue. You are going into Action Group Editor mode and clicking on the tank, right? Does the GUI appear then? Can you use it?

smunist: *complete* modlist please.

rbray: that sounds like a good list! For terrain, do you also mean water shader? That's a big issue with RSS, where it seems they're using a fresnel shader but the shader vars are off. The setting-cloud-position-based-on-UT thing? Is that in? A longer-term issue (non-critical) but that I have seen for a number of versions, unless I'm misconfiguring: it seems very hard to get the detail texture's alpha to affect cloud opacity. In particular, what I'd like to see would be very *white* clouds (i.e. weak RGB effect from detail texture) that are nonetheless very broken up by the detail texture's alpha. As it stands, in order to get detail in the clouds, they come out looking somewhat gray. If you get bored (hah) there's my perpetual suggestion to just implement pnoise in the pixel shader (perhaps rather than detail textures, perhaps in combination). That will neatly avoid the issue of detail texture scaling since it operates in screenspace rather than worldspace, and you can have the resolution be as fine as you want (so even if you're reasonably close to the 2D cloudlayer the detailing will look very sharp). You could do something similar to make city lights twinkle. I have even more long-term stuff (using similar paging terrain code to handle landclasses, which then translate into different terrain shader (or even tiled diffuse/normal textures based on landclass); replacing/enhancing the stock terrain scatter system and getting it to the level of a flight sim (trees, buildings, etc)...

RO is about to be a plugin

Have you verified in the recovery "science gained" dialog that the multipliers are being applied? Try setting them to 0.0001 and see what happens. Also wait you're moving Moho to orbit around Kerbin!?

You're probably best checking to make sure the part doesn't *already* have MJ. @PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]:Final { MODULE { name = MechJebCore } }

Well, I didn't realize until about 5:30am that body.name just *gets* body.bodyName, which is really annoying. So renaming planets will require me posting a PSA begging modders to not grab CBs by name. (That's why the bodyName lines are all commented out right now.)

Not quite yet. They are all out for testing, release this afternoon.

You're most welcome! Good luck, and let me know if you run into any issues. (The reason for RSS isn't difficulty, of course, it's me-wants-orbiter-where-me-build-rockets)

regex: cool! And eggrobin did the hard merging work (since evidently I did stuff while you were, oops). Looks great! RaccoonTOF: Hah! No way! My parents have had it since like the 70s or so. Here it is back about when I was born, I think off Norwalk. SpacedInvader: cool! Yup, still up. Trying to finish about 5 releases before crashing...

1. See post above yours. Would like input. 2. ServiceModule does indeed understate mass for RCS tanks, which is something to fix when PP really replaces Stretchy for use with RF (maybe we should up the tankmass for bladder tanks inside a ServiceModule part? Difficult because how do you distinguish bladdered HTP from just plain pressurized HTP-as-oxidizer?) 3. You need Realism Overhaul, which has the RCS configs. Monopropellants only. It's about to be updated (along with RF) to support ModuleRCSFX (which supports bipropellant RCS).

cantab: RSS will calculate them correctly when you move things. If you place the a moon too near the sun it won't have an SoI (or it might, but it'll be under the moon's surface ). Dewar: thanks so much! For adding them, right under the Orbit {} node (and still inside the Mun node), you can do CelestialBodyScienceParams { LandedDataValue = 5.0 // or whatever } The ScienceParams available to RSSare listed here: https://github.com/NathanKell/RealSolarSystem/blob/master/Source/RealSolarSystem.cs#L1163 I don't know what bodies have by default, but I presume you'll want to change the various DataValues (like InSpaceHighDataValue which presumably multiplies the science you get while InSpaceHigh over the body). You can also change the thresholds if you want to change the altitude (in meters) that FlyingLow becomes FlyingHigh and same for InSpaceLow/High.

Hey Aazard, apologies for non-presence in the RO thread last couple days; as you can tell by MN's post (and the stuff in RSS) I've been kinda swamped. I will get to it asap (although not until after RO v5 that's coming out tonight, that will be last RO with ECLSS; hopefully in another few days with your help v5.1 will switch to TAC), and if you hop on #kspmodders some time I can walk you through stuff.

Two ways. 1, if you want single-plane separation, you do as follows: Use KJR (obvs) Build upper stage. Attach interstage adapter, via floating node, to the bottom node of the upper stage. Add either fairings (and move the fairing decouplers to above the adapter decoupler in staging) or structural fuselage sides Decouple using the interstage adapter decoupler; the extra joints that normally are killed only on interstage fairing separation will be killed by KJR. 2. If you want dual-plane, look upthread where HoneyFox posted a new part that can do that.

SchroedingersHat: thanks for the catch! I think I was missing a zero, i.e. I was intending RCSHigh to have the same basemass as ServiceModule. But thanks to that link (you don't want to know how much time I spent looking for actual stats on bladder tanks...clearly I was searching wrongly) I'm fixing them. Basemasses will now be (barring your violent opposition): RCS 0.0002 RCSHighEfficiency 0.00006 (so RCSHE will be 2x ServiceModule, and RCS [to represent a 5-100L tank, rather than a larger tank] will be 6.6x the SM.) The tankmass should bulk them out to about in line with your sources, I think, or perhaps a bit below at the high-efficiency end. Any other suggestions? (Gratefully accepted )

Great! Thank you so much. Will do.

Of course it's losing power; ramjet power is dependent on airflow into the intake, so every m/s of speed you lose (flow = area * velocity * density), that's lost thrust, then you lose more speed, and thus more thrust, until thrust and drag are equal, your speed stays constant, and thus your thrust stays constant.

Your FASA zip no longer includes RSS_Resources.cfg.

RaccoonTOF: That's strange about maps. I see no reason why that might be, unless for some reason your resizes did something to the channel count? At least you got it working. And...she's quite handsome! Will check the album. Sailing is another giant passion of mine (my family has a (v1.0) Cal 25 we sail each summer). SpacedInvader: no worries. :]

...and ferram ninjas my half-completed math post saying the same. Well, best to be ninja'd by the master. :]

SpacedInvader: That sounds good; and unless Github gets pissy at me and I need to move to sourceforge it should all be good. As long as no file is >100MB, which seems likely (SuperPNG->most optimized PNG export should ensure an 8192 normal is *just* under 100MB...I trust.) With this one might as you suggest use lowres maps mostly, and swap to hires for the bodies one plans to visit that play session, further lowering memory. I haven't licked the scaledspace caching issue yet (I export fine, but import seems broken)...so that delay is fine; I would, however, like to release v6.1 for now, I think, so that it can come out in concert with RPL MS19b and RO v5. So I'd say PM me what you have and we can launch a "teaser" pack; but as for the others, we can shove off RSS v7 for a few days. Homework obviously comes first! SuperPNG in most-compressed mode is about the best we can do without going lossy (jpg). KSP does not read DXT directly (although most textures, on load, do get converted to DXT...). So it's png or jpg. (Note that SuperPNG can achieve a far higher compression than PS's built-in PNG export) Normal maps are often left uncompressed in memory KSP for quality reasons, but I'm adding a new flag to RealSolarSystem.cfg to allow compression if desired; a user may decide on their own whether the 75% savings in memory is worth the quality reduction.

I have somewhat similar issues, actually; With a RATO-boosted ramjet-powered X-15-alike I got up to M5.5+ but with a similar 2x Jet, 2x ramjet aircraft as soon as I throttle back the overheating (~M2.4) I lose ground. I will keep streamlining and testing. I did not think that my X-15alike had that much less surface drag than my twinjet, but apparently so. (Not complaining; merely surprised at the result)

Starwaster: metaphor also did a pressurecurve as an interim fix. That might be why. Green Skull: cool! RaccoonTOF: Hah! It's like when KCreator kept talking about a "star fix" for the planet tools. Y u no haz sextant? Oh, you mean light? Bah. Which 36? You have my interest SpacedInvader: Ah! Yeah, I've not used that to generate normals for RSS. Regarding size: Mac users can't use anything beyond 4096 anyway (for diffuse/normal; height at 8192 is OK IIRC because it's never displayed) so we *have8 to have a 4096 option at least for them. Even Earth with 2048x1024 normals is acceptable, so I would suggest: Earth/Mars/Venus: 4096 color, 2048 normal Moon (and other moon-size things): 2048 color, 2048 normal The hirez versions would be 8192 for terrestials, 4096 for the Moon (8192? Maybe worth it), and similar rez normals. For the Moon, does a 4096 heightmap provide sufficient resolution? That's what I've been using so far (especially since except for converting raw DEM data the 5760-wide Kaguya map was the best I could find, and that needs to be made power-of-2). DarthVader: I already explained where the textures are. Look at the StretchySRB OP, it has links to all textures used. I don't think it uses any unreleased textures; what I referred to was that ferram probably tweaked the *stats* of some things for that launch. blux_: Ack, sorry! Reorganized the repo, forgot to fix the link. Fixed. jsimmons: your best bet is to go back to using legacyAtmosphere with a scaleHeight of 7.5 for the earth (i.e. don't change the pre-V6 atmosphere of earth-sized Kerbin). That seems a reasonable increase from the 69km atmosphere of Kerbin-scale Kerbin. Since apparently in the Kerbal universe atmospheres are much "cleaner" mathematically and feature perfect uniform exponential decay

Excellent!