JoCRaM

Before people shout pendulum fallacy, this does work - but mostly because it moves the engines close to the probe core which "helps" the control software, and reduces compression flexing.

Or use CAPS-LOCK to switch to fine control.

page 10: http://www.reactionengines.co.uk/tech_docs/JBIS_v56_108-117.pdf The thrust on a SABRE is low at mach 1, so the ascent profile needs to take that into account.

Where possible don't throttle, in my head it adds weight and complexity. The only rocket I built in 1.0.2 has about 3x TWR on launch, to get it moving, then stages off the boosters to drop down to around 1-1.5. As it's ascent is entirely airodynamically contolled, it needs that kick to get prograde ahead of it before the aerodynamics start moving it to prograde....

I would like some engine tweakables - Throttle: "no" or "min% max%" weight increases for a throttle, more so if it allows control below ~10% or above ~70% Start: once, twice, up to 10, unlimited - increases in weight. Bell: atmospheric/vacuum/unoptimised: affects ISP Vector: none, 0.5, 1, 2, 5 and 10%, affects weight and ISP

Put a "mammoth" under a probe core - thrust vector is down. Put an ant on top of the the core, pointing down, and it overpowers the mammoth... However, remove the mammoth and replace it... and thrust is upwards again. Prettu much completely useless for balancing thrust - although with thrust varying with ISP and velocity balancing thrust is no longer as trivial as it was.

confirmed - with two intakes either side of a craft, closing just one no longer causes a torque

Easier said than done, it took around eight hours and quarter of a bottle of Tia Maria to get that far. The problem didn't recur from the quicksave. I'll try when I've got the time to go from launch.

does debris still need a probe core to be recoverable? In which case the transponder cost should have been a % increase on the cost of probe cores (and a weight increase please. Personally I think a responder transponder part would be better)

Steam KSP 1.0.2, running under 64 bit windows 8.1 This craft was behaving strangely, not rotating smoothly. When swapping to another craft it would sometimes refuse with something like "Can't switch vehicles while moving across the terrain" and then suddenly it stopped dead: no response to pitch/yaw/roll/throttle controls

my usage has also been small payloads. Has anyone checked the maths to make sure the weight is actually based on area not volume?

Does this still require a parachute or pod? Can it be configured to look for a "magic" part, and only save those? are there any "parachutes for ants" that can be used to `fool` the mod into triggering to watch aerodynamically stable probes land?

Sorry, I failed to use the correct term. A "backshell" needs to separate in atmosphere.

I had a play with your craft. I had to edit it to remove the engineer part, which is not stock. Your craft is aerodynamically unstable before the fairing is taken into account - but this was probably within the ability of the control surfaces to cope. however, because the fairing diameter is wider than the parts it covers, it generated more body lift (not shown in the VAB/SPH, but shows as light blue lines in the F12 aerodynamic overlay). Attaching a delta wing (the 0.5 tonne one) to the bottom of each of the four boosters is sufficient to move the centre of pressure back below the centre of mass, and get the ship to orbit. However it's too big for my computer to handle, so I made a 10% cheaper and much fewer parts one. I don't know what your required orbital deltaV budget is. I also forgot to release the fairing while the craft was suborbital. I'm pretty sure "normal" size control surfaces would have worked.

. Yup, that's a really bad fairing design. A bulge out (shoulder) gives extra lift. you can't really help having one of those at the top of the rocket. The kicker is a bulge in ("boat tail") gives negative lift. your design has a boattail below your centre of mass. So, as soon as you go slightly off the angle of attack the front is pushed further out, and the back is pulled further in. shorten your fairing so the bulge is in front of the centre of mass (allowing for tanks emptying) - ideally more than half way in front.

Don't forget the ground around the space centre is not generated terrain, but a model, so doesn't have seams.

I'm not fussed about it, but can't you simulate life support by only using fuel cells? (justify it as providing water) - when your fixed resource (fuel+oxidiser) runs out, your mission is over. Except your Kerbals go into hibernation and so can be rescued by a resupply mission.

