king of nowhere

that's exactly what you are seeing. that's the new orbit. and it's not elliptical because you are going the wrong way. look, it's the same that happens when you make a manuever towards the mun. you have your ellipse, then suddenly the line breaks and you see a dotted line close to mun. except kerbin is much bigger than mun, so it looks different. alas, that's not how orbital mechanics work. when you are on mun you want to fall down on kerbin, and to fall down from orbit you need to burn retrograde to slow down. which, in this case, will mean your ellipse must point behind the mun, not towards kerbin. if you don't believe it, try it. look how much deltaV it would take to get back to kerbin with your manuever. and then look how much it takes the correct way (should be 250 to 300 if done correctly). if orbital mechanics weren't quirky, they wouldn't use rocket science as synonim for something difficult. getting to and from mun is the easier part. i'm currently trying to start from gilly, get a gravity assist on eve and intercept moho on an orbital node, i know what i'm doing and yet i spent two hours trying different trajectories without getting a really good one.

that seems more practical that my current solutions to this, which are 1) eyeballing it, or 2) saving the game, fast-forwarding time and seeing which day it will be when moho moves in position, then reloading.

Actually, you can. apoapsis was 7.023 Gm, at day 169. gravity assist with moho was at day 261, you can see i set a manuever there only to keep visualizing the trajectory, but it has 0 m/s. after that encounter, the new apoapsis is 6.909 Gm. Not particularly efficient, it is tricky to set up a gravity assist in those conditions. Somebody will be more skilled than i am. but it is indeed possible. doing a gravity assist work a bit like bouncing a ball on a wall. you change direction, but since the wall/planet is moving, you also get some of that speed. if you bounce the ball when the wall is moving away from you, the ball will bounce back slower. that's what happens when you pass behind a planet. circularizing orbit with gravity assists is indeed possible. problems with the manuever are many, though. - you must get a very precise encounter. to do that, you have to manuever. manuevering this close to the sun is very expensive, to the point that you risk losing more in course correction manuevers than you gain in the assist itself. - the faster you speed by the planet, the less you can get out of your gravity assist. with such high intercept speed, your assist is not very efficient. as shown by apoapsis being lowered only by 100000 km (roughtly 50 m/s gained) - you must pass behind the planet, but when you focus the visual on the planet it is in a different position, so it is very difficult to figure out exactly where is "behind". you may end up setting the encounter poorly and gaining speed in the wrong directions

can't you have a moho intercept that you use as gravity assist to lower your apoapsis? i think the messenger probe did something similar.

yes, i know. i've been using that manuever for a while now. in fact, since i'm here, i may as well ask how i get to see the intercept with this manuever, since the game does not show. even when i know (having calculated the orbital times) that i will have a close approach in two orbits, the game does not show that as closer approach, instead showing me some crazy point where the planet is on the opposite side of the orbit that i don't know how the game can consider a close approach. i have to mostly find the SoI blindly.,

interesting statement. how do you know? is there a way of knowing? does that include gravity assists?

i'm not asking specifically for moho. i'm asking as a general rule. and in fact, i'm going to moho starting from eve, from refueling at gilly to be exact, so those dates would be moot. i even figured out for myself the trajectory, since that trajectory is much cheaper than having to make a 1500 m/s plane correction burn midway, and it's very rare to have the transfer window fall naturally on an orbital node. but the thread does answer this: no, there is not another way with the in-game tools.

