DStaal

For on the launchpad, it should be able to auto-fill, though the transfer before undocking is also a recommended method of handling things. For the survey stakes builds - that's intended. The sliders for fuel in that case are just for UI (and coding) consistency.

Good to hear. I expect he's waiting for the next release. I should also update the PatchManager configs slightly - I left some 'optional' fields empty, but that's meant things are blank in the UI.

It accelerates every launch, from what I understand. However, there are other things can accelerate launching the game, including the fact that the OS will cache files, and that MM will cache configuration changes. So the procedure listed is what you need to run through to see how much *this* mod accelerates it, on it's own. Otherwise any comparisons might be swamped by other factors.

I'm not all that interested in the Nimitz, but: Does that drydock have EL integration?

And just because EL is no longer officially supported it doesn't mean it doesn't work. It just means you'll get no help from RoverDude and there will be no MKS parts for it. He's happy for users to contribute PRs keeping support. (Speaking of, if I have some time today I should update that...)

TCA is the choice. Note it does still have trouble with some air-breathing engines on occasion - mostly because the throttle lags, and TCA is continually adjusting the throttle. Do expect a learning curve. TCA is powerful and complex.

Note that 'controlling the craft' is a specialist function. But that's basically what the 'tourist' setting gets you - they'll stop working until you take care of their timer, at which point they'll revert back to their original class/level. Also, if you look at the USI-LS configuration panel you'll notice that homesickness and habitation are already separate - they have separate timers, and can have separate effects.

Personally? Both. Use GC for initial base planting - you can land a DIY kit of your base core, and build it out using a lander or a drop-pod and inflatables. Long-term, larger more complex bases are easier to build using EL and surveyed builds - easier to put it exactly where you want, and for something large and complex, the size of the DIY kit gets awkward to ship up - while EL will just have you sending multiple stocks of resources.

I like it. I also like the idea of putting it in a Patchmanager-managed patch - you could make it so it's default on, and Patchmanager isn't needed - it just gives it an easy way to select to turn it off. That would allow players to play with how they want it.

Looks like you have two, probably valid, choices. Let's examine. @PART[super25nosekso]:NEEDS[KSO]:FOR[z_KSO] Should work fine. *Creates* the mod 'z_KSO' and applies this patch during it. @PART[super25nosekso]:NEEDS[KSO]:AFTER[z_KSO] Again, valid - assuming 'z_KSO' exists. This runs the patch *after* z_KSO. So if these two were both in the same file, this one would run after the previous one. Another option that you might consider: @PART[super25nosekso]:NEEDS[KSO]:AFTER[KSO] This would run it *before* either of the two choices above (since mods are done in alphabetical order), but it would run *after* the KSO mod's own patches. If the point of the 'z_KSO' is to run after KSO, than this should work. (Assuming the patches in KSO aren't using ordering of their own.)

Yeah, looking at the JX2 patch, and the OPM patch, it doesn't look like the patches can be automatically applied in the correct order at the moment. The problem is that the JX2 patch is :FINAL. If that were changed to :AFTER[OPM], then your patch could be applied :FINAL, or you could use a custom name with :FOR that's after OPM, and it would work. But since the JX2 patch is :FINAL, there's no way to override it.

And I'm of the 'never add code you don't know you need' school of thought. But yep, there are good arguments either way. (Though I will mention on your cache statement - for those of us with a lot of mods, it can be rare that we load an unmodified gamedata - just updates to existing mods can be enough that every time you have a chance to start KSP there's more new updates.)

My only comment is that I suspect you don't need the 'AFTER' at all - the parts are loaded before the MM run I believe, and unless there's something that would interfere with adding that module I'd personally leave it out. On the other hand, even if it's not needed I don't think it'll hurt - it'd just make MM work a bit more.

Patches not applying, or applying incorrectly is most likely. With the exception of the :FOR. That causes *other* mods to have errors, where patches were intended to be a skipped (and may not work) are now being applied. It may even cause them to disable functionality that they would have otherwise had.

Using KIS to equip isn't likely to be possible, based on the way that KSP and KIS works. However, there are several mods that have packs that allow you to carry a jetpack, deploy it, and then get into it. (Basically, a small external seat.) First to come to mind is Buffalo, which has a small jetwing you can fly on. Another - fairly outdated, but it still worked last I tried it - mod that has a nice pack is Versatile Toolbox System, which has a large RCS pack. https://spacedock.info/mod/793/Buffalo- Explore In Style

I'd leave it: There's another very good reason for it. That is: Solar panels. If you have them, that 95% will mean the fuel cell will only run if the solar panels aren't doing enough to power the base. If you set it 100%, then you can have an abundance of solar - and still be running fuel cells, and using fuel. (USI does the same with reactors for exactly this reason.)

What I find most interesting is where it he *didn't* make that post: In the SpaceDock thread, to notify the maintainers of that site. (Admittedly I haven't posted an update there either. There are a couple of people discussing the issue, and I don't see the need to add anything - I would just be nagging. But you'd think that would be the first port of call.)

Quick question: How does that actually help? If you're landing and not firing all engines you reasonably can, you're wasting fuel. So telling the player that they don't have enough thrust at that point... Says that they designed the ship wrong, or shouldn't be trying to land it on this planet. Which isn't something they can do anything about at that point, besides reverting. Basically it would be a warning light saying 'you're about to die, and there's nothing you can do about it'. Which is kind of pointless - warning you doesn't help.

That's a misstatement of the problem: It's not that that the version for 1.2.2 is unavailable on SpaceDock, the problem is that SpaceDock is down. Hopefully by the time anyone could find a personal version of the 1.2.2 version, SpaceDock will be back up. And by the time you're doing that, you've pretty much built a full autopilot into this mod, so why not just have the player use MechJeb? ...And come to think of it, even MechJeb doesn't do the full modeling and calc you're talking about here. It does landings in multiple stages - and the main decent stage stops quite a bit above the surface. So it can take an average height over an area, calculate to +$dist$ over that, and then it cancels horizontal velocity, so the final landing calculation is much simpler as the terrain height won't change. You just have to assume the player won't specify a highly-sloped landing zone. (And I've seen MechJeb mess up with extreme elevations - especially when landing below 'zero' altitude.)

No, I mean newly-launched to newly-launched - nothing from before you installed this mod. Many details of ships-in-flight are saved at launch time, and there might be something there that's different between the stock and the new ones, so they don't work with the new models in place.

Does it work with newly-launched ships?

This was in a 'Science Mode' save, so max level. And it doesn't matter for control - but it does matter for science. Science returned via relay gets a bonus that decreases with the signal strength.

It barely has range for Minmus... (I get one bar of signal using it as a relay. Mun wasn't better, actually.)

Thanks. (And yeah, by 'more and more mods' I mostly mean *your* mods...)

An idea I had, related to this an the stock problem of to many preference pages: With more and more mods using this, I'm starting to get a lot of preference panes with only the one button: Whether to use the toolbar or not. Would it be possible for *this* mod to create a preference pane, and aggregate the mods that are using it, so that you just have an array of buttons? I'd guess you'd want to make it opt-in on the other mod's part, so if they have other options they don't need to have this one option be on it's own - but for the mods which only have this one option, opting in would greatly reduce clutter for the user, and the amount of clicks it takes to start a new save.