AHHans

I'm a bit unsure what you actually want to do. Do you want to do a bi-elliptical transfer to save dV? Or do you want to do a transfer outside a transfer window to not to have to wait for a window? If so, then why are you talking about bi-elliptical transfers? Saving dV with a bi-elliptical transfer - compared to a Hohmann transfer - is only possible if you change your orbit (around the sun in this case) by a large fraction anyhow, so it isn't applicable to a transfer to Duna. In my games I often do interplanetary transfers outside of a transfer window. AFAIK doing a standard transfer from Kerbin to Duna or the other way at a transfer window is the fastest and cheapest transfer. But when I don't want to wait for a window I can spend somewhat more dV and somewhat more time underway, to arrive at the destination earlier than waiting for the window would have meant. Depending on the actual situation sometimes the cost in dV becomes prohibitive, or the trajectory for "leaving right now" becomes so long that it is better to wait for a window (actually: be closer to a window), but often it works well enough. I set up these transfers by: first setting up a maneuver node as for a Hohmann transfer. Then checking where my target is when I reach it's orbit: if it is in front of me, then I need to reach the intercept point earlier - compared to the target - to get an intercept, so I need to get closer to the sun to be "faster" than my target. So I change my ejection angle (i.e. time when I do the burn) to get closer to the sun, which means I need more dV on the burn to get to the target's orbit. If the target is behind me, then I need to be "slower", so I need to get farther away from the sun. (I.e. spend some time hanging around in solar orbit outside the orbits of my start and destination.) Then I fiddle around with the ejection angle and the dV until I get an intercept. If a plane change is needed I include a midway plane-change burn into the fiddling process. Finally I think about whether this transfer is worth the effort, i.e. compare the arrival time at the destination - compared to waiting for a transfer window - to the cost in dV, keeping in mind the increased cost of the capture burn. Here a quick example for a transfer of my gateway station in 500km Kerbin orbit to Duna. As you can see from the KAC window the next transfer window is in 175 days, together with the 300 days for the transfer itself this means I'd be at Duna in about 475 days. Some quick and dirty fiddling later I have an encounter in 345 days, at a large-ish cost in dV (2400 m/s vs. 870 m/s). I could probably fine-tune this somewhat to shave off some more time and dV, but it's not going to be a fundamental change. In my current situation, with my interplanetary shuttle with 5 km/s dV and refueling stations both at Kerbin and Duna I might go for it, but at the start of my career - when every m/s cost me money and effort - this might be different.

You don't actually have to have same vessel interaction enabled to have two docking ports (junjors only?) on the same vessel dock to each other. I just did a test craft, and can confirm that (with juniors only!). Two docking ports on the same vessel can be docked by moving them together on hinge (or another robotic part), but cannot be undocked via an action group. Have them on two different vessels, and then the undocking via action group works. You should check first if there is already an issue about this, but otherwise: yes.

Ah, yes, that thing. If you label a vessel as debris or asteroid, then you won't be able to control it if you switch to it again and no crew is on board. Even if you park it next to the KSC with full batteries, you still cannot control it. (IMHO one of the more annoying features of KSP.) I'm sure that is intentional, and not a bug.

That one. When setting up a maneuver node I can see if I have enough fuel to go where I want to go. If it is unclear, then I can set up the full chain of maneuver nodes and sum up the needed dV to see if I have enough fuel. If I'm not sure that I'll get there, then I remove the nodes and think what I'm doing instead. And if all else fails, then I send a rescue mission. (Last time that happened was when I saw that 15 km/s were not enough to rescue someone from low sun orbit...)

Hi @Vsimm, welcome to the forums. [Please keep the shouting to a minimum, that's bad for my hangover. ] If you already have a full tank in LKO, then going to Minmus, refuel there, and go from there straight to the target is usually not a good idea. Due to the Oberth effect you gain more energy (= speed after leaving Kerbin's SOI) when doing a single burn in LKO than first going to Minmus and then doing a second burn there. You gain quite a bit back from refueling on Minmus, but if that is more or less than you lost due to not using the Oberth effect depends on where you are going. Without doing the math my guess is that for going to Duna (and probably Eve) you would save a bit by refueling on Minmus. But on the other hand setting up an efficient transfer burn from Minmus' orbit to Duna is a lot more complicated than doing so from LKO. (I mean: a lot!) -- Hmmmm... So if you want to do that as a training exercise, then go ahead! -- Doing this for a transfer to Moho, Dres, Jool, and Eeloo will probably cost more than you gain. (I think...) What would be the most efficient is to refuel at Minmus, burn in low Minmus orbit onto an elliptical orbit that gets close to Kerbin again, and then do your main Duna transfer burn at the PE of that elliptical orbit. But that requires that you set up this intermediate elliptical orbit in such a way, that you can burn prograde at PE and get onto the transfer orbit to Duna. Setting this up correctly requires exact timing, precise burns, and having a good transfer window from Minmus via Kerbin to Duna. Getting that right is even more complicated than setting up a good transfer burn straight from Minmus to Duna. For myself, I decided that I don't want to bother with these triple transfer orbits, and set up a refueling station in a circular gateway orbit around Kerbin, that is refueled with a miner from Minmus and where interplanetary craft can dock to refuel and then go their merry ways. P.S. I found the discussion about transfer orbits that I remember, here:

I recommend against setting autostruts on robotic parts that are still expected to move! (In your case at least the rotor, but possibly also the hinge itself.) Sometimes this works, and sometimes this causes the part to freeze up.

Probe cores consume electricity, not fast but continuous. But if a craft is not in physics range then it doesn't consume any electricity. (It also doesn't generate electricity, but that doesn't seem to be your problem.) So if you have a probe with that doesn't generate electricity for whatever reason - because it doesn't have solar cells, the solar cells are not deployed / in shadow of parts of the craft or a planet, or whatever - and you switch back to the KSC or another (far away) craft and time-warp there, then it will still have some battery capacity left. But if you do that time-warping while focused on the probe, then it will run out of ECs quite fast.

Have you tried locking the hinges and setting autostruts to whatever is attached to the hinges? As far as I can tell locked robotic parts behave essentially like non-robotic parts.

Because they are not fairings, but engine shrouds. They are part of the engine and not of the object that the engine is attached to. Think of them more as the structure needed to attach something to the bottom node of the engine, with the ability to occasionally work as an interstage fairing a happy coincidence.

Yeah, I also usually get that. I guess that some files like "PartDatabase.cfg" etc. that are generated from other files by KSP are also in the Steam distribution, so that a Steam verify sees some modified files even if that's O.K.

Hmmm... My VTOL that I designed in with 1.7.3 works fine... A new test stand with a pair of F-12 servos placed in mirror symmetry also behaves as expected: when I set the target angle of one, then both of them move.

In one of the change-logs of the more recent patches (i.e one of the 1.7.x or 1.8.x patches) they mentioned something about secondary docking ports becoming primary docking ports when the primary is undocked. So I think that the first pair of docking ports to make contact will become the primary thus defining the root and grandparent relationships, and the other docking ports become secondary and are probably more implemented like (auto-)struts. (But I can also be wrong.)

Well, that is the latest version. And, yes, I guess this is a bug. Or do you have the full science for this already unlocked (with another station on the same moon/planet)? But just switching it on again may not help: in my career save the deployed mystery goo on Kerbin is at 100% science and 95% transmitted (which is still back from the original bug I mentioned). I just tried sending a Kerbal out and "only" switching it on again, but that didn't help: the next time I checked up on the deployed science station it was switched off again. So you might need to reset the station: pick up the mystery goo experiment and then place it again.

Don't worry. We've all been there.

In the main menu of the game, in the lower right corner it says which version you are running. But, yes, with steam you should have the latest version. Well, that's also a thing in real life. I spent quite a bit of my time a) driving out into the field to push a button and b) explaining to someone on the phone which button exactly to push so that I can access the experiment again remotely.

A general note: if you are on a trajectory that will encounter another SOI then the game doesn't consider you being in orbit, but as "being on an escape trajectory" i.e. doing a flyby. From the screenshot it looks like you don't encounter another SOI (in the time-range than the games looks at). So you should have the "orbit around the sun" ticked off. My guess is that the game didn't re-evaluate your status since you got the "flyby" box ticked. My suggestion is to go back to the KSP, check what it says in the tracking station, and go back to the craft. If that doesn't help and it says "on an escape trajectory" in the tracking station, then you should change your orbit a bit, make sure that you don't encounter any other SOI anytime soon, and try again.

No it's a meme.(*) The solution (well, for a certain definition of "solution") to many KSP design challenges is to add more struts, to hold everything together. So "more struts" became kind of a running gag, and because "more struts" still isn't enough it became "moar struts". In a similar fashion "moar boosters" are the solution to get your craft into orbit. (*) Well, at least according to what I think what a "meme" is. I'm old enough that a) this word didn't exist for the first few decades of my life and b) I'm a bit fuzzy about what that word is supposed to mean.

Which version of KSP and BG are you running? That was a common bug in the first release of BG, but it was (mostly?) fixed in one of the KSP 1.7.x updates. You can go there with a Kerbal and switch it back on again.

Hi and welcome to the forums. With only a static image there isn't all that much to base a diagnose on, but the craft looks like it is ready to rip itself apart during launch - no kraken needed! I think you need Moar Struts! And not the auto- version of the struts. At the very least I would add a strut from the bottom of each of the six boosters to a sturdy part at the bottom of the central core, to keep the boosters from tilting. But I'd probably add a dozen or so more struts, just to be safe. Autostruts to root or heaviest are known to be kraken-bait. Autostruts to grantparent are usually safe, autostruts to root are mostly dangerous during docking or staging when the part that is root changes but having many autostruts to the same part that then try to transmit a huge amount of force through these struts is also problematic(*), autostruts to heaviest are particularly dangerous during launch when draining fuel changes which part is the heaviest. So for your craft I would avoid "autostruts to heaviest" like the kraken-bait they are. I also wouldn't use autostruts to root, even though they may be O.K. What I would do is - as already said: Moar Struts! P.S. (*) See the - somewhat role-played - postmortem analysis of such an incident in this posting.

