NathanKell

Kimaera026: just remember that KIDS doesn't work with MFS yet. Visari: cool!

Yup, Starwaster's got it. Pretty sure it's that the resource definitions are being processed as a single key/value rather than a node. KSP requires linebreaks to terminate node defines or k/v pairs. The linebreak between the nodename and the opening brace may or may not be OK; don't know.

FlowerChild: Yeah, could be re: update. Although, interestingly, you'd think it'd be the other way around. I'll do some tests. Regarding shields. Most shields have comments describing what they do, but here's the lowdown: The vector specifies whether the heat shield is directional or not; if the velocity vector doesn't match the direction you won't get shielding. (If direction vector is 0, then it protects in all directions) Reflectivity is as it says, you will get only (1.0 - reflec) of the heat applied. loss rate determines how many units of ablative get used up per second at that temperature at sea level air density. Note that the temperature here is the SHOCKWAVE temperature (surf velocity - 275, ironically enough), NOT the part temperature. So it's not that it won't ablate if the part is < 650C; it's that it won't ablate if velocity < 925 m/s dissipation controls how much heat dissipation each unit of ablative shielding gives when it ablates. Here, temperature is the part's temperature. (This could lead to the odd situation where if the values didn't correspond you could lose shielding without dissipation, a bug I fixed in v3). Actual heat loss = dissipation * loss rate.

Good catch. I'll clear that up.

To get FAR to recalculate your vessel aerodynamics, separate a part from it, that will force recalculation. Instead of using the 6.25, try with the 3.75 maybe? Also, why not use the latest DRE Continued? I've fixed a few bugs from the last release by ialdabaoth.

Short of looking at the CFGs myself, all I would suggest is take the amount for LF in the RESOURCE block and copy it directly in the PROPELLANT block on the ratio line so the ratio for LF is exactly the volume of LF. Do the same for LOX. Then if there's leftover LOX or kerosene, something's deeply bugged. ANWRocketMan: I currently have all planets in their proper orbits. Moons next. We're still lacking Saturn and Uranus and Neptune and their moons though.

Frederf: yes. gm537: I'll check them out.

Huh. I don't really have trouble with the procedural interstage, and it's what I use as stretchy decoupler anyway. As long as you put the fairings and the internal decoupler (which doesn't do anything; it's just there to not confuse MJ/KER) in the same stage as one big decoupler, it's fine. Regarding extending it: there's a few tricks you can do. First, play with J and Y until you get a combination that doesn't go inward like that; second, if you use the non-moving top node, or surface-attach to the top of the interstage base, you can use R (like with regular fairings) to change the shape. Finally, use egg rather than conical. With all that combined, I really don't have trouble with them as my only decoupler ever. I also made my own version with only two side nodes, to lower part count. I forget whether I included that in my PF textures zip.

sarbian, I apologize if I'm coming across as harsh. Not my intention. Examples of why this is bad: I would have to just blindly copy your new DLL to every root folder in GameData, just to be sure that there are no stray CFGs. Second, I could no longer, when I'm helping someone on the forums, tell them to stick their changes in a cfg somewhere; I'd have to find out where they have a modulemanager dll and tell them to put the file there. Those or two examples off the top of my head; I can come up with more. Further, we've all spent the last year or so telling everyone to use only 1 ModuleManager and keep it in root; we've almost won that battle of getting people to understand, and there are tons of posts to that effect. And now we'd have to tell everyone the opposite, and there will be two sets of instructions lying around on the forums. With my mod dev hat on (all the mods I maintain do or will use ModuleManager) I much prefer the current system. In fact I've already had to say on a few posts "make sure you're using MM 1.3."

Dragon01, I second asmi on posting configs, but just to check--multiply fuel volume by its density (0.0041, I assume) and ox by its ( 0.00571). If you don't get the correct mass ratio, something is off. Also make sure that the ratio of those two volumes really does match what you have in PROPELLANT{} nodes. Photonically: thanks! Definitely plan on dealing with reaction wheels; haven't yet looked at how to edit Kerbals...

rbray: thanks! Overlord: a few posts up I posted some higher-res clouds.

Yeah, you can put input control locks on instead of intercepting keys. The problem is you still need to intercept keys for signal delay.

I'm adding it to MFS. It'll be configurable.

Huh! Post your files and I'll take a look. In other news: Finally have stretchy-MFS integration better. The one issue is the ratio issue I've been talking about; when doubling size you end up off by about 1% from correct ratio. So you have to, when done rescaling, go into MFS and remove and re-add to get the correct ratio. But the textfields update, the tanks don't break on save/load, it all looks good. And it will even auto-round correctly when you mouse out of the tank.

You need to: Add a new RESOURCE {} definition For all the tank types you want it enabled for (each TANK_DEFINITION node) you need to add a TANK {} subnode. That subnode needs name = your_new_fuel_type and whatever other params you want to add. Then it should be available. Example In some CFG (assuming you have ModuleManager 1.3 installed): RESOURCE_DEFINITION { name = foo density = 0.005 flowMode = STACK_PRIORITY_SEARCH transfer = PUMP } @TANK_DEFINITION[Default] // add one of these for each tank type you want to add it to, like Cryo or RCS { TANK { name = foo utilization = 0.995 mass = 0.00005 temperature = -183 // do not include temp loss_rate = 0.0000000001 // or loss_rate if fuel is not cryogenic maxAmount = 0 //set to > 0 if you want the tank to default to having some of this, and use % amount = 0 // or set to a ratio between 0 and 1 [or full] if you want tank to start filled to that ratio note = (requires insulation) // include a note if you need a note. Cryos have this, Xenon has (pressurized), others have no note. } }