after some bad experiences trying to get to moho, i realized that i can't just ignore the difference in orbital plane when going to orbit other planets. it results in higher intercept speeds, and i end up paying the cost anyway. so i decided i should preferably start my journey when the starting planet is already in a node. this way, i can pay the plane change manuever together with the ejection burn, and pitagora's theorem will save me some fuel (this will likely be outside of a transfer window, but i can get an intercept by burning when intercepting the target's orbit. if done correctly, what i spend there is mostly saved in minor intercept speed) problem is, i can't seem to find a way to find those nodes, besides eyeballing them. the game does not show them. it only shows nodes when you are orbiting the sun; but then, i'd have made the injection burn already, and trying to make a big prograde/retrograde burn there would make me lose all the oberth effect. so, is there a way to see those nodes? or perhaps some greater trick for interplanetary transfer that will make my experiment with nodes moot?

i have this ship (actually a rover with rockets, but we can consider it a ship for this purpose) with a fuel capacity of 3500 m/s. it has a convert-o-tron, so it can refuel wherever it can land. i wanted to send it to moho on its own power, as a challenge. gilly is the closest i can refuel, so i use that as my start. according to the launch window calculator it never takes less than 5500 m/s, landing included. I managed to bring it down to around 4500 with some clever manuevering, but nowhere near enough for my purpose. I was about to post this in the questions, but then i thought, i already spent one hour trying to optimize trajectories and still haven't explored all the possibilities; this is challenge material. may as well turn it into one, and see if the best score is enough for my rover's fuel capacity. So, the rules are simple. you start on the surface of gilly. you must reach the surface of moho with as little deltaV as possible. I would say no time limit, but i don't want some crazy trajectory using nothing but gravity assists and taking several centuries, so for every day of travel past the 1000th, you gain one point. Final score is deltaV used + 1 for every traveling day over the 1000th. lowest score is better, of course. may the winner find a route cheaper than 3500

sorry, wrong subforum. delete please

i tried to put spacers between the two hinges and it works. and i finally managed to find a way to fit that rover inside a 3-ton cargo bay with a mechanism to lower it to the ground and pick it up again. took me 3 afternoons of trials. i tried the same on the more complex piece of machinery (incidentally, i was sure i didn't use clipping in that vehicle, and i didn't intentionally, but there are some parts that have been rotated in ways that would not be used normally and as a result end up with some clipping on some corners). it didn't work there. but we're talking a very complex robotic arm, with 2 hinges, one piston, and two more hinges all in a row. i'm not surprised if that thing does not work. but i know i have this awesome-looking robotic arm that would be fully functional without glitches, so i still carry it around. if i need to transfer kerbonauts after the coupling i do EVA, if i need to transfer fuel i edit the save file. so, it seems attaching robotic pieces directly to each other causes bugs. putting spacers in between helps, but with the more complex pieces it's a lost cause. i am curious if anyon else is experiencing the same bug?

I tried option 2. i also had a hunch that it may be cheaper. but it wasn't. i had enough deltaV on my ship to get to mun normally, and i burned it all without ever getting close. while i am not sure about the reasons for this, i can hypothesize that it is because of gravity drag. as long as you're not in orbit, your rocket is falling down and you have to constantly burn to make up for it. if you keep launching straight up, you never enter orbit, and you keep paying for gravity drag. 1 and 2, the only difference in cost is that by orbiting eastward you get the extra boost from the planet rotation. as others pointed out, on mun it is very small, but elsewhere it is significant. 3 does not work, for the same reason i explained before.

to be honest, i was using more clipping than i realized for this ship. but i have at least another ship where i'm sure i used no clipping at all, and still i have the same problem

i had to put structural parts between both the hinge and the docking port and the two hinges to make it work. at least now i know how to fix. though i don't like much this solution, i already had precious little space in my cargo bay, putting in structural parts acting as spacers did not help anything. i'll see how well i can do with clipping. in my experience it is a terrible idea to activate any kind of autostrut with robotic parts. now the robotic part has the autostrut telling them to stand still, while it is also trying to move. it never ends well. especially when there are multiple robotic parts involved.

in the last few weeks, every time i tried to dock something with robotic parts, i got some awful glitches on them. I can understand with very complex ships with hundreds of parts, but now i coupled two small things with less than 100 parts total and still the game screws me this is a mechanism to load/unload a rover into a cargo bay, should be rather simple with just two hinges. as i'm still experimenting on the launchpad, there is nothing else above the cargo bay, just a fuel tank to act as counterweight. in the upper image you can see the hinge properly connected. in the lower image you can see that after i dock the rover, when i tell the hinge to bend, the part attached to the rover stand still, and the part attached to the cargo bay moves freely. interestingly, they still count as attached; if i move the other hinge it still carries that hinge along, even if they are disconnected in the visual. I tried using a claw instead of docking port, same result. this is getting very annoying. when i try to make very complex stuff i can blame myself for overloading the pc with too many parts, but this system is simple enough that it should work. and it doesn't happen occasionally so i can just save the game before docking and reloading if needed. no, it happens every single time, effectively preventing me from ever trying to dock ships with robotic parts. is there anything i can do to fix this? (sorry if i'm making so many questions those days, but i'm deep into engineering the helicopterover and its cargo bay, that's when issues arise)

it would also help, every time you are asking questions regarding a specific vehicle, to post some pictures. anyway, it's normal that flying takes long. consider how long it takes for a plane to go around the world. 200 years ago people would have never believed it would be possible to go so fast, and yet it still takes too long for fun. spaceships also take long, but you can increase the speed to skip the boring parts.

when you are in the VAB you can move your visual around freely, but when you are flying your visual is always centered on the vehicle center of mass. you can move around as much as you want, but you are always centered on the center of mass. recently this has become a concern. i have a craft with robotic parts that i need to control accurately, but they are at the end of a longer ship, and so i can never zoom on them. i only view them very tiny at the bottom of the screen. i can't even move the camera to have them at the forefront, because they are to be used when the ship is landed (basically, it involves opening the cargo bay and unloading a rover after the rocket is landed) and so moving the camera closer to the parts would put it below ground. is there any way to free the camera and get something akin to the VAB freedome of view?

after many trials, and thanks to some advice i got here, i finally managed to make a helicopter that flies. yay! unfortunately, i have a lot of troubles landing this thing. or doing any kind of fine manuever. (yes, i am aware there are some... questionable design choices. but i want my helicopter to be fun to drive with internal view, hence a command module with plenty of windows, and i want to be able to load and unload it into a cargo bay, so i cannot use any of the bigger blades. and i need the wheels because there's no way i'm ever going to be able to fly the helicopter inside the cargo bay. Also, they are very resistant, which helps with rough landings) the problem with landing is that i can't seem to find a way to lose vertical thrust in a controlled manner. as i gradually decelerate (i managed to put the engine control on the main accelerator) i abruptly go from having full thrust upward to having no thrust upwards at all. Even at 5% power the engines keep me in the air easily, and if i go below that they stop and i drop like a brick. the engines are probavbly overpowered, but they are the smaller available, and 2 engines won't lift this thing anyway. lack of fine control is also caused by me getting thrust in unexpected directions. like, i activate the engines normally, and i move upwards and forward. i assume it's intended, because most of the times you want to move your helicopter in a specific direction. but if i want to cancel that forward thrust, i cannot do it easily. which adds to the landing problem, because if i try to hover stationary and gradually reduce power to the engine, i start moving forward. another thing i noticed is that i'm severely limited in speed. i assume it has to do with blade angle: when the helicopter starts moving, the actual blade angle will be modified on blade speed and air speed according to pitagora's theorem, and at a certain air speed the angle will become 0 and i will have no thrust. hence why all rotary engines have changable blade angles. however, i don't have any convenient way to change blade angle in mid-flight. having 4 helixes, i must select them all and change them one at a time, which is awfully impractical at best, when it won't make me lost control in the first place. with the action groups i can easily change the blades between extended and retracted, and i can use that to change between 2 different angles. but i don't see how to get better tuning. I think this kind of tuning would also be the key to landing safely. that parachute is meant for an emergency, not as the primary landing gear! so, there's lots of issues. any help with any of those will be greatly appreciated

thanks i knew there must be a function for it somewhere

when i want to fin tune a manuever around a planet, i set the visual focus on the planet. then i must go back to looking at my ship around kerbin. and that's not as easy, because kerbin orbit is so cluttered with stuff than i cannot select the planet. wherever i click, the game thinks i am trying to pick a satellite, or a piece of another orbit. sometimes i do remove everything from the map view. sometimes i click at random until i can get back on track, i'm not sure how. is there any better way?

yes, if all is set up perfectly. i have no doubt the real nasa would do it. and perhaps i will do it too, eventually. as it is, i just started doing real interplanetar trips. oh, i know a lot about hohmann transfer, launch windows, gravity assists and the like, but one thing is knowing the theory, putting it to practice is another thing entirely. so far i am quite happy with what i achieved, but i haven't yet the precision to pull that kind of stunt. not with the precision necessary. and i learned that in interplanetary space a course correction manuever that looks tiny on the map will still eat hundreds of m/s. i am happy to learn of those trajectories, it's interesting and cool, but i don't feel up to replicating them. plus, i'm still close to the optimal duna launch window, so it's a convenient solution to go there. of course. when i say "refuel at duna" I really mean "refuel at duna's orbit".

actually you can syncrozine ships, not side by side (for reasons streetwind explained well) but one after the other. if one ship is ahead of the other, they can effectively be sharing the same orbit, and move exactlty at the same speed. and if you really want them to be facing side by side, just have them point in a direction other than prograde/retrograde granted, from a practical side, it is impossible to completely cancel their velocity. eventually there is going to be a difference of 0.0001 m/s that was unaccounted for that will make them drift apart. but you can get close enough. one time i had to dock two particularly bothersome ships, i did put them in the same orbit, with an orbital time matching to the second. it would have taken at least several days for a difference to become apparent. from a realistic point of view, it also is impossible to achieve perfectly, because there are always disturbances (solar wind, gravity of other planets, microscopic anysothropies of the local gravitational field) that are going to make your ships drift. but again, you can keep them in place for decades, at least. and any small form of propulsion would be enough for stationkeeping. it is part of the reason why any problem with gravitation involving more than two bodies cannot be solved exactly.

it works! it works!!!!! now the atmosphere is no longer an obstacle to my exploration i don't know if it became stable in flight because i moved the solar panels to a way that would not make a sort of parachute, or because i reduced the incidence angle of the blades. i suspect both. anyway, it climbed up to 15 km before running out of electricity anyway, now my helicopter flies really well. now i can start developing a more serious version, one that can be packed into a spaceship and have a less limited authonomy.

i tried to get an eve slingshot to outer space: it takes 900 m/s to get to 140M km apoapsis. in addition to the 1050 needed to get in eve flyby, that's a bit less than 2000, at least in theory; in practice, orbital plane correction and course correction manuevers eat up all that i would gain. from eve flyby it would instead be 600 m/s to get to jool, but setting up that kind of path is beyond me. even setting up the eve flyby so that i can accelerate close to periapsis and get a good trajectory is challenging: made more so because, when i am planning the eve flyby, i see the trajectory compared to the current position of eve, not with its predicted future position. K-E-K-J trajectory... very convoluted. looking at it, i can see that the first eve flyby would put me in an elliptic orbit where i would then wait two or three orbits to get the second kerbin flyby. i would probably have to set up a course correction during that time to get it right. ultimately, i think course corrections will end up eating whatever advantage i gain. it is the most efficient, most elegant solution. but refueling at duna is probably still the compromise i like most between efficiency and practicality.

that would be great, but how do i do it? honestly i tried that design simply because i couldn't make an helicopter lift, and so i wanted to at least be sure it wasn't lack of litfing power...