Wisq

Might be a way to tweak the settings so they only operate when ElectricCharge isn't full, but an alternative might be to use the kOS mod and set up a simple program that turns them on only when ElectricCharge is below a certain value. Untested, I haven't delved into kOS yet.

Anyone know why this science bay isn't protecting the communotron inside it from FAR aerodynamic dissassembly? It's the first and only component to fail. Log shows it disconnecting from the science bay and hitting the fuel tanks below. I assumed that US wedges would protect in a similar way that fairings do?

Okay, interesting. I don't seem to have any problem with going at high speed without the control surfaces. Since FAR has such high terminal velocity and low drag, I generally aim for a high-thrust ascent in order to get to orbit ASAP and minimise losses to gravity. Things I need to try: Reducing control deflection (less control at low speed but more stability at high speed); maybe enabling FAR DCA flight assist (but that might not affect SAS/MechJeb control). Yes, this is the part I love. In my previous game, I recall I would often launch straight up until about 300 m/s (to have enough velocity to hold my vector), then pitch them to about 80º, 70º, sometimes even 60º (depending on their flight characteristics), and then just let go of all controls. They would slowly, slowly tip closer to the horizon (as their prograde vector changes and pulls their nose onto the new heading) and I got true gravity turns (as far as I know). But I guess the difference is, I was using a much higher TWR, so I needed a much lower starting pitch in order to properly gravity turn. Edit: Ah, no, I checked my notes. Turns out I would go straight up only to clear the tower (if any), then pitch over to ~70º using SmartASS, maintain that until 350 m/s, then set SmartASS to "SVEL+" or just turn it off and the nose would follow my velocity vector. My actual vector would drop below 70º because I was too slow for the atmosphere to hold me on a steady path over my (top-heavy) rocket wanting to pitch over, but that's fine, since I was really aiming for a 60º or lower pitch anyway. - - - Updated - - - Okay, I think I answered my own question: Enabling FAR DCA assist will kill the oscillations because it dampens control input at high velocity, which is where the oscillations occur. So, I'll consider this answered.

Hi all, So I've been playing with the Ferram Aerospace mod for quite a while, and I've generally got no problem with making rockets that are stable, i.e. they don't flip around and deconstruct in the air. (Admittedly, I haven't designed many planes, but I've done a couple so far.) Sometimes, though, I end up with a rocket that's just too darn stable  too much drag at the back, I guess  and it's incredibly difficult or impossible to achieve a decent ascent profile. It just keeps going straight, even if I start trying to push it down to the desired pitch (e.g. 70º) right from the launchpad (since SAS is nerfed and all I have is thrust vectoring). I've tried adding control surfaces like the AV-R8 pivoting winglet, but almost universally, what I end up with is not control, but a rocket that's oscallating wildly instead whenever I try to use SAS or MechJeb SmartASS. I've tried various arrangements  near the CoM (laterally and/or longitudinally), or far from it; I've tried horizontal with only pitch enabled plus vertical with only yaw enabled; etc. Almost inevitably, I end up giving up and going back to just thrust vectoring and/or just settling for a sub-optimal ascent. So I'm wondering, is there a general rule of thumb for how to place these (or what settings to use, or how to use them in flight) in a way that won't cause a rocket to freak out?

I guess this is kinda abandoned at this point? Unfortunate, because it seems like a great idea. Would love to see a full release someday.

Yup, same here. Definitely a problem with the latest version.

Ah, okay, that makes sense. Don't want them using up the pod supplies before inflating it. Seems a bit high, considering the mk1 command pod only has 3 days, but I guess it makes sense if you consider that most of the pod is taken up with equipment rather than supplies.

Is it really meant to have 15 days life support? Because I'm running 0.2.2 (from CKAN) and the life support values are all 0.1. That means 2h28m water, 1h32m food, and only 58 seconds of oxygen.

If anyone's interested, I just started blogging a Kerbal science campaign, starting with 31 iterations of sounding rockets (with diagrams), most of them being variations on my quad design: http://wisq.net/2014/12/31/kadet-1/

The key is a) radial decouplers that you never decouple and rockets that you never actually light off (acting as structure) but that still have a tiny amount of fuel (so they don't automatically jettison). Basically, I started with one nosecone and (structural) SRM-S at the core, added radials (70% with TweakScale, but 100% should work okay), added four more (structural) SRM-Ses, then added four nosecones, four (actually fuelled) SRM-Ses, and four SRM-XLs (with adapters). The result is a quad-rocket that can make it to about 100km apo if fired straight up (with FAR + KIDS "FAR to stock" profile), or about 63km if fired at the angle in that picture. The stages are, big SRMs, adapters, little SRMs, parachutes, and then stage 0 (above the parachutes, never fired) is the decouplers and final five SRMs. Parachute velocity is low enough to protect the payloads, but high enough that it does still break up when it hits the ground. Typically it breaks up into five pieces, so I recover the core, then recover the four packages with the Tracking Station view. On one occasion, it broke into only three pieces (core+2 attached, 2 separate). The nosecone in the middle is key, since it needs all five parachutes to (barely) safely land. Also probably helps aerodynamics.

Yeah, if you try just a nosecone with no package, I think it's almost impossible to parachute. Really, the package should be providing the mass and the nosecone should be providing the drag, not the other way around. Also, I miiiiight be abusing this a bit. Four launches in one!

Yeah, I noticed this didn't work either. It does seem weird to me that it has 0.0 drag. I mean, the thing is physically similar in dimensions to a Mk1 command pod, just a bit thinner and waaaaay lighter, which suggests it has a low density and should actually have high drag.

Okay, cool, will do. I just got everything from CKAN  Sounding Rockets 0.1.1, Universal Storage 1.0.0. The sounding rockets part configs all look okay (they define an experiment, the experiment is defined in the ScienceDefs.cfg) but I'll go ahead and reinstall stuff by hand I guess. Edit: Seems to be a conflict with CrowdSourcedScience. Trying my old config now, minus that mod. Edit: Yup, all good here. I never really needed that mod anyway, just sounded interesting.

Hm, nope, still can't do anything even with Actions Everywhere uninstalled. All that happens is I lose the only right-clickable option I had, which was to toggle crossfeed.

Is it normal that I can't right-click any of the survey packages to do experiments, nor do the experiments via action groups? It's not RemoteTech, since a) I added the RT config mentioned earlier in the thread, and I even tried removing RemoteTech entirely. I'm wondering if it's one of the other action-related mods I have installed, like Actions Everywhere or TweakableEverything or something. I'm gonna try removing those when I get back, but gotta go for now. Just wondering if I'm using this completely wrong or something.

