MaHuJa

The minimal dV ascent has a drag effect equal to gravity effect (9.8 m/s2 on kerbin) as much of the time as is viable. This means that as vessels vary in drag, they must vary in speed at altitude.

The problem is that "fairly good" isn't perfect. In the end it's the same problem as when you have two objects near each other but not attached to each other, they will have slightly different orbits. For each orbit, the relative positions will change just a little, say 100m. Two orbits that's up at 200m. Three orbits, 300m. 100 orbits... And that 100m initial difference per orbit is not just "fairly good". (It may be more instructive to measure this in phase angles than meters.) In real life they continuously adjust the orbits of active satellites to keep them on track, though I believe that's also for other reasons.

For that purpose, I've been using the landing pads from hooligan labs. One problem I had with using a small rover for this purpose was that it got blown away when the ship landed. I think that's much of the idea behind the line attachOnStatic = False // Disable/enable attaching a part to a static object like ground or building.

Staggering the launches is one way of doing it - if you have one sat per launch vehicle. You launch the first one, figure out (measure) the launch phase angle (how far an object in the target circular orbit moves ahead of you if it was straight over you at the time you start the ascent. Then you launch the next one when the phase angle is 90+-LPA. This assumes the ascent happens identically, meaning you don't have any mishaps, you start the gravity turn at the same time AND altitude, etc. The other way to do it, is to launch them all from the same ship. 1) Get into the orbit you want the satellites to hold 2) Release the first satellite 3) Burn prograde so you have a 1.25 times longer orbit time than the satellite. 4) When you have done the complete orbit, you're at the correct place for the next satellite. If your sats have engines of their own, you can release it, let it burn itself into the correct orbit, and repeat that every time. If not, you'll need to slow the ship, release a sat, and burn up to your extended orbit again. Using this method you can get them in perfect position with one ship, and this will also work well for placing satellites around other bodies than the one you launch your ships from. I have a setup of 3 RemoteTech Microprobes around kerbin that I deployed in a perfect triangle using that method, though I naturally had to use 1.33 rather than 1.25. To maintain line of sight, they had to be some 600km up. You can be lower if you use more satellites, I just wanted to unclutter my ship lists. If you have space, you can lower your orbit instead, 1/1.25 = 0.8 times the orbit time. If you want to save dV, you can do half the difference (1.125x or 0.9x) and wait two full orbits instead of one. Or three or four. Laughed off the forums? Hardly. This is rocket science

I'm assuming he means increasing warp (time acceleration) and decreasing it again.

Presumably, the problem is one of the antenna going below the horizon - as the RT code is calculating it, anyway. A satellite in orbit may by able to relay between them still, and maybe it'll help if you build an extendable antenna arm on the command truck using damned robotics or similar, raising the antenna height. I made such an arm using the hinges, that folded up 8 times its "stowed" height, and put it on a polar landed beacon. Unfortunately it had landed in a valley. The internal battery doesn't have any stored power left, so it draws power from other batteries around the ship. It should still be working. In the case that you don't have much else on the ship with battery capacity, it will add 5 to that capacity. The smallest RT control unit is the small antenna you can mount radially. Use a vanilla probe core and that antenna, and it'll work like a regular command unit. Though you may want another antenna as well because it only has a 250km range. If you edit the part.cfg of the small dish, you can extend the range. If you want "realism" or "balance" or <buzzword> you may also want to up its energy requirement to make up for the loss of antenna efficiency. A factor of 100 sounds reasonable for "realism", though it's probably still conservative.

Try search thread (upper right corner), I'm pretty sure it's been discussed recently. Don't switch away from KSP while it's loading, even if it's a long wait. That's known to cause problems.

By example... A vehicle for clearing debris - a kerbal gets out, picks your SD device off the hull (putting it on his back), flies over to the debris, attaches it to the debris. He can then, in EVA, activate the thing, perhaps with a timer so he doesn't get THAT good a view of the explosion. (He can also use KAS to tow stuff out of orbit, give it just a bit of fuel if that's all it needs, etc.) Specifically, look at the radial connector port that you can take off the ship and put elsewhere, KAS_CPort3 title = Radial connector port (dismountable) I've put those on other non-kas parts with luck in the first version of KAS. Haven't really tried it in the later versions. Going to try with a static solar panel soon.

If you have the kerbal attachment system installed then that's a simple matter of editing the part.cfg - which is what I intended to do for myself in my post above. In fact, it could perhaps be included in the default part.cfg, if it does no harm when KAS is not present.

No XIs. And it's just a matter of engines' fuel supply instantly going from e.g. 9.97 to 0. I have no idea what triggers it, but whatever it is, it hit one engine (a couple km off the mun surface), and only later hit the other two (with kerbin orbit, not yet decaying). Could be a mod conflict, I do have a lot of them. I haven't given up on it, so I'll try more. If it happens again I'll try to figure out the conditions.

