AHHans

In general there should be. Did you target the asteroid, so that it shows its patched conics in the map screen? What is also possible is that the AN and DN are not on the part of the orbit that is inside Kerbin's SOI. Try fiddling around with a maneuver node.

What I do when I catch asteroids that pass through Kerbin's SOI is to: Match the plane of the asteroid's future orbit. Get into an elliptical orbit that crosses the asteroid's future orbit Set a maneuver node on my orbit at a place outside the asteroid's future orbit, usually on the line from Kerbin -> asteroid's PE -> my orbit Hit "next orbit" on the maneuver node until the intersect nodes on the asteroid's track appear. (If it's too far in the future I just wait before setting up the node (KAC is your friend.) Set up the node so that a prograde burn will give me a nice intercept - you need to balance the "next orbit"/"previous orbit" with the amount of prograde dV.

Ah, O.K. It looked like one part to me. But two of those together have the same lift and mass as one Small Delta Wing which I used, so my results don't change. Saving a few seconds through an optimized flight profile is probably possible, but a higher TWR is going to be hard!

Not sure if it can be done. I added a pair of small nose cones + junos to what I think your craft is (What Is your main wing? A modded part?) and got a lower TWR after setting the thrust limiters.

Well, a TWR of less than one means that the engine generates less thrust than the force of gravity on the craft. I encourage you to try out what that means for a rocket that rests on the launchpad. Another issue is that atmospheric drag is a thing. So you don't want to get too fast too deep in the atmosphere where the air is still dense, that would mean that you spend most of your energy just pushing air around. (I don't know exactly, but 50% of the mass of air is in the lower 10 km or so, so you don't need to get all that high to avoid the bulk of the resistance.) In addition high air resistance means also high aerodynamic forces - which can make your rocket hard to steer or even flip out - and lots of aerodynamic heating, which may become a problem. Conventional wisdom has it that a TWR at launch of 1.3 to 1.8 is good, and that you want to avoid a TWR of larger than 2 while still in the atmosphere. Random facts: Once you are well on your way to space and don't need your engine thrust to counteract the force of gravity you can live with a TWR less than one. When designing a rocket I don't check the TWR at different altitudes. Except for the first stage I only check that the total vacuum dV is enough and all stages that run while still in the atmosphere have a TWR of at least around one. Once you are in space both very high and very low accelerations are viable, but both have their own set of issues. (Try making fine adjustments to your orbit with an acceleration of 5g, or a transfer burn of 1000 m/s with an acceleration of 0.1 g.) The optimal launch profile (how much to pitch when during the launch, how much - if at all - to throttle down at what time) for a rocket depends very much on the specifics of the rocket (how much drag it has, it's TWR at different stages, etc.) and even on the target orbit,so there is no simple "correct" answer. The Saturn V left the launchpad in "slow motion" because it had a TWR of just above one. In reality the dry mass of KeroLox fuel tanks is very low (in contrast to KSP), so the engineers could just add as much fuel as the engines could possibly lift without significantly lowering the TWR of the rocket with empty tanks, and thus increasing the dV a bit more.

In my experience the best method to determine if your craft is orbiting in the correct plane (and orientation) is to look at the ascending (AN) and descending (DN) nodes displayed on the target orbit in the map view. These actually show the AN and DN of your craft's current orbit to the target orbit, so when hovering over the AN / DN markers it shows you the difference in the inclination. And if it says 180 deg then you are orbiting the wrong way around! P.S. These AN / DN markers show the difference in the inclination for your current orbit, not any orbit after a maneuver node - in contrast to the AN / DN markers for a "regular" target. So planning is a bit more complicated.

Shouldn't that be "catfight"? *duck & hide*

I guess you are missing the engines from making history, that can be found on the Making History parts page. (Or directly the stats-table for the engines, if you prefer that.)

Yupp, it does!

Still the 403. You can also put the images on imgur for free. There is a forum post on how to include the images that way: Quick guide to posting pictures on the forum.

It would help to orbit the correct celestial body. The contract is for the Mun, you are orbiting Kerbin. But thanks for including the screenshot! It showed all important information, which made answering your question easy!

... I still only get a "403 Forbidden" when I try to look at the images you linked.

Today I did an emergency upgrade of the astronaut complex: Jeb ran out of fuel when trying to get home from the first flyby of the Mun (in this save) and I needed that to teach him the secrets of getting out and pushing the spaceship.

Yes, but "only" twice so far: I abandoned my first career after visiting Duna and doing a flyby of Eve, because I had nearly all of the tech-tree unlocked and found it too easy. My second career (with only 50% science/funds/rep gain) was "completed", but I didn't visit all planets. I started my third career when Breaking Ground came out. This is also "completed" according to your definition, but I still want to finish the kolonization of the Joolian system and find all the POIs. And I just started a standard "Hard" mode career to see how well I handle no revert to launch. (I tend to rage-quit when one of my people dies.) So you never discovered the secrets of Nanolathing?

