Pand5461

Or zero the thrust in the VAB. I prefer doing both, just for extra safety.

Okay then, I didn't get that from your original question. But my point is still the same: increased costs reflect the fact that pod has doors (and probably airlocks but who knows).

What? There is a Mk2 Crew Cabin with 0.5t/kerbal, 1050 credits/kerbal, 45 m/s impact, 1400/2000 K. Why such difference in costs? It's the addition of the hatch I think (and hitchhiker container also has ladders!)

@linuxgurugamer, is this code supposed to run in a loop? If yes, for the performance reasons, I'd suggest calculating localg as mu/R^2, where mu is standard gravitational parameter of the parent body, R is distance from body center. In kOS it's as follows: set rb to ship:position - body:position. set localg to body:mu / (rb:x*rb:x + rb:y*rb:y + rb:z*rb:z). Don't know how it looks like for mod development though. From your code, it looks like that FlightGlobals.getGeeForceAtPosition is calculated as a vector, and only its magnitude is used. It adds a lot of unnecessary computations if you only need a scalar.

On second thought, you are right, it must be possible. So, here's the kOS lander code: https://drive.google.com/open?id=0Bw2BzA4x17Y2Tl9OcW5GNkVkcDA. It does landing by trying to maintain constant horizontal and vertical acceleration. So, on the problem in OP. As far as I understand, the number needn't be very exact unless it's close to zero. So, you may integrate retrograde burn until all velocity is killed, then assume distance traveled through burn proportional to vertical speed and estimate when to do suicide burn by that condition. The integration may be done by, say, Verlet scheme because it's computationally cheap and accurate enough, to my experience. Also, timestep of about 2 seconds should be enough, except for final moments of braking. Some concerns: Equations of motion must either be done in inertial frame or centrifugal and Coriolis forces must be accounted for. Unlike vertical burn, the ground height at landing site is generally not the same as right beneath the ship. In the case of vertical burn, if you missed the right moment - you are certainly going to crash. When you have initial horizontal speed, there are two cases - one is when you can't kill all vertical speed at touching the ground even burning straight up all the time, the other when you don't have enough time to kill horizontal velocity before touching the ground. In the former case, you are doomed. In the latter case, the situation can still be fixed by burning a bit upwards from retrograde. Thus, the time shown may be quite a bit misleading.

Erm... Holding Retrograde at full thrust most probably won't work - you won't be able to bleed off horizontal and vertical speed at the same moment. You are going to need either fairly complicated steering or throttling. Stock SAS doesn't do either of that automatically. I can post my continuous-burn landing script somewhere. It is not exactly this exact problem but might give some ideas.

I can guess why no one is even bothering about suicide burns that start with significant horizontal component. The difficulty is to keep the direction of the burn that won't be purely retrograde in such case. As for SQRT in time to burn computations - that might come from the approximate solution of the Tsiolkovsky's equation with gravity, I have to compare it against the formulae I obtained while writing kOS landing autopilot.

My pleasure Thanks for the great mod! Build #15 works just fine on my side (but I have no idea what "Recover to storage" means).

Thanks, @magico13! With the new build, the rollout issue is gone. Editing bug is still there. From what I briefly tested seem to work: Crew assignment (only tested when assigned crew becomes available by the launch time) Rollout -> Launch without changing scene Rollout -> Rollback -> Rollout -> Launch Wait until build completion -> Edit (a finished ship in storage) Rollout -> Rollback -> Edit What does not: Editing ship from build list But now, edited ship appears after the original in the queue, while in the previous builds edited one was first to build. There are still messages of successful removal in the "bugged" case, whereas in the working case there are messages about ID comparison. Maybe I'd better open a Github issue on this? Logs: Editing vessel from list Editing vessel from storage

Yes, the bug is still there on my installation. OS-specific issue?

Oh, sorry for the wrong log. Haven't read the reporting guidelines properly. The issue persists with build #13. It wasn't present in #10, though. Logs are attached. Both times I entered VAB, edited a craft being built and saved edits. #10 - no dupe appears, #13 - there is a dupe (or, actually, an unedited initial craft) in the build queue. For build #10 For build #13

@magico13, I'm trying KCT build #12 and encountered an issue right from the start. For some reason, vessel is not getting removed from the VAB storage after rollout, so I'm getting two for the price of one. However, this only happens if I don't reload the game between rollout complete and launch. So, if I wait for rollout, then go to any building and immediately out - then everything is perfectly as expected. This is done on a clean install (reinstalled from Steam, no mods except for KCT and ModuleManager). How to reproduce: Start a career game with default settings. Build any vessel in VAB (just Mk1 pod will suffice). Warp for build completion and rollout. (a) Click Launch in KCT window or (b) enter and exit Tracking station and then Launch. From launch screen, return to KSC or Recover. (a) There is a vessel in VAB storage ready for rollout or (b) VAB storage is empty, as expected. Video showing the process: https://youtu.be/-xJso9Gkd0E Log: Edit: Storage and build queue overall do not work as expected. Editing a craft does not remove the original one from the queue or storage.

@lajoswinkler, are you sure this all works without decoupling? I mean, will it still hit the hole after two SOI changes? And, even if you delete decoupler, the orbit still may change enough to miss due to CoM shift.

Great! No more "built ship for tourism, forgot to put actual tourists at start". Will try it.

Nailed it! Starting in an equatorial orbit. Because having a mothership on a polar orbit is not very practical. Transfer: Approach: In the hole: And a smooth touchdown: And kOS code to handle this, if anyone cares: