ferram4

Well, without a crash log we can't tell what's happening, but I'll bet that you're running out of memory. The thing is, B9 is kind of a memory hog, and I'll be Interstellar eats quite a bit as well. If that's the case, your only solution is to install one of the texture reduction packs.

Yo Nathan, got some more info for you on the Modular Tanks freaking out on reverting to launch / loading. It's not dependent on stretchies being involved anywhere, nor do fuel lines seem to affect it. The tests I tried: Central stretchy with 4 radially attached stretchies, no fuel lines; fine on initial launch, after revert symmetry counterparts have no resource mass, making vehicle unbalanced; nulls thrown at ModularFuelTank.get_tank_mass(), originating at OnStart(). Same test, but radial stretchies replaced with stock fuel tanks; same results as 1. Same vehicle as 2, but radial tanks empty; nulls are still thrown, but vehicle isn't unbalanced on revert. Somewhat related, I was also able to cause the same teleporting tank weirdness (like with my earlier Delta II) when switching to a vehicle with radially-attached fuel tanks while it is in orbit from another vessel / from the Tracking Station. I don't know what's happening in the code, but I would guess that something that the MFT code needs is being set in the VAB / SPH. When going straight to the flight scene without hitting the editor scene that isn't set properly, causing the bug. But I'm speculating. Output_log.txt in full.

It's difficult to do with very low TWR upper stages. My solution was to put a relay sat in a 550km orbit and time the launch; use that satellite to relay the signal over the horizon to KSC. An alternative is to have a very high TWR for your upper stage. That would allow you to get the burn done before losing contact.

It will, but docking connections will still be a weak point in the design. So to answer the next question, yes you will still have issues if you try to have a Clampotron Jr. handle the thrust of a Mainsail. However you shouldn't if you use a Clampotron Sr.

@jrandom: Wolfram Alpha is your friend. Trust me, the number of ugly integrals that can't be solved easily that will pop up in aerodynamics is amazing; you'll just have to bite the bullet and do a lot of it numerically. @DaMichel: FAR only leaves the parachutes to do their stock aerodynamic properties. Everything else is cleared out. The attach nodes are supposed to be set up so that the last number controls the size of the node, which is used by FAR to figure out very, very sudden changes in cross-sectional area. It's what's used to determine most of the drag and the lift of a reentering command pod. There were a few stock parts that didn't have the last number set or had it set to the wrong value, causing weird things to happen.

@DaMichel: I don't know, the GUI doesn't seem to be clear with it set up that way. I think there is a bug somewhere in the CoL code, but I haven't been able to track it down. I'll see what I can do. @jrandom: If camlost is talking about the book I think he's talking about, that's one of the ones I have lying around. It's got the limitations of an introductory book (not very in-depth) but is otherwise quite good. @Bouncingbunny: From earlier in the thread: You could just load it in-game and see the horror for yourself.

Really? Using what craft?

Alright, version 1.6 is out, fixing the I-beams-made-of-toothpicks and FASA Agena disassembly-phasing bug. I'm leaving pFairings as they are with this, since it works out to be a lot of work to try and fix that, and I kind of like the result anyway.

@roxedboxer: Your problem, had you the patience to solve it, was too much control surfaces. Alright everyone, version 0.12.4 is out, including increases in body lift, fixing the intermittent supersonic roll-twitch introduced in v0.12, a serious increase in the mechanical lag of control surfaces, which will probably make SAS behave worse, but everyone's complaining about the unrealistically fast control surfaces causing twitching so we'll see if this fixes it / causes a nice placebo effect, tweakables got tweaked, and some other odd bugfixes. Also, there's a new stock craft, the FAR Ugly Duckling, which you should try flying. Landing it is the hard part.

@Draft: I can try and look into that, but it looks more like an issue of playing fast and loose with adding PartModules when they aren't needed in procedural fairings. @Deltac: Confirmed; it's due to the fact that the part of the nosecone with the docking port also contains a decoupler to separate it. I'm going to see if I can have KJR only kill the joints that it adds specifically and see if that works.

@NathanKell: Yeah, that sounds right for the S-IVB. I dunno. If you want a better idea, you can look at Alliant Techsystem's Motor Catalog (PDF Warning). The STAR series includes some ullage and separation motors (STAR 5C, STAR 5CB, STAR F) that you can look at.

I wish I could, but I think that would be a pain to try and model. I'll add it to my list of things to try when I go and recode everything though.

@NathanKell: I did manage to cause another a weird bug with the problem craft I sent you, which I think is caused by stretchy tanks. The "Delta K" like stage has 6 stretchy tanks clipped into the procedural fairing bases at the top of the stage, with fuel lines coming out of them to ensure fuel crossfeeding. Launch the rocket; revert to launch; launch again. Partway through the flight (I think at ~the unloading distance from the pad) all of the symmetry counterparts of the aforementioned stretchy tanks will teleport to some distance below the rocket; the original will remain there. Fuel lines stretch to infinity in either direction when you do that, which is kind of weird. As for the ullage motors, they're about the same as other SRM nozzle throats, but considering that the nozzle is generally hidden inside the aerodynamic fairing, most people don't notice it. See example. Generally it shouldn't be a problem since ullage motors are generally wider than they are long.

@NathanKell: Little more info on the problem craft: Upper stage vac-SRM behaves properly if the lower stage vac-SRBs are removed; once the lower stage vac-SRBs are added it picks up their characteristics. Although I didn't test, I'm tempted to see what happens if you stage the upper stage SRM before the lower stage SRBs to see if the lower stage SRBs pick up the upper stage SRM characteristics. What I meant re: nozzles was that there's a logical reason to constrain the size of the nozzle for upper stage motors, say for fitting the nozzle into an interstage; I probably wasn't clear enough. As for controlling the nozzle size, why not just set the nozzle throat area to be proportional to thrust? Then, limit the nozzle size so that the throat can't be bigger than the ~50% of the rocket's width. Then nozzle size makes sense and you add a nice constraint to burn time that keeps solids as rocket motors and not mortars. I would like to be able to cant the nozzles, but that's another thing entirely. Too many boosters have torqued themselves into the main tank due to excessive forces for my liking.

@Picard: You can go into the config.xml file in FerramAerospaceResearch/Plugins/PluginData and increase the control surface time constant parameter to a higher number if you want slower acting control surfaces. I've found that higher values (with more control delay) tend to cause SAS to freak out more than lower delays. Regardless, whenever the next version comes out it control surfaces will be set to deflect about as slow as the stock ones.

@Hodo: I guess I can look into that. It'll be a bit of a pain to set up though. @BC000001: Yep, that's correct. Sudden drop-offs in the object's diameter generally create quite a bit of drag, and a smoother tapering can lead to a less draggy configuration. @Shad0wCatcher: I meant percent change, so that would mean that the fairing adapter has a taper ratio of 0.75 but the fuel adapter has a taper ratio of 0.6666..., and the lower that number gets the greater the drag on the part. @roxedboxer: It works fine. This is actually answered in the first post of the Procedural Fairings thread.

The bottom of the fairing tapers less than the tank below; it's the relative change in diameter that matters, not the absolute change diameter, and the fairing adapter has a smaller relative change in diameter than the fuel adapter, so that would result in lower drag on the fairing adapter. I'll admit that I don't quite understand the point of this design; wouldn't it make more sense to use a wider tank under the fairing and then use the fuel adapter at the bottom of it? I can look into it to see if anything truly messed up is going on, but I doubt that anything really is going wrong.

@Chris_W: I'll look into it, but the right-clicking on the part does state that it's making 0kN of lift and drag, correct? @Hodo: Good to hear. @Shad0wCatcher: That's correct. Changes in part diameter add lots of drag to the shape; you should try putting a standard fuel tank on its side at the same dynamic pressure and see how much drag it makes. The reason that the straight fuel tank makes so much less drag is that there is only skin friction drag acting on it, which is a drag coefficient of ~0.005. A tapered tank will also have pressure drag acting on it, which can go up to a drag coefficient of ~1.86 for a purely flat face. Use a part with a less-sudden tapering.

