NathanKell

Make sure that none of your mods reference any Squad assets though. For example SXT depends on Squad textures.

RealHeat is a WIP right now, waiting to replace Deadly Reentry.

jlbasey: Please follow the guidelines in the How To Get Support Sticky What you said tells us NOTHING.

Another user has been working on adding nodes (read the last few pages of the thread). Woo open source and forking/pulls.

rescaleFactor is currently bugged when MODEL nodes are involved. You need to leave it as =1, always, or these bugs will occur. Here's my usual spiel on scaling: 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.

Starwhip: First, it sounds like you're making a part, not a plugin. A plugin is something compiled to dll. Second, you will not be able to find a stock solution (short of running fuel lines, 1 per radial part), because that's not how stock works: radially attached parts do not flow in. That is exactly why I had to make the plugin I did.

I suggest PMing r4m0n.

You said "Can't go by the folder size for this because some small mods use more RAM than its filesize..." which is the *opposite* of what I was talking about: KSP *compresses* textures on load, so in a few small cases textures will take more RAM than disk space (solid-color PNGs) but in most cases, textures in RAM will take much *less* space (512KB in RAM, 3MB on disk for a 1024x1024 MBM or TGA texture).

Not only that, it's not loading *parts* that takes up memory, it's loading textures. As of KSP 0.20, textures are loaded independently of models are loaded independently of cfgs; only once *everything* is loaded into memory do they get connected.

That looks nice!

Glad you got it sorted out!

No, you don't need a credit card.

You probably didn't change the name= line. That means the new copies will have the same name as the old copies, so when KSP loads your ship it loads the part-with-the-name-that-got-saved, and the first part it finds of that name is the old part. That said, please do a search on the forums for welding; after KSP 0.20, there's no reason to copy models. Instead use MODEL nodes to reference the existing assets.

Starwaster: Point 2 is no longer true, I fail gracefully in v7+ braininator: awesome!

O Nerd: Yes, that *is* for RSS. That's why it's not the original link. However, it hasn't been updated for v7. Instead, you should use Trigger Au's Transfer Window Planner, which is that, but ingame. Luscion: Do you have everything the OP of this thread says you require?

Thor-Deltas would be awesome in addition, yeah.

Then you didn't install it right.

Stock issue. It's how fuel flow works.

Ouch! Best of luck, and fingers crossed.

Cpt. Kipard, pointy nosecones are *exactly* as aerodynamic as round ones in FAR; they're all treated as a conical frustum with the front as radius 0--so long as the front is not literally flat, it will taper to 0; FAR ignores curvature in its taper calculations. In real life, of course, a bit of curvature *does* help.

Kiwiak, please package that in a zip following the addon rules. One can't just post a dll these days. (In particular, the zip needs a license file pointing out that it is MIT licensed, and who the author is).

Sorry, still not sure what you mean. Are you saying you want Kerbin at 10.62x scale with all the other planets converted to real planets? There exists no prebuilt config for that; your best bet would be to just use the Kerbin section of the 10x config, but the rest of the normal RSS config.

That seems like something to bring up on the TACLS thread.

Not a MM bug; MM just changes cfgs before they are read by KSP. If you remove it, TweakScale no longer gets applied to anything, that's all.

While I doubt very much that saves will break per se, spaceplanes (and spaceplane craft files) will. From the dev notes: