NathanKell

Nothing much to add, just a +1 on excellent work RedAV8R

Thanks, that's quite a howler. Fixed.

Working as designed, it's a good thing.

It's definitely not the right formula for calculating tank volume, alas. Tanks are pressure vessels, and KSP "tanks" of liquid fuel and oxidizer are in fact outer structure, and inside are two (usually) capsule tanks.. Note that how much of the cylinder is in fact used for tankage depends on cylinder length vs. diameter, it's not constant. Short, squat tanks like the FL 100 might be made up of a dozen very small capsule tanks, since were it to have only two, only about 50% of the volume would be utilized!

Change the offset of the heightmap.

A_Burnt_Rodent: you can remove it, yes. If you leave it, it will gracefully fail to load. And I pulled MM 2.4.5 from the main trunk, but I think Sarbian may not have updated the OP. Northstar1989: This is perfectly compatible with saved craft. Saved craft don't generally get put in the RealFuels folder in GameData. RealFuels does not include any engine configs at all. See the second post in this thread for where to get engine configs. If there are parts that contain *fuel* that RF doesn't edit, please mention them.

There's a commented out (foo was added) export node in Kerbin's cfg node; copy-paste it to desired CB's node, and uncomment it. Set maxheight to the maximum displacement in meters (i..e what you want white on the heightmap scaled to, vs black). Remove oceancolor if the body doesn't have an ocean.

Only the UP25 came with DRE originally. I later added the UP13 for consistency, and then, for compatibility with RO, added the other sizes. Other than the UP25, they were never intended to perfectly match the shields, since the only case where there was a real mismatch with the stock decoupler was with the 2.5m pod and heatshield. Also, I will just point out that Starwaster does about 80-90% of the tech support in this thread (which is incredibly helpful), and also does support for a bunch of other mods. And in general, people don't deserve to get reamed out for trying to help...

Motokid600: all you can do is poke Borklund about it.

It can with all other satellites inside its cone of view. If the satellite is too near a planet, not all the things orbiting it will be near enough to the center of the planet (what the satellite with the dish aims at) for them to be in-cone.

HOLEEE CRAP. There are not enough <3s in the world. One suggestion: that upper ring on the nozzle looks a bit too thick to be for regenerative cooling; since there's already an exhaust pipe, it wouldn't be piping turbine exhaust into the nozzle. Well, ok, actually two: you can take this opportunity to remove that cylinder on the far side of the engine from the gas generator and the exhaust; there's no reason to have *two* gas generators (or that third one?)

Changelog: v7.4 \/ *B9 configs removed from RF; they are included in B9 itself. *Fixed so tank-switching can be done after a database reload *Added procedural cost, with taniwha *Fixed refueling pumps again, with taniwha (they respect flow and flow type, and cost funds) *Autoconfig buttons moved to the top of the list, and fixed (will now treat jets etc properly, and both multimode modes) *Supports multiple ModuleEngineConfigs per part (i.e. Multi mode engines, engine+RCS, etc) *Maeyanie: add support for SXT and KAX *Removed some unneeded Firespitter entries *Supports Tweakscale again, internally. NOTE if you do not have tweakscale, you will get a harmless exception in the log about failing to load Tweakscale_Realfuels.dll. Ignore it. *Made all RCS tanks into ServiceModule tanks (finally); deprecated old RCS tank type. *Aristurtle Support blackheart's AJKD and KSLO mods. *Raptor831: Support for Kommit Nucleonics, KSPI improvement, Near Future Woo, finally! Note the note, and make sure you nuke your old RF folder first, as the OP says. Files *were* removed.

It's the same solution, alas. It just makes the cockpit clippable, and moves the radial attach node to the best position. So now we can not-awkwardly clip, which is still a great advance, so thanks OP!

Detecting fine controls is easy. Overriding the binding is less likely, not sure you can consume the key before KSP notices it. However, what you can do is check when a trim key is pressed, and then yourself subtract a portion of the trim that was (or is about to be) added. It won't work perfectly in edge cases, but it should work decently well.

While we're suggesting suggestions, I have another suggestion! Add "fine trim" keys, so you can vary trim in lower steps. With decent control at low Q, it's very hard to trim out at high Q

After .25 gets done (and I get a couple things finished off) I'll try to devote some actual time on Kopernicus dev. It'd be nice if my status as collaborator meant more than "can merge pull requests"

TranceaddicT: cool! Luscion: Real Fuels does not, itself, provide engine configurations. Check the second post for engine configs. It does configure FASA tanks (mostly--it may not be quite up to date) when FASA is installed and RO is not. However, while support for FASA is not *finished* in RO, it does work pretty well.

I suggest checking out this similar project.

That means something broke when you installed it.

.dll files are compiled source code, yes. The KSP wiki has some good info on how to get started making plugins.

They are flags/logos of the various countries and companies involved in the LV and satellite construction and the launch.

I am happy to report that kspmodders.com is back up, and so TreeLoader will again be able to grab trees. Thanks, r4m0n!

MeCripp: ['code] and ['/code] (remove the ') tags. Here's my usual paste on scaling btw, might be helpful. 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.

Here's a tutorial on MODEL nodes. Before KSP 0.20, each part had to have its own model.mu file (signified by mesh = model.mu) With KSP 0.20 and later, a part.cfg can reference *any* model in KSP. This is because models, textures, and cfgs are all loaded independently now (first all models and textures, *then* all cfgs, and *then* all cfgs are processed and parts are compiled). Note that GameDatabase references are the relative-to-GameData path to the file, minus its extension. So instead of copying all the stuff, you could do: (replacing the mesh = model.mu and the node lines with:) MODEL { model = Squad/Parts/Structural/structuralPanel1/model scale = 2.0, 2.0, 2.0 } node_stack_top = 0, 0.055, 0, 0,-1, 0, 0 node_stack_bottom = 0,-0.055, 0, 0, 1, 0, 0 node_attach = -2, 0, 0, -1, 0, 0, 0

Fuel lines, crossfeed, all that stuff applies only to resources with STACK_PRIORITY_SEARCH flow. IntakeAir, like electricity, is ALL_VESSEL. Starwaster: Yep, I know the units/required increases. Working as designed, just like ion engines (Best bet is to use AJE, which does to jets what RF+enginepack does to engines and FAR to aerodynamics.) TranceaddicT: yep, as cremasterstroke says, plugins in KSP that (hard) reference other plugins will only work with the version number of the other plugin they were designed for. Since RF has been updated since Tweakscale was, Tweakscale's RF-supporting plugin won't be loaded by KSP anymore (it wants a different version of RF). That will be fixed by RF next release. But note that (for next RF) if for some reason you don't have Tweakscale but do have RF, you will get that message complaining about a missing tweakscale Basically, those messages are the plugin equivalent of an MM NEEDS[] block failing.