arkie87

Does this count as adding something else?

Due to reasons i dont want to talk about (i.e. i just barely ran out of fuel on the way back from a rescue mission from the mun, so i had to use EVA RCS fuel to deorbit rescue vessel but ran out of RCS fuel in the process while Bill was still outside the vessel), i had Bill in EVA with no RCS fuel remaining, and had to pick him up by maneuvering the craft to him so that he could grab hold. HD youtube video of the rescue: I was wondering if you guys think it should be possible to use one kerbal to grab another so that we wouldnt have to maneuver craft into position?

So to obtain true Lagrange points, N-body physics must be simulated, but since no analytical solutions exist, the game will likely never implement that due to processor limitations. However, i think it should be possible to simulate Lagrange points themselves via the already implemented SoI functionality. Lagrange points would be simulated as point masses (since they need a gravity well) whose orbits are "on rails" (since there velocity and distance would not satisfy kepler law mechanics and the solver wouldnt work for them). When you get close to the Lagrange point, you enter it's SoI, just like any other planet or moon. If your velocity is too different than the necessary one to remain in the SoI/Lagrange point, you leave it (just like a planet), but if its close enough, you get trapped in orbit around the Lagrange point. If the Lagrange's SoI is small enough, this is almost the same as being trapped in an actual Lagrange point... What do you guys think? Alternatively, the lagrange points could be simulated as 1 m diameter spheres, which could serve as easter eggs for the players to find?

I agree. They should either remove all the science from the EVA around KSC (or remove the biomes, but i assume they cannot because its related to the destructible/upgradable buildings), or allow you to EVA without a suit, but kill your kerbal.... (and he wouldnt die on Kerbin or Laythe)

The devs have explicitly stated that auto-launch/perform maneuvers is out of the question. However, MechJeb could integrate pilot skill into autopilot function based on what i suggested above?