Okay, this Delta II 7295 is the problem craft. In the editor, the upper stage SRB says that it is set to make 67 kN, but in the flight scene it makes 450 kN. Requires AEIS, KW, PFairings, StretchySRB, MFS and using SFJackBauer's Real Engines, with a minor change to the real_engines_rescale.cfg to make the AJ10-118K look better on the Delta K; just look for the KW1mengineVestaVR1 entry and replace it with this: @PART[KW1mengineVestaVR1] { %title = AJ10-118K %manufacturer = Aerojet description = Upper stage, pressure-fed engine of the Delta II vehicle, burns hypergolic propellants and is optimized for vacuum operation. %attachRules = 1,1,1,0,0 !MODEL {} !MODEL {} MODEL { model = KWRocketry/Parts/Engines/1mVestaVR1/KW_1mEngine_VestaVR1_M scale = 0.5, 0.5, 0.5 } %rescaleFactor = 2 %attachRules = 1,1,1,0,0 %node_stack_top = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 2 } That just controls looks, so you shouldn't have to do that to cause the bug, but just in-case. If you're testing in an install with RemoteTech you'll need to add an antenna to it because I didn't add one yet (haven't installed RemoteTech yet). Just get it up to a point where you can ditch everything below the 3rd stage and fire it. Stupid amounts of thrust from that tiny thing even though it shouldn't be able to produce it. Oh, an unrelated Stretchy SRB request: Could you try detecting whether there is a part attached to the stretchy SRB's nozzle and change the nozzle size based on that? I understand not making them larger than the SRB body if you're dealing with upper stage SRMs, but for the vacuum-optimized SRBs attached radially it would be cool to have the nozzles have equal throat areas, not equal exit areas. Should be easier to do now that you're not hiding an RT-10 in each one.

It would be great, but there are quite a few serious issues that need to be answered about how mods will have to work with this kind of system: How much leeway will modders get in specifying installation instructions for the program? Will we be heavily limited in what we can do because the mod installer will only do so much? What happens when the installer screws up? It will eventually, and who is responsible for fixing that? Odds are the user will expect the mod author to fix it, and we won't be able to do it, since we can't deal with that code. But then given that SQUAD currently doesn't provide support for modded installs, unless that changes that means that no support will be provided by those responsible for the issue. And no matter what happens, the user is ticked because the modder can't help and SQUAD appears to screw them over. Given the above, will SQUAD provide support for issues caused by the mod installer screwing up? And what will be the criteria necessary to prove that it was the installer that screwed up and that it is not the mod itself? Since the mod installer will remove any need for the user to go into the GameData or KSP_Data folders, will the installer also remove mods as well? Will it be able to submit bug reports to the modders, since if asking a user to copy over a folder is too much, surely asking them to go through folders to find a specific file to upload for us to troubleshoot is too much? Will the mod installer be able to handle a list of conflicts between various mods? This essentially makes modding appear far more difficult than it actually is, since an installer implies a more complicated set up than simply copying folders; will this discourage people who might be capable of modding, but won't get into it because it appears too difficult? On the other hand, will this encourage people who probably shouldn't be using mods (little kids, the hopelessly computer illiterate) to install them, with the attendant increase in entitled and confused requests for support that modders will have to deal with? The moderately computer literate already given sub-standard bug reports, and I don't like what my imagination can come up with for what the computer illiterate will be like. The thing I'm concerned about is that something like this will help most users only a little bit while adding more hassle for modders.

My tests have indicated that it doesn't seem to work with plugins and also seems to break ModuleManager. I haven't tried in a while, but I see no reason that should have changed.

Just to chime in, it seems like the MFS and StretchySRB pre-releases are fine, except for the solids-of-the-same-type-all-making-the-same-thrust issue. I tried making a Delta 7925 and the PAM solid stage ended up picking up the characteristics of the 3 air-lit vacuum-optimized SRBs. So instead of making 67 kN (as it said in the editor) it made ~450 kN and crushed the probe. So that bug's still a thing, but otherwise everything looks fine.

Does it do that in flight, or are those errors from using the CoL in the editor? I'm looking at the code and I'm not sure how a NaN error could occur... Right-clicking on the winglets confirms that they're not producing any lift or drag, correct?

@Hodo: That sounds like some other mod is causing the bug; I know you have a list of mods in your sig, but would you mind listing them out, including version numbers and what version of KSP they're guaranteed to be compatible with? Perhaps it's a known issue with one of them or exacerbated by something. @t3hk0d3: Struts. This is a stock bug, nothing I can do about it.

Well, then don't use it with MFS. I'm not going to bother bugfixing until the official, non-experimental version of MFS comes out so I have something stable to work with.