NathanKell

Cool! If you want to follow reality, they'd be for tank pressurant, and thus not contribute to fuel or oxidizer.

MM 2.3.x does its processing slightly later. The RSS class that loads launch sites is instantiated very early; just after MM < 2.3.x, and just *before* MM 2.3.x. I believe I have fixed it RSS-side and will have a release this evening.

Interestingly, the Isp thing allows a further way to "balance" high efficiency engines: you *will need* lifter-class engines to lift off if your upper stages don't produce much thrust. (This especially holds true for the LV-N; it would be a lot less "OP!!11one" if it produced 1/4 the thrust, rather than consuming 4x the fuel, at sea level).

This sounds really great! You might want to hold off a couple weeks or so putting major effort in, though, given all the new persistent-kerbal-stats stuff .25 will be adding.

This is the correct place to ask the question. The "reply" you had in the other location was me closing the thread at the OP's request.

The pictures aren't showing.

This looks super helpful!

Heck, it wouldn't be that hard to write an external *editor*, and it'd probably be easier to use than having to load KSP to edit the tree.

Ah, right. Forgot that bit. Yes, if you postfix _NRM to a filename, Unity will recognize it as a normal map and convert it if it's not in the internal format already.

The config for Planet Factory--I'm not sure that's been updated recently. I would not suggest using it right now. I have edited the OP to mention that it appears to be for 6.2, quite a few versions ago.

No, it's how Unity stores normal maps internally. All textures (that Unity is told will be used for a normal map) are converted to that format on load. However, if Unity doesn't know it's supposed to be used as a normal map (i.e. if it not a normal-map-flagged MBM, and you're using ATM, and ATM isn't told to treat it as a normal map) it will not be converted, and there will be a line in the log that it failed to load.

dreadicon: sure! 1. With a 6 ton payload and a 4.3 ton NTR, you're looking at a dry mass of over ten tons *before* you start adding fuel. To even get a mass ratio of 2 (i.e. as much fuel as dry mass) you're going to need something like 11 tons of hydrogen. And, given how not-dense hydrogen is, you'll need something like 155,000 liters of it. That's 155 cubic meters, which is probably more like a 16-17 meter 3.75m diameter tank. You have to look at the *mass* of fuel you're carrying, not the volume. Of course, the other thing to remember is that 3.75 x 16 is actually...not that big a payload for a real life payload fairing. It would easily fit in a Delta IV or Atlas V 5m PLF. You'd need the Heavies to get it into LEO, though, with it being 20+ tons all up. YMMV if you're on stock Kerbin and your payload is larger than your launcher. 2. While spheres are slightly stronger (relatively) than capsule tanks, they're also more expensive and not as useful. So a purely spherical tank should mass something like 70% of a capsule tank, but it will also lead to poorer volume utilization (and thus a higher structure:tank mass ratio) than a capsule tank, so that evens out some. However, comparing apples to apples (a 1m radius sphere vs a 2m radius sphere) the mass scales linearly with volume. Since RF treats a part not as a tank but as a stage filled with user-definable tanks, I have not thought it worthwhile to try to exactly model the dry masses of the tanks involved; heck, even those "you can actually see the tank" parts get *simulated* by RF as a modular volume into which can be placed any number of "sub-tanks." For that reason I default to a volume-utilization of about 86% (somewhere between the Titan II first stage and the S-IC), although that is customizable if you want to replicate some other (set of) tank shapes. 3. Ah, probably the best approach would be to add a button to the toolbar in the VAB/SPH that will, when clicked, auto-upgrade all engines to their highest-allowed TL. Because even if the parts in the editor part list default to highest available TL, when you load a craft all engines will have the TL that they had when you saved the craft.

Cpt Kipard: Let's try this again: Unity expects normal maps in a certain format. If you do not give Unity a normal map in that format, and you do not tell it to convert to that format, it will not appear correctly ingame. The format Unity expects normal maps in is: The Green channel has the Y value, and needs to be inverted. (Note that this is usually also copied to the R and B channels) The Alpha channel has the X value. You can see the result in the pic Beale posted of a SQUAD normal map; it's gray because the R, B, and G channels are identical, since they all express Y-inverted, and X is in alpha. The format you are passing has X in the Red channel, Y in the Green channel, and Z in the Blue channel, with no Alpha channel. If you export your textures from Unity (i.e. to MBM) this conversion is handled automatically. If you don't do that and you are not using ATM, it is usually handled automatically in texture loading. If you don't do that, and you are using Active Texture Management but do not have the texture specified as a normal map (i.e. the NORMAL_LIST node) in an ATM config, then it will not be converted automatically on load by KSP, and it will fail to work. Since Unity has this weird format, obviously you should only do this conversion *after* you have finished getting everything looking right in Blender, since obviously Blender is not going to know what to do with weird Unity-style normal maps.

Thrust-to-WEIGHT ratio is not the same as thrust period. No one is saying TWR remains constant. If you don't believe me, just right-click on an engine and watch during ascent. As your TWR increases, what happens to the "thrust" line in the right-click menu?

As I mentioned here the latest Module Manager broke it. I will release a change to RSS to work around it.

As a way to deal with spam (which we do get a lot of--if you don't see it, that just means we're quick at dealing with it ) a user's first five posts are moderated. After that, free and clear.

Nope. *All* assets in GameData are loaded before a single cfg is processed.

This was removed from the game itself. Not sure why you think FAR is to blame...

Check the stock support forum's known issues stickies. They're very helpful. MaxP: It's so that if Frizzank changes what kind of engine module (from ModuleEngines to ModuleEnginesFX) we don't have to change our cfg. It will patch either. It would only match one instance of a MODULE anyway; do read the docs on how MM works, it should prove very helpful.

That's pretty weird. Thanks for the catch. The I'll check it out. (The other one works perfectly, except not in the Editor, so dV doesn't update properly except in flight)

Love the new docking port! And the IVA stuff too. Uh, can the heat shield be removable? It works much better, generally, when the heat shield is a separate part; then it can have its own mass, its own specific heat or shielding ability (DRE), and when you don't need it you don't have to add it.

At what speed and altitude and *current* TWR did you do that? How much control authority did you have at the time?

My cunning plan is revealed! (Turns out, even beyond my own interests, I'm also shilling for this ) You might want to look at some simpler, less trussy pressure-fed engines then. Maybe the AJ10 from Vanguard/Able or Thor-Delta. Or do you want pump-fed? Those usually are more complex-looking (because they're more complex period).

If you need inspiration for detailing the engine, you might look at the Astris upper stage engine (highres here). It looks about the right size for you, and no one's made a lookalike (unlike the fifty million SPSs and J-2s).

The latest MM broke it. I'm fixing RSS.