That is correct, but you still can have two craft connected via multiple docking port paris. In this case one connection becomes the primary one (which defines the craft tree for those who know what I mean by that), and the others become secondary connections - I guess they work essentially like struts. That's how my Nauvoo Station is built. As stated above: it is possible to have two craft docked together at two points. But from the screenshot I would say the the top pair of docking ports is not aligned, there is a clear offset between the two ports. So in order to have both pairs connect, you have to either align both pairs perfectly while docking or align them afterward, e.g. with rotating servos. For my Nauvoo station I got around this by using SAS to keep the two craft aligned so that I only hat to watch the relative rotation myself. On another note: once one connection is made then the two craft become one, so collisions between the different parts are no longer evaluated and the parts can freely clip through each other - unless you have "same vessel interaction" activated.

LOL!

One thing that seemed to have helped when I ran into this problem is to not have any other parts in the "line of sight" to the target capsule. I.e. that KSP can not be confused which part I meant when clicking. I also switched between left and right clicking (i.e. opening and closing random PAWs), and canceling the transfer and trying again. It is an annoying problem, but - up to now - I always managed to transfer the Kerbal where I wanted them to go in the end.

Good for kidney stones? Sure. (PSA from AHTech industries: renal colics are not fun! )

As I wrote, either with the update from 1.8 to 1.9 or with the update from 1.9 to 1.10 the directions of the rotor blade pitch was changed. But you can change them outside the editor, so "just" switch on the aerodynamic overlay, and toggle the "invert" button until the arrows point in the right direction. P.S. You might need to switch on the "advanced tweakables" in the game settings.

P.S. I just checked my Basic Quadcopter ng, and, indeed, the deflection directions changed between KSP 1.8 and 1.10. I updated the craft file on KerbalX to work with the new version. P.P.S. I just noticed that the left landing gear wheel in your screenshot is fully depressed, while the right one isn't. So, yes, that rotor is thrusting downwards...

The green arrows in the aerodynamic overlay show the rotation direction of the blades, not actual forces. This is used to determine when and in which direction the blades need to deflect when used as cyclic or collective control-surfaces. The red (drag), yellow (control lift), purple (artificial rotor lift), dark blue (airfoil lift) and light blue (body lift) arrows show actual aerodynamic forces. Unfortunately it's hard for me to see from your screenshot if these (the yellow and purple arrows) are in the correct direction. But I'd guess that on the rotor on the left they are pointing downwards.

Well, such an "electron drive" could kind-of "work" - for a very loose definition of "work" - if you consider picking up electron from the interplanetary plasma. A positively charged spacecraft will attract the electrons from this plasma (and repel the positive ions/nuclei), so it will neutralize its charge partially from the plasma and not only from the electrons it expelled. So if you limit the number of electrons that you push out to the number of electrons that you can pick up from the plasma then you could generate some net force. My guess is that the force that you can generate this way is smaller than the force from the light pressure of the sunlight on your craft. And if you want to go that way then I'd suggest looking into more direct ways of accelerating the interplanetary medium around your spacecraft. (Not that I believe this will be a much better idea.)

You also need to check if this is a case of bug #24282, i.e. if the orbit that is specified in the contract is an orbit from which the sentinel cannot detect asteroids close to the requested body.

Hi @udkwum, welcome to the Forums. The overly simple answer to your question is that you lock hinges - and other robotic parts - by telling them to activate the lock, e.g. by clicking on the lock button. (SCNR) The real answer to your question depends on what your problem actually is: do you have problems activating the lock, or that the robotic parts still move around even when they are locked (unfortunately both are issues with the robotics parts). In my experience activating the locks is an issue if the game thinks that the part in question is still moving, e.g. because the whole structure is still oscillating a bit after changing configuration. In that situation you will get a message and the lock will just not set. When you want to set the locks on multiple parts, then it will usually set on some of them but not on others, that makes using the "toggle lock" functionality an exercise in frustration. So what I do is to put "engage lock" for all robotics parts on one action group, that way I can hit that button as often as needed until all the locks are set The other issue is that the robotics parts are rather weak and prone to permanent deformation, even when they are locked. There is no magic bullet to solve that so you'll have to engineer around that. The best tool here are struts, autostruts and regular struts. IMHO the biggest advantage of locking a robotic part is that this will allow autostruts to traverse the robotic part. So if you place a hinge or so between two sturdy parts and then set autostrut to "grantparent" on the downstream part then this will transfer a lot of the forces around the hinge and thus make the whole structure so much more sturdy. (You can also use the other types of autostruts, but they have problems of their own that are unrelated to robotic parts.) Regular struts can help you keep your craft together during launch before it has to move. I often place dedicated decouplers on my craft that then only have struts attached to them that connect to different parts of the craft. While these struts are in place the robotics parts cannot move, but once the launch is over - and thus the main stress on the craft is over - I can fire the decouplers, get rid of the struts, and allow the robotics parts to move. Does this answer your question(s)?

You can't do normal time warping, the game just cannot do that. What you can do is physics warp: on Windows press <Alt> + <.> (like time-warp but add <Alt>) on Linux use <R-Shift> + <.>.