If you have the deadly reentry mod, you can use a tricoupler + 3x 1.25m heat shields + 3x FF engines for a fairly compact engine setup. On the other hand, I've had problems with these engines suddenly, for no particular reason, losing all their fuel. In this 3-engine setup, one lost all its fuel very suddenly. I hadn't even hit the 10% mark for fuel usage. Then the other two did the same, together.

Marder, read back a couple pages. It's a workaround for an even more annoying bug.

Maybe it'll work if you use the connector without the grapple. Unless it smacks down so hard it explodes. Oh and... I was just thinking of something like the landing pad for my mun base. I currently have a demv5 as my "landing target" marker, but I'm not too comfortable with it.

For one, the source folder is used for compliance. To post plugins here and on the spaceport, you need to also include the sources. It's also useful for those who want to learn how it works behind the scenes, and someone could potentially look at the sources and find how to fix a bug. Potentially continue the project where kospy left off if he disappears, but that depends a bit on license and stuff.

Well of course not, since it's already in. The remotetech flight computer has an attitude window and a thrust window. The thrust window lets you select engine power, duration of burn (in seconds or m/s) and a delay before burn start. And once you set it, it will perform that burn even if it has since lost contact.

Going to try this. If one can trigger it from eva, I can make it possible to move it by KAS attachment, and I have a way to get rid of all that debris around my mun base. (I usually have to discard a stage there. Those are not from crashes. Mostly.)

I have a couple feature requests. First, do any range checking and adjustments on loss of focus rather than on update. If I know what number I want, I CAN'T JUST KEY IT IN because it will change it after the first digit. Add the rest at the cursor position and it tends to hit maximum too, just to salt the wound. Second, 1.25m, 2.5m, 3.75m buttons to quickly set the part to the most common sizes would be appreciated - especially when I - or a new user who hasn't done this yet - don't even remember that they aren't 1m, 2m, 3m though we usually describe them as such.

Is there a way to enable the EVA features (detonate, decouple, weld) without having to include yet another part? I've already moved most such "functionality" onto all the command pods; the exceptions are isa mapsat gps and lazor. The common feature of these two, that keeps me from doing that, is the part.cfg line module = LazorSystem whereas almost everything else uses module { name = X } and so can be added to an existing part. Using the latter where the original part uses the former doesn't work. Doing the former on a command pod will probably just blow up on me.

Here's my niftiest creation so far. The screenshots were taken during a prototype stage, I've done a few test/change iterations since the screenshots were taken, but the basic idea remains the same. It's a good old fashioned crane. The real invention is using grapples to lock it to the ground, rather than ballast or stabilizers. Using Damned Robotics the arm can rotate 360, turn about 60 degrees down from vertical (120 if I add another hinge) and extend to a good bit extra length. It's very flexible too (though it looks glitched under load), so the arm is not limited by weight pretty much at all. Especially not at mun where I intend to use it. Grappled the ground with the crane to see what would break first - the core flipped even under its restraints, crashing the boom into the ground. It being uneven, it hit the boom in the middle. The one thing this crane won't be able to do is pick up a heavy object and move it a long distance, but that's the job of a heavier vehicle. The latest iteration is approximately 7.2t, and I will try cutting down a bit more. Big images though. Bugs 1) Have a winch with connector and grappling hook (built or attached, doesn't matter) 2) Extend or attach grappling hook 3) Quicksave, quickload 4) Hook is no longer connected. Presumably it has something to do with the hooks not being docked - or even dockable. To preserve it across a reload requires releasing whatever is held and pulling it all the way in to lock it. Also, another save/load cycle took it out of the world for me. (And I'm supposed to be on infinite debris.) Haven't tried reproducing it a second time, though. 1) Eject 2) Retract 3) Eject 4) Try to retract - it won't react. There's an easy workaround in pressing the extend button before retracting it again. Presumably the underlying code thinks it's still locked in the winch. Not sure if this also happens with release instead of eject.

My solution to aiming the grapple (that I haven't actually tried yet): Clampotron jr sitting next to the winch, using the lazor docking camera. Gets you a nice crosshair (but with a bit of offset). Maybe KAS can offer something like this built in in the future. Without the cam it'll still work like what winn75 suggested when you use 'control from here'. Anyway... 1) EVA 2) Pick up connector 3) Put in detachable receiver (also called connector) 4) Pick up detachable receiver 5) Change the receiver's mode (probably changing it to docking?) I suspect you want to disallow #5 when it's connected to an EVA kerbal. When I saw the option I just had to try.

I wanted this. So much. Any chance getting a list of actions on a specific keybind? Knowing what's bound to the group already can keep me from breaking things horribly when older keybinds also do something.