SFJackBauer: Nice! Click for preview:

So should I post my code as a pull or do you want to do it yourself? Or are you not interested in allowing user-changed scaling for the citylights detail textures? (It's kinda necessary for rescaled Kerbin, otherwise the roads are a kilometer wide...)

Regarding the person who asked about using this on rescaled Kerbin, I've been testing a fork that allows specifying Mission Control's position and antenna range via CFG. When it's solid, Cilph, I'll add it as a pull request.

Bump maps are just heightmaps. Normal maps, harder; don't know how to make them in a graphics package. But for bump maps, here's my suggestion. Render your clouds filter (I assume that's how you made the cloud detail texture?) at multiple resolutions--1024, 2048, 4096, and so forth. Then scale the larger ones down to 1024 each. (If GIMP supports variable cloud size for the cloud filter, just do it that way; Photoshop doesn't.) Then paste the larger ones as new layers into your 1024 image, and set the layers for the new ones to multiply. That will give you a few octaves of fractal noise.

Some new cloud textures, a bug report, and a suggestion. Clouds: https://www.dropbox.com/s/yigd9ia740mq4ur/CloudsTextures.zip It has two 2048x1024 (actually 1/2 the memory footprint of your textures, because of the upscale of non-power-of-two textures) cloud textures, and a new detail texture. (Although I don't see much affect from the detail texture in game...) The clouds are from NASA's Blue Marble set; the detail texture was some more work in PS based on yours (a few more octaves of clouds). Bug report: the way you currently handle texture offsets is just to constantly add to them on update. That means, once sufficient time has passed in any given scene, the UVs start getting precision errors. You need to do the equivalent of a modulus operator: check if offset > 1 and remove ((int)offset) from it, for each axis, after you add your speed to it. Suggestion: Configurable scale for the citylights detail texture, just as there is for detail textures for clouds. I even wrote the code for it to make sure it works; you're welcome to use it if you like.

Huh! Weird. Ok then. If you're consistently not getting the problem then DREC must be doing something to exacerbate it. Off the top of my head, only thing I could think of was that other partmodules weren't handling on part die events and failing non-gracefully when the part explodes.

Engineer, I guess I should include some of ialdabaoth's OP. Sorry. Modular Fuel System does the following: *It allows any supported tank to be filled with exactly how much or how little fuel you want, of whatever type you want (though different tanks may allow or disallow certain fuels; jet fuel tanks won't take oxidizer for instance) That's the classic modular fuels. Then, there's the Real Fuels mode. That opens up some new options. First, new resources get added, so engines can use real-world fuels, and KSP fuels are changed to be their real-world counterparts. Also, Isps are made realistic for the type of engine. Finally, engines can be of multiple tech levels; at higher tech levels they have higher thrust, lower mass, and better Isp. Second, engines can have multiple configurations (for example, an upper stage could support a kerosene + liquid oxygen mode, and a liquid hydrogen + liquid oxygen mode). These modes have different thrust, Isp, etc. asm: cool! Yeah, close enough. :]

Nice! Reminds me of what e of pi and Workable Goblin (née truth is life) did with the Vulkan Multibody (do you know about ETS?)--a kerolox CCB instead of Energia. Uses equivalent of 3x RD-180, IIRC.

That sounds like an extra config file changing something, sure enough.

asmi, 1. I released a v3 alpha, and now I have released v3 full. But some folks didn't want to unzip RealFuels.zip and change cfg settings, so I provided three "prebuilt" MFSCv3 downloads, regular, RealFuels (but non-realistic masses) and RealFuels + RealMasses. You presumably want v3RFRM. I think I may have titled the zip file for v3 alpha just v3, though, for which I apologize. Won't happen again (Well, I will make every effort. No impossibles.) 2. I do recalculate the whole tank. That's the new system. But what gets messy is that to recalculate the whole tank's _fuels_ I have to run off the existing maxAmounts of the resources in it, to keep the percentage of each scaled right. And since they start rounded (MFS rounds all amounts and maxamounts to 4 sig figures), that's where the error arises. I did find the problem where they're overwriting persistent volumes, though, and I'll add final rounding on mouse leaves tank (via another sendmessage to MFT) 3. You can add a "dummy" ModuleEngineConfigs. MODULE { name = ModuleEngineConfigs configuration = ANYTHING_CAN_GO_HERE modded = false CONFIG { name = AS_LONG_AS_THE_SAME_THING_GOES_HERE minThrust = YOUR_ENGINE_MIN_THRUST (= maxThrust if not throttleable) maxThrust = YOUR_ENGINE_MAX_THRUST heatProduction = YOUR_ENGINE_HEAT_PRODUCTION PROPELLANT // copy this from ModuleEngine { name = Aerozine ratio = 0.47 DrawGauge = True } PROPELLANT // and this { name = N2O4 ratio = 0.53 } atmosphereCurve // and this { key = 0 316 key = 1 160 } IspSL = 1.0 IspV = 1.0 } } The reason is because thrust scaling is done in the MEC partmodule. No partmodule, no thrust scaling. It's required because you need some way of knowing the engine's actual max thrust, and with configurations chanegeable in flight, the method Arcturus uses (load each engine module on flight start) won't work.