NathanKell

Interestingly, that's exactly what RP0 is trying to do, although with the assumption that people are using Realism Overhaul, and moving nodes for a fun realistic career. Taking node names as given, and also what parts are in nodes to some degree (although we will be shuffling parts some), and rearranging them and their links.

NEAR is *simplified* FAR. Simple does not always mean easier. When simple is "removed mach effects" that makes reentry (where mach effects make reentry easier, by giving lots of drag early on) quite a bit harder. From UmbralRaptor's signature, ferram4 on NEAR: By that I mean "if you're building a high-performance jet, make it look like real high-performance jets" and "if you're building a rocket, make it look like a real rocket, i.e. faired payload, aerodynamic needle shape, possibly with fins at the base, low initial TWR." Wait, the OP of which thread says it doesn't support 0.25? FAR, NEAR, DRE, and TACLS all support .25. For TACLS, there's a GUI visible in the VAB/SPH that will tell you how long your life support supplies will last with current occupancy and with maximum possible occupancy.

How do you handle deciding on DXT1 or DXT5? Sounds like those textures should be made DXT5 (due to the alpha) but aren't.

Hah! Awesome.

Isp relates fuel flow in mass units to thrust. You don't have to worry about fuel density, always burn your least efficient fuel first.

You also have to deal with people who won't let this die. Dragon01, if you really want to talk about this, please do it on the relevant thread. Please don't keep resurrecting the argument here.

As requested, applying some

komodo: Thanks :] Note that it doesn't actually scale up the effectiveness at all, just the loss rate. One might also want to increase the dissipation rate a bit, and for some things take the loss rate down a bit (my shields are hovering at about 400C on reentry, and run out to fast.) But the main point is that it's possible to change the stuff by math.

NEAR is much, much harder than FAR with reentry. As for how to use them: For FAR/NEAR, design planes that look like planes, and rockets that look like rockets. Don't overspeed (use sane TWRs) and don't deviate much from the prograde indicator (high AoA or sideslip is bad) For DRE, enter at a shallow-ish angle, so maybe a periapsis of 30km? For TACLS, bring enough life support.

Part testing contracts will often enough require something like the X-15. In addition, it might make sense to have (a subset of) speed and altitude records only settable when under thrust. Our plan is not to add custom-tailored science experiments like RPL.

The body's radius is scaled. However, if the various terrain-creating PQSMods had all their deformities scaled up, you'd have 70km mountains. That would be....very odd. Instead, the PQSMods are tweaked to generate good terrain for a planet of the new size.

Ok, I'll try to replicate. Clean install of Pwings + NEAR + ModuleManager, yes?

No. No color maps are duplicated. No files inside a PluginData folder are loaded by the game unless a plugin explicitly does so, and when heightmaps or vertex color maps are created, one loads the file into a texture, creates a MapSO from it, and then frees the original texture. No duplication (except to the extent that MapSO is wasteful).

I checked the DDSLoader plugin, and it turns out it doesn't support either keeping things readable, or 8bit textures. That means you will need to leave anything used in a PQSMod as png. However, if a texture is used *both* in a PQSMod and for the Scaled Space color map, you can leave the PNG in plugindata and make a DDS copy of it to point SSColor at. Here's how to test (I realize I should have actually left instructions): 1. For each Color and _NRM file, make a copy in the main RSS folder. 2. Run the converter (making sure it doesn't touch inside PluginData, as I think it now, properly, does not) 3. Change all SSBump and SSColor references from GameData/RealSolarSystem/Plugins/PluginData/foo.png to RealSolarSystem/foo (assuming you now have a foo.dds in the main RealSolarSystem folder)

Ah, yeah! You did one of the dedupers for Internals, yeah? That needs to be part of any unofficial patch, I think. Lack: I am unsurprised that the only engine models whose textures you use are the sane ones. I'll see if I can do up a regex-based MM patch to handle all that.

There's two problems here. One is that, to make DRE deadly on Kerbin, it *does* look like the heating model may be pumping out a bit much heat. The second, worse, one is that DRE is at best a bandaid on the stock temperature model, which is a *temperature* model, not a heat model. No matter how much or little thermal mass, no matter how much or little heat capacity, KSP and DRE don't know and just apply degrees Celsius as the way to heat things up. Also, the stock dissipation model is quite, quite wrong.

The DLL on github should now support GameDatabase references for all textures. That means you can convert everything to DDS and use Sarbian's DDS loader. I would like to have it tested before release, however.

jrandom: huh. Confirm on latest from git, then post an issue on the repo? Phylan: That would be pretty cool indeed!

Fixes like what? What needs fixing?

Gotcha. Will tweak. EDIT: Have tweaked.

1. Unlock the joint code. KJR can no longer do the strengthening it once could due to how locked and protected the joint code currently is. If you want non-wobbling parts, ask Squad to un-hardcode the joint code. 2. Various one-line bugfixes that have been found and passed on to Squad over the last two years but not implemented. Bugged intakes, the "part blows up in the editor" bug, the "atmosphere cutoff" bug, the ModuleRCS PROPELLANT bug

I believe you were just ninja'd

Poked. What step should I add though? How does US break them?

It is indeed generally best practice not to bundle, but rather to state your mod requires other mods. This way you don't have to worry (and, importantly the other mods' authors don't have to worry!) about you shipping out-of-date versions.

You will need to increase scale lines by 6.4x and decrease speed lines by 6.4x. (Though if this uses EVE Overhaul, you can leave speed alone). You also might need to change altitudes upwards to decrease zfighting in scaled space.