NathanKell

Cool! Thanks. I promised asmi I'd do it myself like a month ago, but I've been super busy ever since and I don't know your code like you do.

Hey cybutek, any hope of getting support for engines with corrected thrust (i.e. thrust scales with Isp so fuel flow is constant, and sea level TWR != vac twr)? You can check if an engine has a ModuleEngineConfigs or ModuleHybridEngine on it.

https://github.com/NathanKell/StretchySRB

I usually use git[hub], but as I was continuing others' work in MFS, DRE, and ST, I hadn't posted my own repos. I'll do that now. The ST code is a bit weird, mind; when I first added the SRB it was a real hack, because I'm using the RT-10 model just for the nozzle. I never had the time to make my own nozzle and set it up in Unity. I mean, all my changes to ST started out as minor patches to AncientGammoner's code, so they're all rather hacky. I apologize for the mess. :S

Yeah, if they all use the same texture it's pure wastage and you'd save a TON of memory. Even if not using model nodes, if you just put them all in the same folder...

ferram: will do! wasmic: as starwaster says everything is configurable. Every single change is based upon the values in the RealSolarSystem.cfg file (or the RealSolarSystemSettings.cfg file for non-planet-related stuff). I barely have the time to breathe right now so I'd rather not maintain two versions of those settings, but it's not at all hard to create an alternate config; remove all the referenceBody = lines, change the orbital parameters, and that should do it for now. iVG: Remotetech2 antennae should draw 1/10 to 1/100 what they do now. For batteries and solar panels, a few pages back I posted my Realism Tweaks zip that fixes them all. I'll start a new thread on that.

e-dog: Oh, we can do that with the current single texture. I'm just saying if the fairings used two textures, then the fairings could share outer textures with stretchy tanks, which would save a lot of RAM and texture-making time. My specialty is writing the code to transform a model's stats into a realistic amount of fuel. Not so much the actual transforming of the model. :] That's why I was either hoping you'd do it (the visual side), or that I'd just use the existing procedural interstage and accept it wouldn't look right if there were no parts above or below it. DREC has two issues. One the heat shields aren't re-rated for Real Solar System's earthlike (because earth-size) reentry, but rather they're still set for Kerbin's nice-and-cuddly not-really-deadly 2km/s reentry. The other is that one often loses the ability to click when all parts are destroyed; this is a stock issue that DREC exacerbates, and I have some idea as to how to mitigate it thanks to ideas from FlowerChild (which I will try in the next few days time permitting, along with new values for the heat shields). Other than that, it's quite solid: there are patches available for the heatshields, and the no-click bug can be gotten around by reverting, launching, and reverting again.

Frederf, I'm sorry, but I don't really understand what you're saying. Can you try again? nullreference: I'm rewriting how DRE does all that; we'll see if that helps. TechnicalK3rbal: Yes. It only protects when the craft is travelling in that direction (or from all sides if direction is 0,0,0). So a heatshield with direction 0, -1, 0 will only protect when the craft is traveling retrograde.

ANWRocketMan I second your request (for obvious reasons ) It shouldn't be hard to write a controller for that. Compute delta-pitch and delta-yaw to desired heading; make a small rcs burn in the correct ratio; wait for (near) correct heading and make the killrot burn.

Loving this! Ideas for how to have radiation affect Kerbals and/or probes/parts: Screen darkening or noise appearing (vision loss / signal issues) Part failues (perhaps using HoneyFox's RandomFailures mod?) i.e. a decoupler decouples early, or will not decouple on command. Part destruction (antennae, batteries...) Random flybywire controller added, so craft does random attitude changes Conversely, control locks: throttle is locked, or pitch control is "stuck" down or up, etc. Or, one axis is unavailable: to yaw, you have to roll and then pitch. If using KOS, corruption in the active program, or the volume.

That looks great! And just in time--I'm going through all the engines to create an RSS / real-scale config for MFS, and I desperately need new small engines. A request: for the vacuum-optimized engines, can you give them real vacuum-optimized nozzles? I.e. closer to cone than a "fat" bell, very high area ratio (wide end, narrow throat), and quite large (for shape, see Kommitz's nukes--your own LV-Nc is close, but the throat is IMO rather too wide). How large? Like, an engine that produces 15kN thrust should have a nozzle as large as the Spinnaker, at least. You know that giant bell on the back of the Apollo CSM, about 3.7m wide? 91kN thrust, massed about 0.3t.

We desperately need more probe parts IMO--what about basing something on those solar panels you already have, and releasing a solar panels set? Especially for the realism rebalance (where even the Gigantor only generates 1.32EC) we need more panels. Other probe parts: scientific instruments, especially cameras. As kerbtrek says, KSP is CPU-limited and RAM-limited, not GPU-limited, so while normally you'd do fine detail with a normal map, in KSP right now it makes sense to do it as geometry and use smaller and fewer textures.

Hey e-dog, a question for you: might it be possible for you to export the fairing side mesh such that the inside and the outside use separate textures? Then you can use the code I wrote for StretchySRB to support adding new textures arbitrarily (support via confignode) and switching between them. It also means they could share the same set of textures as the sides of stretchy tanks, meaning textures wouldn't have to be duplicated (that's why I ask re: exporting with two textures). I assume I'm not the only one who uses procedural fairings / interstages to make curved rocket/plane fuselages? Another thing you might think about: IMO it would take very little work to turn the procedural interstage into a very shapeable fuel tank. Just keep the fairing sides always attached (or, if the current way you do things require they be separate parts, ah well), add a top cap, and change the interstage model so it's just a bottom cap. Then we can make tanks of any top and/or bottom radius, any height, and even have curvature! I've been thinking off-an-on about trying that out by making a modified version of the StretchyTanks module, but I haven't gotten around to it and figured it'd be best to touch base with you first anyway.

