NathanKell

Yup, the KW engines are in my prior post, but the link again: https://www.dropbox.com/s/k1hywmzcrpc50tt/KW_modularEngines.cfg (Replace your old RealFuels/KW_modularEngines.cfg file with this) Tanx for the tanks!

I just realized, with the Transtage, and Tohou Torpedo's Mk3 Expansion (for the Cargo Bay and the Mk3 Fuse->2.5m adapter), you could make a really close clone of the Dyna-Soar! And with KerbPaint you could probably even paint it black. (It'd be 3 person instead of 1, but ah well.)

You're welcome! That part works on legacy (.20) SAS/ASAS and not (AFAIK) .21. But since the .21 SAS works quite well I wouldn't bother with it. So delete the CFGs.

Ah, I see the issue with the liquid booster. It has an engine and a fueltank, and stock MFS only supports 1, not both, being modular. However, I have fixed that problem in my dev copy. When I've tightened up a few more loose ends, I'll repost it, and the modified NP2 config. KW engines: https://www.dropbox.com/s/k1hywmzcrpc50tt/KW_modularEngines.cfg Replace your original from ChestBurster's pack. As to the directions: Take an example config. Let's say the NP aerospike. @PART[NP_lfe_125m_AerospikeEngine] { @maxTemp = 1800 @MODULE[ModuleEngines] { @heatProduction = 150 @PROPELLANT[LiquidFuel] { @ratio = 0.4 } @PROPELLANT[Oxidizer] { @ratio = 0.6 } } MODULE { name = ModuleEngineConfigs configuration = LiquidFuel+Oxidizer modded = false CONFIG { name = LiquidFuel+Oxidizer thrustVectorTransformName = thrustTransform exhaustDamage = True ignitionThreshold = 0.1 minThrust = 0 maxThrust = 285 heatProduction = 150 fxOffset = 0, 0, 0.4 PROPELLANT { name = LiquidFuel ratio = 0.4 DrawGauge = True } PROPELLANT { name = Oxidizer ratio = 0.6 } atmosphereCurve { key = 0 380 key = 1 375 } } CONFIG { name = LiquidFuel+LiquidOxygen thrustVectorTransformName = thrustTransform exhaustDamage = True ignitionThreshold = 0.1 minThrust = 0 maxThrust = 295 heatProduction = 170 fxOffset = 0, 0, 0.4 PROPELLANT { name = LiquidFuel ratio = 0.35 DrawGauge = True } PROPELLANT { name = LiquidOxygen ratio = 0.65 } atmosphereCurve { key = 0 390 key = 1 385 } } CONFIG { name = LiquidH2+LiquidOxygen thrustVectorTransformName = thrustTransform exhaustDamage = True ignitionThreshold = 0.1 minThrust = 0 maxThrust = 270 heatProduction = 140 fxOffset = 0, 0, 0.4 PROPELLANT { name = LiquidH2 ratio = 0.73 DrawGauge = True } PROPELLANT { name = LiquidOxygen ratio = 0.27 } atmosphereCurve { key = 0 430 key = 1 425 } } } } Copy it, paste it into a new file. Call this whatever you like, but make sure it has the cfg extension. We'll call that window the MEC window. Now, in another window, open the part.cfg of the part you want to modify. You'll need info from that. We'll call that the part window. What you're creating (through modifyng an existing one) is a ModuleManager config. It has a particular syntax. Lines that start with @ mean splice. It means find this key, like @maxthrust (or the node of this name, if something in brackets follows, like @PART[temp]), and change it (if key, change it's value; if node, operate inside it). If there's a !, it means delete. For nodes (things with {} after them) you also need {} if you're deleting. If there's no symbol, it means insert. In the MEC window, change the thing inside the brackets in the top line to the name of the part you want to be modifying (find the line name = SOMETHING in the part window). That will tell MM to find and modify the part you want to be modified. Then look at the "@maxTemp =" and the "@heatProduction =" lines. Find, in the part window, the original values, cut them in half, and stick them in the MEC window, replacing the originals. Now look down. You'll see three CONFIG blocks. Do the same for the LF/Ox section, replacing all values there with the values from the ModuleEngine block in the part window. Now we'll look at the other two CONFIGs. You'll see that generally LF/LOX has higher Isp and thrust and heat than the LF/Ox block, and LH2/Lox has way higher Isp, worse thrust, and lower heat. First replace all the values in those blocks with the values from the part window, then tweak to taste. Save the file in the MEC window, make sure it has a CFG extension and place it in ModularFuelTanks/RealFuels, and you're done.

