Garek

look for Action Group Manager, it basically does what this wanted to do, but working and with a (imo) better UI

Just read you're going to use something like a stripped-down boo for user-defined variables. You aren't, by any chance, thinking about extending that to an Autopilot scripting thingy, like kOS, but you know, with proper language features like functions and arrays and non-messed-up maintenance? Or if someone else is interested in doing that (and has the time for it), that would also be nice. I would propably try to do it myself, but I'm always running out of time, so...propably not going to work out. Of course, this is all very hypothetical since your basic Boo integration is still just a plan, and there might be a usable fork of kOS incoming.

For what kind of ascent do you need that trigger at more than 100km up? atmosphere cutoff is at 70, and even around 40 it's already mostly irrelevant.

Single part? propably a folding arm like Liowen said I first thought of fairings, but even Procedural Fairings need at least two parts.

Depending on how heavy your base modules get, you could make a single-end rover work, so the other end of the module can be docked. Just put a counterweight on the other end of the rover. This has two requirements: - the rover has to be significantly more heavy than every base module - the base modules have to be light enough to 'hang' from one end without touching the ground Of course, if you use mods (I think I see a KAS winch there) you can get a lot more creative. Some tips what you can do with KAS: - use hooks to anchor the carrier to the ground (so it doesn't tip over etc.) while un-/loading modules (maybe combine with robotics) - use EVA struts to secure a loaded module

Two reasons why I, personally, need multi-seat pods: - I don't like to send a kerbal far out into space all alone - that's pure RP, there is no gameplay reason for this - I can use my regular manned craft for rescue missions - might actually be more difficult than just using an empty pod with probe control, didn't test it yet So I would conclude that although it offers no real improvement from a gameplay perspective, there are reasons to use it, depending on your play style.

You could just use a docking port for a low-force decouple. If you place a single docking port (during construction) like you would a regular decoupler, you can undock from the payload placed on top of it. Bonus in this case: after the probe is out of the way, fire the fairing decoupler to shoot the port into oblivion. (space, actually. But there isn't that much of a diffference for a lone docking port)

This is basically what I'm waiting for. I like the concept of remote tech, and used it a little bit in .22, but if I use it, I want to be able to run stuff like a landing program on a probe itself so it's after the signal delay. Sadly, it doesn't seem like Kevin is coming back soon, and a fork propably needs some more time to get started and working.

Maybe Kerbals aren't actually that solid, and as long as they don't wear their spacsuits (aka fully pressurized enviroment), they can fit through most pipes.

What do A/D, MECO and CONT mean?

But ALCOR-camera part will also work out-of-the-box, right? Also, I want the new IVAs. And since I won't be able to play KSP in the next days, maybe .12 will be out when I finally start .23 for the first time

I also don't run KSP without FAR anymore. Mostly for rockets, because I want fairings to work, and I want my rockets to flip if I build or fly them wrong. So I want better aerodynamics, but I'm happy to use FAR in the meantime.

Wait, pods include Monoprop now?

You're right about that, and I agree that's a strong point for the tweakables not being finished yet. My argument was more ment for the general "you can't use less oxidizer to pack more LF because the internal tanks are fixed" vs. "why should the supposed internal tanks be fixed when we're designing a new rocket?" discussion.

I think the point is more like, when the NASA launched space lab, they just used a spare Saturn they had lying around, without changing fuel tanks to optimize it for that task, because it was cheaper just to use it as-is. The problem is, you can't model this in KSP, not before you introduce currency. Without currency, either you allow a player to change tank types around without limits, or you always limit him/her to some constraint e.g. maximum of fuel per fuel type stays, as it's apparently implemented.

That you no longer have to build symmetrical is not only useful for Shuttles. I think it's also nice for multi-part interplanetary ships.

But it shouldn't it be possible to switch which kind of fuel goes in which tank? So you couldn't lower one slider to increase the other, but you could assign which slider has which fuel. I don't care about the tires themselves, but I really want to be able to edit the ground clearance.

I think it would be awesome if every player got there own KSC. Assignment would be an issue, but is solvable. The bigger problem is, that a planet with only a crowd of KSCs is even more absurd than a planet with nothing but the KSC.

I should have been more clear, I didn't mean difficult per se, I mean difficult because I like the rotation of my pods to be aligned, because otherwise the positioning of windows etc. along the craft looks wonky.

As far as I know, you can actually make reasonable assumptions about the gravity of the planet (remember, SOIs are a simplification of a multi-body system) without sending a probe, just from the interaction with other planets. Especially if your not concerned about local gravity (e.g. for landing), but on it's range of influence into interplanetary space (aka SOI). Also, I can get the SOI range from KSP without any additional tools because the maneuver planning shows a trajectory projection including SOI changes. Adjust a trajectory until it barely hits the target SOI and read the projected Apoapsis. This value is a reasonably good approximation, especially given that the only way to truly measure it with a probe would be to fly across the boundary and read the height at the moment of change... Also, when talking about 'data files' we need to remember that kOS doesn't actually support file IO yet, so what we're using as database files are actually scripts setting variables, which is a waste of memory compared to actual data file formats. I would like to be able to store a certain part of a map whenever I get around to actually writing that super-awesome-landing-program (I'm waiting for RT2 integration, amongst other things), but because kOS supports neither arrays nor efficient data storage, it's impossible.

I imagine there will be MM files for that being thrown around on the day of release.

it also makes it really difficult to construct something (e.g. space station) where kerbals can get from pods to hitchhikers (or other parts with hatches right on the side) via ladders only.

Hm, doing a ballistic reentry with a capsule I can get it right into booster bay (aka in the water next to KSC) on a good day. I just do a deorbit burn to a ~20km Periapsis somewhere in front of the next continent after KSC (don't remember the exact location, and it varies depending on initial orbit). This isn't anywhere near precise enaugh for something like a base, but it's sufficient for we-don't-want-out-kerbals-to-walk-across-the-globe. I'm not sure how I would go about landing a base on an atmospheric planet. Some kind of indicator would be very helpful there, I agree. I also thought about writing some kind of self-correcting descend program in kOS, which would integrate using current drag loss, but that is still very much theoretical.

IIRC the problem with FAR and trans-atmospheric precision landing is that drag is no longer purely a function of the parts of the vessel, but very dependend on both it's shape and orientation. So for any kind of landing prediction to work, it would have to know your orientation during descend, when you activate the chutes, etc. And even for a specific descend profile, this would probably be excessivly complicated and (run-)time consuming (aka lagging). I think it's the same problem aerobraking calculations have with FAR: even given a specific descend profile, you need some time beforehand to calculate, and if you don't execute that profile exactly, the calculated results are worthless. The simple solution of course is to just try repeatedly and get a feeling where you end up landing in relation to both vessel shape and descend profile. EDIT: Real space agencies run simulations for stuff like this, I think. But in KSP, the equivalent would probably be Quicksave, try, Quickload instead of having FAR running a simulation which might not work out as stated above.

I have no problem with a hard dependency on the toolbar, because that gets us faster to the point where everyone has the toolbar, so mods can use it without worrying about these problems, like it's currently with MM.