On the test I did I gained - but I'd estimate the fairing you have has roughly twice to thrice the cross-sectional area as the rover - it being round, to match the maximum diagonal of the rover, but the rover itself. Of course, they've tweaked things several times over the last few days, so I don't know if my test is still valid.

The separation has to be capable of high force so they separate reasonably in thick atmosphere (think atmospheric entry). Hopefully - as they have with the decouplers - they'll let one adjust the separation force in later releases.

When building Shuttle like craft, I often move the root node around (to the shuttle/maintank decoupler usually). Have you moved it back to the cockpit?

KSP version: 1.0.2 Stream under MSWindows 8.1 64bit This could, in a certain light, be considered a user interface bug? I like the service modules, however, they can be difficult to fill. I've spent seven hours tweaking my Mun lander to fit it inside the larger one - whilst everything seems fine, part clipping causes phantom forces. As a work around opening and closing the module will allow the physics to resolve - but you cant open a module that's inside a fairing. Surface attaching things to the inside is difficult. Using the offset widget to move surface attached objects behaves most unexpectedly - I worked around this by attaching a cubic octagonal strut, then attached things to this, instead of the container directly. The top and bottom should also become transparent to aid positioning. zooming in really close and spinning the part to see how close you are to the wall gets old real quick. The interior of the model should match the collision mesh, (actually make it appear a little smaller inside than it really is to visually compensate for the approximate collision meshes of the other parts) Appease your 3D modellers by telling them the service module is to have a layer of flight case foam the Kerbal workers can carve as necessary.

It makes simple designs easier, but it makes it much harder to be creative. I recognise it is probably an overall improvement, however I have the following suggestions: As an interim fix make enable/disable/toggle fuel flow from a tank an action group item. Docking ports and launch clamps should (but don't currently) count as decouplers for the calculation. If you're going to allow "no fuel crossfeed" parts to cross feed fuel, make them count as a decoupler. - alternately add radial and stack parts that count as a decoupler for the calculation. Most importantly, In the old system you could compensate with fuel lines, in the current system you can't. Please add jet fuel line logic. Possibly add a new "jet fuel line" part. At a rough guess the logic should be: - any part fed by a fuel line is treated as a decoupler for the stage calculation, but is considered to be "after" the decoupler. - any part feeding a fuel line is considered to be in the stage the fuel line is connected to iff that stage is "before" the current stage here the root node is "after" everything else, and in most cases the engines are before everything else

with regards the wing colliding with launch pad bug, try clearing the launch pad (start to launch something, such as a cubic strut, then recover it.) before re-entry.

I'm glad it's easy. Forgive me if I seem dense, but I've not fiddled about with vector maths for 14 months, I'd just like to get my existing scripts working in KSP 0.90. what do I replace my lock with in this fragment SET yaw TO 90. SET pitch TO 90. SET roll TO -90. LOCK STEERING TO HEADING(pitch,yaw,roll) given yaw pitch and roll will be fiddled with by other bits of the code, e.g. WHEN ALT:RADAR > 40 +MASS then { SET mark TO TIME:SECONDS. LOCK roll TO (TIME:SECONDS - mark)*7-90. IF MASS < 50 { LOCK roll TO -90-((ALT:RADAR-50)*.7). }. RUN att("reorientation start",missT). WHEN ABS(roll)<1 then { RUN att("reorientation end",missT). LOCK roll TO 45 - (pitch/2). }. }. WHEN VERTICALSPEED>100 THEN { LOCK pitch TO 90 - [...]. PRINT "fakity turn started". } Unless I'm missing something "LOCK STEERING TO HEADING(0,0)*R(yaw,0-pitch,roll)." is going to be simpler?

Any chance of a HEADING3, or ROLLHEADING, or something similar in the interim? I'd do it myself but, while this is trivial change, working out how to use Windows as a build environment (or, in fact, anything other than a games launcher) is beyond me.