I don't have Kerbolar, but I can add the radial boosters. Although it's a very simple process you can easily do yourself. Just look at an existing modular engine config and copy the block, then replace the part ID at the top, the thrust and heat and Isp values as appropriate, and the name of the thrust transform and/or fxoffset if they're non-standard. That should about do it.

You can look in Firespitter or StretchyTanks for how you can do texture changes on the fly. Dunno about reloading DLLs though.

Atlas is apparently the Skipper? It was removed from KSPX when they added the Skipper, apparently. Is it any different? Starwaster, and lots of texture changes. Apparently much better and slimmer.

Look upthread. Someone posted a DLL that does that.

Cool. I'll handle the engines...

The big thing I'm aware of is that parts periodically overheat or overG in PreLaunch...

It can, but you might need to use tangents.

Yeah probably...heh. Interesting you found load() is non-destructive, btw. Just have to make sure ModuleEngineConfigs always runs after ModuleEngine loading so the right (i.e. part-default, not default-default) values are set.

A question on the dock-o-chute: the numbers are all working right for me (the drogue drag goes away when the mains deploy) but the drogues don't disappear until I manually right-click->cut chute. Is this what others are experiencing?

Changed GUI code so a part with both modular engines and modular fuel tanks will display both GUIs. Testing an ability to override TANK{} blocks from a part's module. This is very handy if you want to preconfigure certain tanks to have certain ratios without having to create custom TANK_DEFINITIONs. (no update file yet)

Thirded! I've been using Yogui's but it's too close a clone to the LM for what I'd really like.

MOARdV, that's spot on, with one little exception: given that a chunk of the memory usage spikes is from leaks, it's not clear that the original format will have _no_ bearing on the final memory usage; as I mention above, there's a chance that if their code leaks, having to uncompress an image before converting to DDS may (since that memory leaks) cause more usage. It'll take some SCIENCE! to test this all out.

Is it true of uncompressed TGAs as well as compressed TGAs? It might be that the memory page used to put the uncompressed version into is never freed. (pipeline: read file into memory space A. If file is compressed, allocate space B and uncompress into space B. Then pass pointer to A (or pointer to B if step 2 was necessary) to DDS compressor.)

Same link. There's on onRecover*, yes, it's what I use in Mission Controller. So you could trawl through parts, find the partsnapshop for the tank, get the resource confignode, and add the Kethane to a stockpile. *something like that. Check my MCE recycle function (and the hook it sets) for how.

This is looking gorgeous! I'm relieved you're having the docking port as a separate model, because I plan to use this as a post-Apollo craft myself, with a real androgynous berthing mechanism...

I fully support LH2/LOX main stage, and hypergolics for OMS and RCS. Conveniently I added NTO/MMH to MFS.

Updated with a fix for how amount/maxAmount/fillable works (or rather doesn't work). Now if you set amount=0, or fillable=false, that's respected. (amount is a ratio, 0.0-1.0, full=1.0, of maxAmount specified)

DarthVader: NO. The whole last few pages established that, and the author just said that while thinking they might have stolen the textures is your right, they started making the rocket before the other one was released.

Alpha channel is usually used for transparency, but really it's just another channel. Bitmaps can usually have at most four channels (though there's no reason you couldn't have an arbitrary number of channels), and the channels are usually 8bits each (though there are 16bit/channel formats). Alpha in games is usually used for transparency, but really it's just used so you can pack more into a single texture. So you can read color + transparency from a texture, or color + height, or color + specular, or color + emissive/self-illumination... Specular maps tell a shader, basically, how "shiny" to make the object. Emissive maps controls whether the object is self-illuminated, i.e. is bright without light hitting it. (In the best of worlds, it would control the object actually emitting light, but usually it just means "count the object as self-illuminated"). A brief detour re: lighting models and shaders. How these all combine is: Get the color of the pixel from the color map. Get the normal at the pixel by averaging the vertex normals and then modifying by the normal map (if there is one). Calculate the light hitting the pixel by calculating diffuse factor and specular factor (dot product of light incidence and normal, basically, with a power for the specular factor). Multiply diffuse by light, multiply specular color (or diffuse color or white, if no specular color) by specular factor and by that pixel (0=0.0, 255=1.0) in the specular map (if there is one). Add them up, in each (R/G/B) channel, that's your pixel's color. Get alpha from alpha map. Instead of just writing the pixel, if alpha < 1, blend it with what's under it, by the alpha factor.

PF code doesn't scale nodes as it stands; upthread I asked e-dog to include that because it's a quick one-line code change (I know 'cuz I added that to StretchyTanks). Don't know whether he saw the request, but either way he said he was a mite busy at the moment...

On the contrary, +50 points for not just copying a stock model. Modeling takes a while to get the hang of.