NathanKell

It is and it isn't. It's KW rocketry: aka Kyle and Winston. Just Kyle posts a lot more...

Very nice!

Raptor831: Do want (xls that is). I'll update post 2. Thanks! (I may, for stockalike "simple" feel, adjust so all ratios are consistent in fuel groups...IMO if you're wanting a stockalike feel you probably want hydrolox tanks to always work for hydrolox engines...)

SpacedInvader: You seem to be mixing terms here. Heightmaps are used by PQS, and all the changes you did are to PQS. The scaled-space models don't have a heightmap; they get their vertex displacements from the PQS at game launch (although obviously they have a *lot* fewer vertices), and on that is placed a color (diffuse) map and a normal map. Let me ask a question: regardless of terms, which terrain are you trying to make look better: the terrain you get when you're close, or the terrain you get in (medium-high) orbit? On enlarging heightmaps: that's *already true* for Earth in v6 (it has the largest heightmap possible). And it's still a resolution of almost 5km per pixel. For the Moon, with another 8192 map (that's another 32megs at 8bits/pixel) it'll be 1.33km / pixel (which is *roughly* what Kerbin was in stock KSP, IIRC; I think they used a 2048x1024 heightmap?) As you can see, the various noise-based PQSMods are *very* necessary to make for good terrain in practice; heightmaps alone are far insufficient. WindShields: uh...? Have you *seen* how close Europa and Eeloo look?

SpacedInvader: it's not "the engine by itself"--remember there's a gig or so of textures in assets (like, say, all planet and UI textures), along with all the sounds and other resources. Also the Voronoi craters on the Mun take up a lot of memory for caching--I haven't tried disabling them, but doubling the frequency of only *one* of the PQSMods takes up like 500mb extra.

Sure! Please do.

Amazing stuff, rbray! Congrats! An idea re: z-fighting. Might it be possible to increase the cloud-sphere's radius based on camera's distance from the scaled-space planet? That is, when close, it could still be only 6km or so above the surface; when far away, it'd be more, to avoid z-fighting. Even if you don't see it much stock, it's a big issue in RSS with the 11x diameter planet but still wanting clouds only 6km or so above the surface! And my *guess* is that by the time z-fighting becomes an issue, it won't be visually obvious whether clouds are 6 or 30km above the surface...

Ferram, it's really ironic that it took breaking rockets when node size is wrong to finally get modders to fix their node sizes...just as you're working on an update that makes that no longer necessary for FAR.

e-dog, good to see you! I hate to nag, but I wondered: what is the status of fully-procedural (i.e. like the interstage) payload fairing base rings? With stretchies or PP tanks, tanks can be arbitrary diameter, so it would be very useful indeed if payload fairing bases could be as well! (And you'd mentioned, some time ago, that that would be next on the list.)

Phredward: in v4, sitting patiently on my disk and in github, I've set specificMass to 0.100, seems ok. If you look at the KW fairings, that has my best estimates on masses, which I haven't ported over to pfairings yet. In the Calcs.xls sheet (available from post 2 of RF), on the Misc page, you can see my calculations, based on fairing diam and height. Base is what the fairing base or interstage adapter should mass, IMO. (I have not yet backported those calcs into specificMass, which will prove difficult since IIRC my figues go up by the 2.5 power or so, and e-dog's go up by the cube). Armchair Rocket Scientist: Alas no. Someone needs to write a ModuleRCS replacement that accepts more than one resource.

This is the dawn of a great new era with you--texturing *and* modeling! Sweet!

Many part mods include these, FYI.

So you're saying Windows versions are the anti-Star Trek-movies. SpacedInvader: meshes take up very little memory, all things considered; I doubt it's worth the effort.

This isn't actually true--any engine needs to have at least one PROPELLANT with a density > 0. This is why, for example, Firespitter electric engines both create and use Coolant, so there will be some mass involved. This is because of how Isp is converted into fuel usage; Isp is a measure of how much *mass* of fuel is used per unit of thrust per second (or, put another way, one (weight unit) of fuel will provide one (weight unit) of thrust for (Isp) seconds). Otherwise ModuleEngines will be dividing by zero...bad stuff. DuoDex: I can give you the exact math if you want, but what you should probably do is just give your engine a *very* high Isp; you will find, for a given Isp, that the engine will use the same *mass* of fuel per second, no matter what density you specify in the RESOURCE_DEFINITION: this is because, again, efficiency as given in Isp measures how much *mass* of fuel you're using, not how many "units."

Uh, no. Three things affect scale. First, does the part use MODEL nodes? Skip to part B. A (MODEL node not used; instead "mesh = blah" used) 1. "scale = foo" determines how the first three numbers for each attach node line (the X, Y, Z coords of the node) are scaled. It does *not* affect anything else. Default = 1.0 if not present 2. "rescaleFactor = bar" scales both the model (and its transforms) *and* the attach nodes. Default = 1.25 if not present. B (MODEL node(s) used) 1. Inside the MODEL node, "scale = blahX, blahY, blahZ" determines the scaling of the model and its transforms. Default is 1.0, 1.0, 1.0. It does not affect node positions. 2. Outside the MODEL node, "scale = foo" works as above. 3. Outside the MODEL node, rescaleFactor works as above. HOWEVER, there is a bug in scaling. For parts with MODEL nodes, rescaleFactor is applied twice to the mu, *unless* (a) the part is the root part of the vessel and ( you've reverted to launch (or perhaps switched in flight? Don't recall). All other times, it is applied twice. What this means is that if you have scale = 1.0, 1.0, 1.0 in the MODEL node (or no scale at all), and rescaleFactor = 1.25, then your mesh will actually be 1.5625 as big, but your nodes will be scaled outwards 1.25. For this reason, when scaling parts using MODEL nodes, it is suggested to leave scale (outside the MODEL node) and rescaleFactor both at 1.0, and instead both change the scale = x, y, z inside the MODEL node and manually scale the positions of the attach nodes.

You can add a dummy module to each part affected.

Not sure about the jitter.... Re: maps. First of all, the normal maps are for the scaled-space planets; PQS terrain appears to have a normal map applied in the shader that's not exposed to the PQS itself (?)--just the vertex colors are. Most planets do have a heightmap for when in PQS mode; for Earth it's already at the maximum KSP allows (8192x4196) but I haven't redone Mun into the Moon's real terrain yet so that's still using the stock, lower-res heightmap (and lower-res diffuse and normal maps for scaled space).

Thanks! Aw yiss, F8F time. The Iron Works knew how to build 'em... Yes, yes you do. I need to make ones for brushed aluminum and X-15-black. I also need to enable it for proc surfaces and proc wing ends.

If you grab the scaledspace transform of the planet, find the meshfilter and then grab its material, you can change the diffuse and normal textures. (RSS does this on load, see RSS for example)

RSS, RF, RO, and DREC all seem fine. RF doesn't support the new parts yet.

So, you've renamed some mods' folders (never do this, it often breaks them), installed a mod into the Parts folder (never, ever do this--any mod released in the last year, literally, goes in GameData), and...I don't see anything obvious in the log. I suggest you start fresh, and follow *exactly* the install instructions of each mod you download. Let me know if that fixes it.

Fleet: Yes, that's the EE gimbal. And yeah, really don't know what to say. Do they still perform strangely if you surface-attach two engines, and try to roll? horndgmium: what version of KSP? What mods? Output log? Why are you thinking RO (which only changes part stats, it doesn't even have any code itself!) is doing this?

//Starwaster/NathanKell @PART[*]:HAS[@MODULE[ModuleEngines],@RESOURCE[ElectricCharge]] { @RESOURCE[ElectricCharge] { %isTweakable = false %hideFlow = true } }

I don't believe it has, other than MJ which Sarbian has already released a fix for.

The heat correction should work fine for anything that *isn't* specified in DRE.cfg, and unless Squad added a *third* new engine module, which AFAIK they did not. I have tested DREC for some time with .23.5 and found no problems. Barring any reports, I will release an official update tomorrow.