To elaborate: it would be cook if piloting skill came in a few levels and kerbals could level up as pilots: Level 1: perform maneuver nodes Level 2: perfect execution of maneuver nodes; simple docking Level 3: moderate docking; simple landing Level 4: complex docking; moderate landing or something like this, etc.... Using a level 1 kerbal to attempt a docking or landing might (read: will) result in him smacking into your space station or tipping over on landing... (assuming you let him pilot and dont override/pilot yourself) The way this would be implemented is via the math already present in the autopilot: as far as i know, MechJeb (as well as FAR's autopilot) uses a PID controller to stablize the craft. PID controllers need finely tuned coefficients to fly craft well so that they dont overcorrect and become unstable; if you make some of these coefficients too large or small, it will not perform well. Thus, these coefficients can be modified behind the scenes based on kerbal skill... What do you guys think?

I think they can and should make it more complicated than that. One thing that Kerbal Space Program has been lacking is the last word of its title: program. Having Kerbals actually pilot your crafts would bring a welcome change of focus in the game from "build and fly" to "build and manage" (hence the "program" part) as I think most seasoned pilots enjoy designing new craft and planning missions more than actually performing the maneuvers and waiting for transfer windows etc... (exception: spaceplanes) However, with regard to having stuff done automatically and instantly (like establishing a trade route) with pre-determined results and penalties based on kerbal skill etc... (as you suggested)-- while it might add in the "program" feel too, the devs would be forgoing an opportunity to enhance the Kerbally-ness of the game: just imagine watching the little green monsters flying your maneuver nodes and performing landings in real time, and, undoubtedly, messing it up dearly. Edit: i am not opposed to the ability to establish automated "trade routes" to perform routine actions that you have already manually performed (i actually love this idea); i just think the kerbals should actually fly the missions, rather than it being done instantly with predetermined results and penalties. I want to watch them mess up due to lack of skill on difficult maneuvers...

HD Video:

I thought Jeb was better? Or maybe it was Munfrin...

It is similar to what MechJeb only insofar as they both have to do with time warping and are ways to prevent time-warping past maneuver nodes or SoI changes; otherwise, it is completely different and a novel idea, i think. It is a way for Squad to improve their current GUI/environment (without needing to add a new window to clutter the screen): just like you can click anywhere on the trajectory to add a maneuver, so too you can click anywhere on the trajectory to warp there. This adds many other benefits besides, as listed in original post as well.

Thanks for the praise/rep! In general, i dont think the potential for new glitches should impede a suggestion, otherwise, no suggestions should be implemented

Basically, as the title says: when right clicking on the orbital trajectory in the map view, two buttons should appear: "Add Maneuver" (which currently exists) and "Warp to" (which is new). Clicking "Warp to" would warp vehicle to the point on this trajectory (assuming trajectory doesnt pass through atmospheres or planets/moons etc...). I think this should be possible since the way KSP works when on rails is by calculating positions at time t rather than integrating. Thus, the points before the desired point need not be simulated. The way i see it, there are a few main advantages: (1) This ability would make transfers to Jool (and the additional gas giant planets when they are added) instantaneous; at present, even using 100,000x takes a few minutes of real-life time to get out there, and I assume the dev's dont want to add a 1,000,000x button... (2) It would make time-warping past maneuver nodes easily avoidable (instead of manually time-warping to a maneuver node, you simply click on a point sufficiently before the node, and click "warp to". (3) It would allow SOI changes to not lose precision (since current patched-conic values would be used exactly)

well, thanks for posting about bi-elliptic transfers anyway It's kinda counter-intuitive that they would be more fuel efficient under certain circumstances, and i enjoyed reading the wiki article about them.

Can this do what I am suggesting? It doesnt seem like it can put a moon in the SOI of another moon and that moon still have its own SOI?

Yes, so i figure, for it to be stable, it would have to be near the SOI boundary or at least in very high orbit around the planet, and the parent moon would have to be relatively large compared to the sub moon

Interesting. I assume you have to place the periapsis precisely though, since it wont be possible to adjust it later with monoprop alone, and then you would have to worry about transfer window expiring during the fall from HKO, as GoSlash27 pointed out

And if a minmus analogue orbited the mun analogue

I see. But a moon with a SOI would be cool too...

Is it possible for a large moon of a large (gas) planet to have its own moon, or would the gravity from the large (gas) planet steal it inevitably over time? Either way, should one of these be put into KSP?

I am more interested in where the balance point between burning retrograde and falling into LKO (or LXO if not around Kerbin) and then burning out vs. burning out from the original location. There definitely are more efficient (but more complicated) maneuvers, such as bi-elliptical transfer and gravity assists if the conditions are right. Your point about missing the window costing more than assist is good though, especially given how many days it takes to fall back to Kerbin from minmus. That said, I think i answered my own question with the second graph i posted, which states that the balance point depends upon altitude and intended deltaV. I would probably have to make this graph for each planet to fully answer my question, but i think knowing that in general, its probably better to burn down towards a planet if you are near SOI boundary is good enough

Exactly, and that's what my graph shows: once you are low enough in orbit, the cost of going lower to gain more velocity outweighs the benefits, unless you need a lot of deltaV... And i imagine the balance point varies from planet to planet....

What if you use RCS to thrust down onto the ring, then get started walking, and once you are walking fast enough, the centrifugal force is enough to keep you there?

I wasnt only asking about transfers out of Kerbin SOI from minmus; thus, my question (still) stands-- are there any other practical transfer maneuvers in KSP where it doesn't pay to do (? von Ziegendorf suggested that Tylo to Kerbin might be one example where it does not pay to fall towards Jool first. I will run the numbers soon to see if he is correct. Regardless, in theory, it is possible, and the graph suggests that the lower into the gravity well you are, the larger the burn you need to do to make it worth it.

Perhaps this graph will make more sense: It is a graph of altitude above sea level vs. deltaV burn required to make (a) = (. Thus, if your intended deltaV burn is larger than the blue line, it is more efficient to do (; if it is below, (a) is more efficient. Minmus is around 50e6 m, so reading the graph, deltaV ~= 600 m/s (noting the log-log scale) Similarly, if you're at 200 km altitude, your intended deltaV burn would have to be around 8 km/s for dropping periapsis down to 100 km to be more fuel efficient... which makes sense

Yes, thanks for replying to him. I agree with you. I was very confused both from the fact that he implied that the maneuver was worse for most cases (which it isnt in the case of Minmus) and by his labeling of this maneuver a "bi-elitpic transfer", since, after checking out the wikipedia article, it doesnt seem like it is for the reasons you described.