DerekL1963

Thanks! Up to ten characters worth!

Yes, I know.... what was it changed to?

That's precisely *why* he has an attitude with you.

Does anyone know the altitude for the new KSO? (I.E. with the changed length of the day.)

It can also make bad things (or at least unpleasant things) happen too. Follow the mod maintainers instructions.

It is possible to have *too* much control authority, but without seeing the rocket in question it's hard to accurately evaluate if the problem is MechJeb or in your booster design. But really, so long as your rocket isn't tumbling end over end it's not actually all that big a problem. Roll is caused by vehicle design, usually a lack of struts allowing parts of the vehicle to twist out of alignment. Kerbal Joint Reinforcement helps here, as does a picture of the vehicle so we can evaluate the design.

OK, a very strange and annoying problem... When I go to set an interplanetary transfer, MJ produces a trajectory that passes kinda close to the target but does not actually encounter the target. I've actually flown a couple, and used "fine closest encounter" to create a mid-course correction node and almost always it requires massive delta-V to actually produce an encounter. MJ and KSP are both patched to the latest versions. The vehicle(s) in question have more than sufficient delta-V to execute the transfer.

I'm curious as to the logic behind putting the multi-spectral scanner in the construction branch.

Yes, which is why it's called a Carbon Extractor. I used the wrong term, maxima mea culpa, the proper question should be be "why no water splitter"?

Why no O2 generator?

Targeted at the pad (using the button in the LGAP), I consistently landed just to the east of where the pad structure sloped down to the base (the part which eventually slopes down to the ground itself). Prior to .024 and the current dev build I hit the center of the launch grid 99% of the time.

Using .24 and the latest dev build (266), I kept landing to the East of the launch pad.... it took a bit to figure out why, I bet the LGAP hasn't been updated for Kerbin's new (slower) rotation.

If you don't want to use this mod, please stop clogging up the thread for those of us who do. It's not your business what we do or don't do or how we go about it - and it's certainly not for you to dictate to us how to behave.

You don't even want your craft traveling at 8-9 km/sec at say, two or three times the height of Everest.

Thanks for getting this up-to-date, as I rely heavily on this tool!

Has anyone tested this with .24?

Looking forward to it... this is one of my 'must have' mods.

Huh? Setting an orbit to a particular time is just as easy regardless of whether it's 3 hrs, 6 hrs, or 6 hr 53.17 seconds. You read the appropriate display, compare your current orbit to your desired one, and burn as needed.

Is the other craft stable? (I.E. has some form of attitude control engaged?)

Same here... all of KAC's graphics are "fuzzy", no ATM, using the current version (2.7.6.0). Problem occurred when 2.7.6.0 was installed.

*Some* satellites most certainly do use "attitude or tidal lock". *Other* satellites simply spin at the same rate as they travel around the Earth. (Mostly because using gravity gradient stabilization requires a specific configuration that may or may not be feasible and compatible with the satellites mission.) Yet other satellites do neither. *Some* satellites are designed to carry enough fuel to maintain station keeping for their their life time. Others have no need of station keeping and carry no fuel at all. *Some* use their RCS (if they have it) to boost into a graveyard orbit. Others use their RCS (if they have it) to simply de-orbit themselves. Yet others are simply abandoned in place and if they're low enough then atmospheric drag eventually brings them down (though some are high enough that this make take tens, hundreds, or thousands of years). Seriously, trying to lump all birds into one basket is a fool's errand. There are a handful of large families, but that's about the best you can do.

OK, I deserved that. Seriously, if there's a config switch to force it to select the same transfer node time, I'd appreciate knowing what it is.

Is there any way to get MJ to reliably produce the same [censored] node time for interplanetary transfers? It's almost impossible to plan ahead when it randomly chooses departures anywhere from 200 days away to 1 year 180 days and almost every figure in between.

Easy peasy. Possible solution 1: Orient your bird normal (+ or -) to your orbit (rather than prograde or retrograde), then fire the decoupler. You'll get a slight change to inclination, but virtually no change to period. Possible solution 2: Or design your bird such that it retains the stage/systems that were used to perfect the orbit and don't decouple at all.

The problem is, drag varies not only with orientation - but with speed and altitude as well. In the real world the effects of drag also vary with the ballistic coefficient (essentially a combination of the surface area as seen by the airflow and the vehicles weight), I don't know whether FAR calculates that or not. Either way, it's a Very Hard Problem. Even without dealing with the odd rounding error, the bits simulated and not simulated in game (even with plug ins), the bits that are either simply assumed or simply ignored...