NathanKell

Doing that is actually much harder than I thought it would be. Planned, but not for a while.

Rhidian: yes, it's possible. If you moved Kerbol, presumably all the bodies orbiting it would move with it. Tidus Klein: a part's temperature is part.temperature. So you'd just check the temperature of the part attached to the bottom node of the precooler. Not sure what you're asking with the second question. Presumably you'd just add code in OnFixedUpdate to check if activated, and if so, do stuff?

Sarbian: by "unlock in pitch" I guess I actually mean "lock to surface prograde pitch value", which works exactly the same.

That looks awesome!

Piwa: thanks! Spanier: it doesn't do anything since changes need to be made on Squad's side for it to work. (You can look at the source to see how I attempted it--you can get the tilt working in scaledspace but when you're near the planet the reference frames get screwy.)

Spanier: Ah. Both RftS Engines and SFJackBauer's real engines do engine resizing as well as stat changing...and one or the other is pretty much required for RO (hence one or the other being included ). Oh, right, but SFJB's engine pack doesn't touch stock engines. Try RftS. You can try recompiling it for .23 and seeing what the errors are; I doubt the system changed that much...

1. Yes, you can. MM patches are processed like so: first pass does all regular nodes, second pass does all @NODE[name]:Final style nodes. Each pass is done in file-loading order (i.e. starting in root of gamedata, go to alphabetically first folder, then first folder inside of that, etc., load all cfgs in alphabetical order, then go to next folder). This is why RO patches use :Final whereas RF ones don't. 2. Thrust shouldn't be changing; let the engine configs do that. Everything else should be 1.6^3, yes, although for aerodynamic or other "hollow" parts like fairings / nosecones / etc, it's more like 1.6^2.2 or so. What part would you be rescaling that has thrust? 3. TTNeverUnload is throwing exceptions. Probably not .23 compatible? Remove it.

Oh, I'm not saying don't use it, I've used it myself at times. I'm just saying (a) it's not a "fix" because "PQS is slow" is not a bug, and ( it has issues.

An issue here is that Kerbin just isn't that dangerous a place to reenter. (That's what the shockwave mult and exponent are for, per OP.) Solar panels break due to code in their module; same for antennae in RT2. It *is* a decent idea to add similar functionality to DRE, to add a max dynamic pressure value to parts and break them if that's exceeded. But usually temperature and G-force suffice to kill unshielded probes in poor reentry corridors.

I love this idea! As it happens, what I do in DRE is really a hack for this. What it *should* do is decrease the crew's *health* due to G-force, and when *health* gets below a certain limit kill them. In fact, the damage levels are set for a bit more than "longest time to suffer x G force *without damgage*" rather than without death. I don't know if you want to take this on, but what I'd love to see is for this to morph into a slightly-broaded-scoped mod that dealt with crew health. That is, microgravity would decrease health to some threshold; unable to exercise at all would decrease it more; G damage would decrease it (at a rate also proportional to existing health, so weaker Kerbals experience more damage). It might also be worth considering tracking two stats, health and fatigue--or something to model the fact that people in microgravity don't have broken bones, even if they lose bone mass and (usually) muscle mass, whereas people who suffer crushing Gs may take internal damage. Further, you could increase fatigue on EVAs (which are supremely tiring) and limit ability to move when a Kerbal gets too tired. You're of course free to use any and all DRE code you like. I also like your idea of separating out short vs. long-duration G exposure. That's what I tried to hack with my cumulative formula, actually, so that a long exposure to 6Gs was roughly equivalent to a short one at 12, and that having *both* is bad news. But it's a minimalistic, simple model...

Spanier: I wasn't planning on it, since Stretchies will do for most things, but if you want to make one I'll certainly include it! The additional part mods are not essential, no. They just give additional options. What you're seeing is on account of some plugin's code dying. Post your output_log.txt; my guess is it's something like having two gimbal plugins, or installing both MFT and RF, or something like that. Or maybe having both HotRockets and RF? eggrobin: don't *all* pressure vessels' mass scale linearly with volume? I *really* like the idea of RCS feeding only from bladder tanks, especially since right now (HTP, N2O) we have RCS fuels that are also oxidizers, and it's hard work to prevent cross-feeding; it'll only get worse when I add biprop RCS. It sounds like eventually I should implement an "add tank" interface with some comboboxes for RF, to select resource and tanktype. That'll take a fair amount of rewriting though. Zyglrox: I just noticed that SFJackBauer is actually *never* setting maxTemp for engines, and leaving heats as original (pre-DRE) heat levels. Since DRE generally halves engine temperature, then yeah, halve the values in the configs.

It's the PQS. Planetary quadtrees are expensive, and they're doing basically all the work on the CPU. (They kinda have to, given how PQSMods work, but there are ways...). What really would be nice is if they could just render the entire ocean in the pixel shader, which I think should be possible (check if z-value of pixel is underwater from camera POV, render blue if so, etc).