You should be able to get the craft file with my changes here: https://drive.google.com/open?id=1KRTN5QhF7Xt5brd4ki0R1TuuOPRbFeEi Have a look at the settings for the helicopter blades and the up-down axis action action group to see what I changed. To take off you first need to start the engines (press <1>) and set engine RPM to max (press <Z>), then you can use the up-/down-translation controls to change the blade pitch: <K> will increase blade pitch and thus increase the lift, <I> will decrease the blade pitch and lift. I usually keep the window of the one the helicopter blades pinned in a corner of the screen, so that I can see what the blade pitch settings are (I.e. the value for "Deplay Angle" in the window).

The way you described it, it probably is. Not so much because you need to coast to apoapsis, but because by first going straight up and then tilting over by 45 deg you are not thrusting in the direction that you are already going, so you are fighting against the velocity that you already gained. The most efficient ascent is a gravity turn, where you tilt over a bit shortly after leaving the launchpad and then lock prograde, thus letting the gravity pull your velocity vector more and more horizontal. The exact parameters for an optimal gravity turn depend on your launch vehicle: its TWR and drag during the ascent. A typical gravity turn for me looks like this: when the I get to 20 - 30 m/s it tilt over by 10 - 20 deg, when I get to 120 - 150 m/s I lock to prograde, I'll stay there until the apoapsis is where I want it, and then I'll coast to apoapsis and circularize. If I have high TWR I tilt over soon(er) and more and lock to prograde earlier, with low TWR I tilt over less and later, and with high drag (but high-ish TWR) I first go up quite a bit before I tilt over. I kind of try to keep the coast phase, i.e. the time to apoapsis when my apoapsis gets out of the atmosphere, at about 1 - 2 min: if the time to apoapsis increases too fast then I need to tilt over more (or reduce thrust), if the time to apoapsis decreases during ascent, then I tilted over too much. At 1 km distance I usually go for the direct approach (even if it isn't the most efficient). I.e. I thrust towards the target, and then use the method for "Fine tuning the rendezvous" from @Snark's Illustrated guide to docking, to keep my prograde vector pointed to the target.

I guess you are talking about the Illuminator Mk2. I don't have any problems changing the color of the light that is emitted by it. But the color setting only affects the look of the objects that are illuminated by the illuminator, not the illuminator itself. (I.e. the dark or light square on the illuminator doesn't change color.)

Well, after fixing some issues (clicking away the "the part FAR whatever part is missing" messages, setting the deploy angle on the blades to 4 on both rotors) it flies O.K.-ish in stock KSP. It doesn't flip out of control on its own, I can get it to climb fairly easily, it can rotate in all three axes, but rotation in pitch is rather sluggish, and getting it to hover or sink at a constant and survivable rate is tricky. The sluggish pitch control is not surprising: that is the axis in which the craft has a high moment of inertia and in which the two rotor disks provide large amounts of drag. I guess you had problems either because the deploy angle on the aft rotor was set to -0.45 and on the front it was set to 0.0, or because FAR doesn't play well with the helicopter blades. As I said: I prefer when the rotor RPM is kept constant and use the blade pitch (i.e. deploy angle) to control lift. Also the two rotors are well placed to provide pitch control for the craft: to pitch up all the blades on the front rotor have to provide more lift and all the blades on the aft rotor have to provide less lift (and vice versa for pitching down). After setting these (and reducing the authority limiter on the blades to 2) it flew quite nice. P.S. We only ever need the *.craft file. The *.loadmeta file is essentially just the thumbnail and will be automatically generated by KSP when needed.

Without the craft file it's fairly hard to diagnose a problem, but I can give some comments that may be helpful: It looks to me as if you have contra-rotating rotors, is that correct? (If not, then change it so that you do have that.) You also need to make sure that both rotors have the same RPM and torque at the same time. (Except when you intentionally fiddle with that for control issues, but that is an advanced task.) To do that I usually bind them to the same axis action group(s) and only control then via the action group(s) and never manually. To fly any rotor-craft in KSP it is usually helpful keep RPM and torque constant and to control the lift (or thrust in case of a propeller plane) with the blade pitch. In your case that means to set the RPM limit to the maximum, increase the torque until the rotors reach that limit, and then fly the craft only with the blade pitch. How do you plan to steer the helicopter? Only with the reaction wheels, or also with cyclic control of blade pitch by allowing yaw, pitch, and roll control on the helicopter blades? The latter doesn't work well in KSP. It works after a fashion if the whole rotor-disc is to one side of the center-of-mass of the craft so that the blades only need to collectively increase or decrease lift to give the right control input. (I.e. there is no working cyclic control builtin in KSP. But you can make a working quadcopter without reaction wheels.) It is best to first start out with a craft that uses the rotors only for lift and not for control, and uses only reaction wheels for control. Once you get that flying, then you can shift control of the rotation axes to the rotors one by one.

No, not that I'm aware of. See also this forum thread: [Feature Request] One additional KAL-1000 Sequence Loop Mode