NathanKell

HoneyFox, you can post something that awesome in any thread of mine any time Captain_Party: I assume you mean HoneyFox's engine thrust controller plugin (the OP should make clear what Stretchy does!). If so, ETC allows you to create a floatcurve that determines the solid rocket's thrust as a function of time. I.e. it could start at full thrust and decrease over time. (The pictures are "looking down" the solid motor casing.) From Bob Braeunig's site, here's how different propellant shaping affects thrust (over time): Link to discussion of solids: http://www.braeunig.us/space/propuls.htm#solid

Regarding point 1: that's *really* weird. What other mods are you using? Regarding point 2: sounds like you're using an old version of KJR. Check the log and see why (does it say "collided with launchpad"?)

Starwaster: there's no here here... Himidori Shuumoto: you're correct, it should be 86080. I'll fix that. Regarding LF/Ox, I'm not changing their densities: they're still 1g/cc. RF changes the size of a KSP unit though, from ~5L to 1L.

Graphotron 2000

helldiver, good to hear from you and don't worry about the nattering nabobs of negativism :] Can't help you with much of that, but if you still want to use RealFuels I can bang out a config for you. Also, re: engines, sounds like dtobi would be the person to talk to there.

CluelessModeler: Uh, 10k max per part. Modern GPUs can easily push *millions* of tris. A couple hundred k onscreen won't hurt anybody as long as the collision meshes are simple. Re: textures. Yes, exporting to mbm should be fine; just make sure (a) you disable compression for normal maps and ( have NRM in the filename for (and only for) normal maps. Also, as I said above, a 2048 diffuse or two is fine (as long as no alpha channel!) for the CBC, but keep your normal maps much lower if you can (and as Razorcane says above, you don't *need* large textures for small parts). Also, even if you do make a CBC with a builtin engine, make sure the engine is referencing the same texture as the engine-only part; otherwise you'll have duplicate textures. Check out how FASA does things for example: it has multiple models in the same folder, so they can share the same few texture pages. Finally re: boattailless engine, just for clarity this is what I meant (apologies if I were already clear) No boattail, and no stupid KSP "engine mount" that's actually the bottom of a tank...

Uh, what do you mean? Prograde is your velocity vector; the way you keep it at a given angle is by pitching and thrusting to change your velocity vector. Do you mean something like, "stay at a given angle *from* prograde"? I.e. "I want my spaceplane to maintain an angle of attack [i.e. pitched above velocity vector] of 20 degrees"? If so, then alas no, but that would be a good function for MJ.

That's not a module. The word you're looking for is node, which is the name for anything with {} after it. (In fact, MODULE nodes are also just nodes; it just so happens that the game reads that node and creates a PartModule from it). Anyway, point being: in MM you access nodes by @nodeName or, if there's more than one and they have name values in them, @nodeName[nameValue] So you'd do: @PART[someAntenna] { @MODULE[ModuleRTAntenna] { @TRANSMITTER { @foo = bar } } }

That's...not true. The mention in the log is about *using* the texture for the part, not *loading* it (if you were right, mods like Visual Enhancements wouldn't work at all). *All* images in GameData will be loaded, with the exception of anything in a PluginData folder (also true for mus, cfgs, etc.)

Fixed. I forgot to revert it when I un-changed Xenon's density.

Oh, ok. Then I'm mystified. Download Novapunch and only add the K-2X part (in Engines). See if the gimbal is reversed for you too. Just in case, also use it as an upper stage engine, such that the center of mass starts below the engine and only moves above it during first stage burn. If not, I must be breaking something somewhere... For a screenshot: The K-2X is hidden inside the interstage fairing (the inward-cuving procedural fairing 2/3rds of the way up)

Add a partmodule to (at least something on) the vessel, and override OnSave

Requires changes to ModuleManager. They're tagged by id, not name. Oh Squad, ever consistent.

First: Loving the DIV! That would be much appreciated. Also if you would make it without the boattail, just the engine itself. Let us boattail it ourselves. Um...have you missed all the threads with people complaining about crashing, and the need for memory reduction mods? :] Or the giant thread in the Modeling forum called "Devs Please Read: About Textures" or some such. Anyway, the long and short is: KSP is (a) CPU-limited due to physics and ( memory-limited as a 32bit process. It's not GPU-limited unless you have four-year-old integrated graphics and even then it's probably CPU-limited. That means that high-detail geometry (as long as it has a low-detail collision mesh) is totally fine. However, high-resolution textures are bad news; if you have the choice between making detail with geometry or making it with a normal map, choose the geometry and use a smaller normal map. A 2048 diffuse and a 512 normal for the CBC should be totally fine, but if you're talking about about many, many 2048s then that's a different story. Regarding formats: the format on disk has *nothing* do with the format in memory. That's like saying because I sent you a model in 3ds it'll have different geometry than if I exported it as .blend. Nope, just as all geometry must be read in and converted to actual vertices and tris, all textures have to be read in, converted to bitmap, and then compressed. Where it gets complicated is: 1. Textures with 4 channels (i.e. with an alpha channel) take up twice (not just 4/3) as much memory as textures with 3. 2. The png and tga loaders have some issues, both of which rbray89 has corrected; but mbm is still the safest format. That said, remember to name your normal maps whatever_NRM.ext (include the NRM) so that they get dealt with properly (i.e. not compressed to DXT, which is bad for normal maps).

There *is* no base for *any* engine in real life. What KSP players/modders think of as the "base" is actually the bottom of the fuel tank. See my rant in the FAQ in the OP. At *most* there's a thrust frame. See http://en.wikipedia.org/wiki/RD-107 for an example.

Measured diameter of the *nozzle*? Agathorn etc: Yup, a number of those mods are don't-distribute. And--congrats! And looking forward to your engine work.

Most excellent!

Heh, just realized I replied to this thread rather than Shuttle Engines. Oops. Sorry. Anyway, confirmed: it's that you can't rely on the the gimbal transform's own axes, because they might be flipped (as they are, e.g., on the K-2X). You have to use the *vessel's* left/right/forward/back axes (and invert when on opposite sides of CoM, as you realize) when determining how to rotate the gimbal.

Nonono, it's not that. It's that *in the mu* some of the transforms are probably rotated. Or at least that's my guess. All the Squad models behave as you'd expect, but some mods may not have their gimbal transforms oriented as you expect.

Pol: there are two approaches for using realistic-ish stuff with the stock KSP universe. 1. Use KIDS to scale down Isp. That means you'll need just as big a rocket as in real life, for the smaller KSP universe. 2. Have useRealisticMass (in RealFuels/RealSettings.cfg) set to false (defaults to true) which will mean that you have approximately the same dry mass for tanks, and TWR for engines, as you would in stock KSP. Hydrogen has a very, very low density. You need to compare how much deltaV you're getting for the same mass of fuel, not the same volume of fuel. And yes, it does have considerable boiloff, even in cryogenic tanks. Liquid Methane is probably a better bet--lower Isp, but higher thrust and lower boiloff and higher density, all of which mean that it doesn't have markedly worse performance than pure LH2. You obviously will get different deltaV, because everything has been modified to conform to reality. If you just want a harder and more complex stock-like experience I heartily recommend FlowerChild's Better Than Starting Manned mod. If you do want to use realistic fuels, etc., then see the two options above.

dtobi: I'll see what I can do. But just looking at the code, I'm wondering if it's because some engines' gimbal axes are rotated (like +x is actually -x, and +z is -z, i.e. gimbal tranform is rotated 180d around y); that would make sense since I also had that issue when I had my verniers flipped 180 degrees.

cardajowol: Soviet Engines is already RF compatible (other than using LF instead of Kerosene), so I don't touch them. They're 100% size, 100% mass, 100% performance. Starwaster: Heh. :] I thought LMAE was TRW? But nope. Guess only LMDE was. Regarding restarts, I presume that's to rendesvous with CSM without burning any CSM departure fuel. Probably couldn't guarantee a pure two-burn transfer, let alone a launch to rendesvous. Well, the LMAE article on wikipedia mentions that NTO/AZ50 was so corrosive that they didn't even static-fire the LMAE before use, so I'm guessing yes to your question. Yeah... :\

Known issue in KSP 0.23 for a part that has >= 3 resources but no module. Add a dummy module yourself or use ModuleFixer.

Does it have rcs in the pod itself? Try with capslock on.

Ferram: I'll have to look at e-dog's code. I really hope he's not grabbing node position OnLoad. fatcargo: yes, that dll was only for acc. It's outdated, but I knew it removed fuels properly. Haven't heard of the weird orientation stuff. A screenshot would be helpful...