li7in6: very cool! Would you be interested in doing another version of the configs for when (I fix it and) Cilph releases the next version of RT2 with my new range model? It has multiple antenna support (total omni range = strongest + 1/4 * sum(all other omnis' ranges) ) and a new range model, where max range for a connection is shorter_range + sqrt(shorter_range * longer_range). It's somewhat more complicated to use, but IMO leads to a much better feel--you can have a large base station antenna and only a few small ones on your satellite, for instance, or you can have a small dish on your Voyager-alike and a BIG dish at home. Hey, yargnit, you're using DRE now!? Regarding DRE and RSS: FlowerChild and I have been playing with heat shield values. The correct solution to RSS is not to nerf heating (which is actually at its realistic level) but to better model real heat shields. Until I get detached shockwaves working, that'll be by tweaking heat shield values.

As it happens...if someone will do modeling for me, I can write that. I've been meaning to post a request thread, but been busy enough I didn't really want to take that on now. But all the work I did for the MFS spreadsheet means I have a pretty good idea how to calculate everything. That's true of stock KSP: for some reason the Xenon tanks have super-high volume, unlike the other tanks in KSP. I've been meaning to fix that and rebalance it all, just haven't gotten there yet. My understanding was it used N2O/Amine for all spacecraft engines (RCS and Retro) Cryogenic tanks are lighter per unit of LH2 and LOx stored than regular tanks. Other fuel combinations will be heavier than an equal-volume regular tank. The loss rate is lower for LH2 and LOx in cryo tanks. The loss rate per second is given in RealTankTypes.cfg for each tank type. IIRC loss rate is roughly halved by using a cryo tank. Thermal fins will help keep the tank cool (regular or cryo) and would be useful for longer missions. Although Starwaster has found some issues with the way KSP handles heat that interferes with the fins, and is working on a rework. I think people should read the first post rpayne88: you have an install issue, some old version of a MFS config file sitting somewhere. Try a clean install, like Milkshakefiend did. FanaticalFighter: I wouldn't exactly call the Merlin Vacuum the "same engine" as the Merlin 1C / 1D. Takes changing the nozzle a good bit, and they probably also changed the compression ratio, though I don't recall. Same turbopump though, I'd think (it's another of theirs that's pressure-fed). SRFirefox: that's super helpful! Will do.

Decoupler doesn't make a different. What matters is the ModuleHeatShield and the AblativeShielding resource. Also, please use the Deadly Reentry Continued thread. That's where current work and discussion on this mod is going on.

Hey, when I add NTR support to modular fuels techlevels system, you can just use that--that's _exactly_ what the techlevels system does.

More probe parts are _sorely_ needed.

Decrease the (magnitude of the) values in the module generators (i.e. add some more zeroes) . Thanks for the catch!

Wow, that's really impressive. Nice job!

That's _really_ weird. They shouldn't. Thanks!

Well, pick one. Shield looks nice!

KSC, of course. :] Well, and one at Baikonour, one at Kourou, etc. Although for my own purposes I'm adding one in Tanzania. Regarding the pack itself, took a peek. I note you have doubled textures in the BoulderCo folder--KSP ignores extension, so you need _either_ a png or a tga or a mbm or a jpg but not more than one or you're wasting memory (and who knows which it'll pick). Also, can you include an edited common.cfg with the distances scaled up so that clouds appear when in PQS mode? Other suggestions: for square detail or bump textures, you need to set the x scaling to 2 times the y scaling (otherwise they'll appear quite stretched). Unless that's intentional. Or you can just use textures that are already 2:1 rather than square. You also might want to play with the radius values so that, for instance, Kerbin's clouds aren't 25km and 50km up. Try 1.003 and 1.004 for Kerbin? That means 20 and 25km roughly, which is a bit better. Any lower and they start clipping the scaled space mesh. Even better, just get used to using the same aspect ratio for all cloud-related textures as you do for the planet textures (i.e. 2:1) and then you can leave scaling at 1:1. Also, and this is something I keep bugging rbray about but s/he still hasn't done it, you NEED to be using power-of-two textures; Unity _will_ scale non-power-of-two textures, either leading to ugly loss in quality or wasted RAM. That means i.e. 2048x1024, not 640x320 (use 512x256 or 1024x512 instead). Oh, and since KSP converts textures itself anyway to a format that takes more memory than jpg, there's really no point in not including a losslessly compressed texture (PNG or TGA, though each has issues) or an uncompressed texture (mbm). MBM takes the most space on disk but (apparently) the least in ram, because the TGA loading code is bugged; png loading code has a different bug (it doesn't take more RAM, but it also doesn't get mipmaps generated so it flickers when you're far away). Best bet is probably make PNGs and use the PNG to mbm converter? (Then, obviously, delete the PNGs so there's only one texture each in the folder, per above). Hope that comes across as advice, not criticism; the work you've done is very pretty!

A page that might prove very useful to you, rbray, given your earlier question: http://chrisholden.net/tutor/rocknorm.htm I'm playing around with the technique right now, since the existing normal map doesn't work right for RSS. Also, is the alpha channel of the detail texture supposed to do anything? It doesn't seem to, for me.

nguyenmanhtuan69258: have you edited common.cfg in your citylights mod? Set the cutoffs to 2000, not 200. mushroomman: Very nice! OK, I'll uncomment and try to fix the code I was using to replace textures directly in RSS, so as not to be dependent on UR.