1. I think Java would probably be best for this; most people are going to have JREs, or if not will probably better know how to get one, and you get nice cross-platform GUI. (And using the GUI it'd be easier to select which mods, or which mod-groups...). You could even, dare I say it, add a wizard for installing and configuring some settings. 2. Hey, thanks for *doing* this!

Try increasing the flatten radius of the mapdecal (it's only 10km radius at the moment; to scale it up proportionally it'd be 75km!), and increase its absoluteOffset until it's the same height (roughly) as the surrounding terrain (and increase the repositionRadial of KSC by the same amount). Yeah, make sure the lat/long of the two are the same (or not, if you want to move KSC around on the map decal!).

Not for all that long you won't. I'm sure we'll get humans in before too long.

That "fix" for the ocean is...um. Not a fix, you're just turning the subdivision of the quadtree used for the ocean down. The issue is that for planets with oceans KSP renders two procedural planets, one land, one ocean. If you turn the subdivisions down, the ocean's surface level will be weird, since what happens with the PQS is (by 2D analogy) fitting a polygon to a sphere, and you know how much more gap there is between a square inside a circle, and an octagon inside a circle...that's why the water level appears to go "up" or "down" when you change max subdivisions.

The way I'd do the autopilot--although I'd ask Ferram and asmi (who AFAIK know this stuff best!)--is set a turn start speed, an initial turn pitch and azimuth, an AoA/Sideslip limit, and a final pitch limit. Autopilot acts as follows: 1. Burn vertical until velocity > start speed, rolling to place +Z along azimuth 2. Pitch over (aka pull up, since +Z will be aligned with azimuth) until aligned with initial pitch/azimuth (pitching slower if necessary to keep AoA/sideslip below limit). 3. When velocity vector passes desired pitch, (unlock pitch and) follow it, but stay locked in azimuth (yawing to return to desired azimuth, limiting yaw to keep within sideslip limit, and rolling to keep +Z stabilized along azimuth line, aka vessel roll parallel to the surface). 4. Lock pitch again when pitch = final pitch limit. An addition, for the circularize-after-apogee type of rocket, would be an "unlock pitch altitude", when >= that altitude, immediately pitch over to final pitch and stay there. Or perhaps key this to stage number? This would allow a gravity turn until high enough apogee, then a horizontal burn to circularize. Since the switch from prograde to horizontal usually accompanies stage separation, it might make sense to key to that rather than a pure altitude thing, but altitude is probably more flexible.

check StretchyTanks/Parts/tech.cfg for a listing of the nodes and diameter multipliers (width will be 2.5x the multiplier for tanks and 1.25x for SRBs)

Still working on known issue with stretchies nodes. .. Coords for KSC and the map decal are latitude and longitude. Inexact because the earth is non spherical but ksp planets are spheres. Just find the latitude and longitude of a pad at Woomera and use that. Note that I use decimal degrees of lat/long, so convert minutes and seconds if given to decimal. Also, S and W are treated as negative. (KSC is N28 W80). Set it. Then check it out in game and then modify the heights to match surrounding terrain.

This is already 1:1 IIRC

Well, here goes. I'm now ready to release a test version of Earth. NOTES: 1. This will gobble up a couple hundred megabytes. And no, these files will not be touched by rbray89 (though you probably need to run ATM to compress everything else) since I put them all in PluginData and load them myself. 2. It comes set for maxLevel 14 (!) so turn it down if it chugs too badly. (In RSS.cfg). Note that the value set there should override anything in your KSP/Settings.cfg file, but just in case, find your current preset in Settings.cfg and find Kerbin within it and change maxSubdivisions to the same thing you set maxLevel to. 3. I have changed the SS<->PQS fade range so that PQS should remain visible in really-low orbit. If it chugs too badly in orbit change them back to the commented values (look for the block that starts with SSFStart and ends with PQSdeactivateAltitude) 4. Feel free to mess with all values in the file. Crowdsourcing is cool! I've exposed tons of new settings you can change in the CFG. 5. If you want to export a map of the terrain, change fooExport to Export, and set size as desired. A 1024 takes me 12 seconds; a 2048, 37; etc. Exporting is useful to get an overview of your terrain height and landclass changes. Exports will be in your KSP folder once you reach mainmenu (a colormap and a heightmap). 6. No GUI yet for launchpads. In RSS.cfg, find the MapDecalTangent block and the PQSCty block, and change their latitudes and longitudes to desired location. Then increase the decal's absoluteOffset to match the surrounding terrain, and the PQSCity's repositionRadiusOffset by the same amount. Passing over mountains in northern China. Oh, and scaled-space meshes should be all perfect now. Download RSS v6_pre1

Ok, long as it works for you, that's cool

Huh, interesting!

Let's talk about the very cool, very pretty rocket, ok? Let's leave rocket-length-measuring out of it; if you're not interested in it, you needn't waste time reading the thread.

This sounds great! Love, love, love this. Thanks! Two questions/requests/etc. 1. Is there any way to compile it to a stub? The sorts of folks who would want a pack might not be the folks to (a) clone a GitHub repo and ( grab a Ruby runtime environment and © run it from it. Even better a GUI. 2. Is there any way to, instead of relying on a local mods.yml, rely on a web-based one? (That, hopefully, someone will pledge to keep up to date). Mine use non-permanent dropbox links....and you're tracking version numbers anyway. That way one wouldn't have to redownload the tool each time.