FYI, the CKAN version of this plugin doesn't install correctly  it puts it into GameData/KeepFit rather than GameData/Timmers/KeepFit, and so it pops up the "you've installed this incorrectly" popup at the main menu.

FYI, the DERP Propulsion Module is throwing errors when I hover over it in the VAB: [EXC 18:31:08.301] ArgumentOutOfRangeException: Argument is out of range. Parameter name: index System.Collections.Generic.List`1[AvailablePart+ModuleInfo].get_Item (Int32 index) PartListTooltips.GetPrimaryInfo (.AvailablePart aP, Int32 maxLines) PartListTooltips.ShowTooltip (.EditorPartIcon part, .AvailablePart aPart) EditorPartIcon.MouseEnter () EditorPartIcon.MouseInput (.POINTER_INFO& ptr) UIButton.OnInput (.POINTER_INFO& ptr) AutoSpriteControlBase.OnInput (POINTER_INFO ptr) UIManager.DispatchHelper (.POINTER_INFO& curPtr, Int32 camIndex) UIManager.DispatchInput () UIManager.Update () This causes the tooltip image to display incorrectly  it grows / zooms in very quickly until it's bigger than the screen and disappears. KSP 0.90, USI Survival Pack 0.2.0 via CKAN 1.5.0.

I'm unable to use the new 1.5.0 ckan.exe. Running it just pops up a dialog saying "This application could not be started. Do you want to view information about this issue?" Clicking yes takes me to a Microsoft knowledgebase article: http://support.microsoft.com/kb/2715633 Edit: Hmm, weird, something must've gone wrong in my download. Downloading it again worked.

As far as I know, it's always worked this way. You only get cone effects if you target a planet / moon. Targeting another ship or targeting Mission Control always ignore the cone.

Realiy looking forward to using this in 0.90. Thanks for the late night efforts!

Awesome, thanks! Re: profiles, I haven't had a chance to investigate further, but the last time I used ScienceAlert (prior to reporting the EPL incompatibility issue), I had issues with profile saving/loading not seeming to work. Generally, each time I quit & restart KSP, I had to adjust everything to my liking by hand. But with the incompatibility fixed, I'll see if I'm still having the issue and try to give an actually-useful report if it's not.

Any chance of seeing a new release in time for the holidays that addresses the EPL/Hangar incompatibility bug? I would really love to do a holiday break playthrough using both EPL and ScienceAlert at the same time.

Okay, either I'm completely misunderstanding the RCS Balancer, or it's severely bugged for me. I've tried using it with lots of crafts. Typically, they're small to medium drones with 4x RCS ports (at 0/90/180/270, i.e. cardinal directions, 4x symmetry, not off-axis) around a monopropellant tank, roughly around the center of mass (design permitting), and with ample SAS to correct an off-center burn. This should be an absolute piece of cake  I can RCS normally, without the balancer, and I get good control, and the torque is nothing SAS can't handle. When I enable the RCS Balancer, the result is almost always the same: I can't RCS in at least two directions, often more. I poke all the different RCS directions, find that half of them do absolutely nothing, and so I give up and turn off the RCS Balancer and do it normally. In my most recent example, I put 4x Vernor Engines at the center of mass of the ship, then 4x more at the top and 4x more at the bottom, again in the four cardinal directions. Without the RCS balancer: If I press up, all three down engines fire; if I press left, all three right engines fire; etc. With the RCS balancer on, left and right each fire only the top engine (leaving SAS to counter the visible torque), while up and down do absolutely nothing. Honestly, the only reason I really want the RCS Balancer is to disable RCS for rotation. But I pretty much can't ever operate with the Balancer enabled, so I'm stuck just disabling RCS whenever I rotate and enabling it whenever I translate, which is annoying as hell. Am I just using this feature wrong, or is there maybe some incompatibility with another mod? The only one I can think of would be RemoteTech, which does mess with controls for ships somewhat; but, the only thing I've ever seen it mess with re: MechJeb is preventing MechJeb from doing anything if the connection breaks (and I'm operating in very well-connected space, with low latency).

Any idea where EPL stores the position info for the windows? Specifically the EL Build Resources Display window in the VAB? It's working on my Windows KSP but not on my Mac. I'm trying to figure out if it's a bug preventing it showing up, or if it's just appearing off-screen or something. (I copied my mod directory from one to the other, but the Mac has a smaller screen.)

Not the original reporter, but FYI, I found I ended up disabling SCANsat integration because it was failing to recognise some rarer biomes on the Mun, even though I recall that I definitely had the whole thing 100% biome-scanned. Unfortunately I don't have more details; I'll try reenabling it and report any issues, once the ExtraplanetaryLaunchpads compatibility is fixed.