DStaal

I think you need to over-write. And note that USI-LS will take the most pessimistic setting it sees from any settings file - if you're using MKS as well, it has it's own, for instance.

We'd need more information than this. A log file of when it happened would be best - but if you can't get that, can you tell us things like: Are there any other station contracts in progress? How long have you had the contract since you picked it up? Etc.

BTW: It might be nice to be able to add stuff to the wiki on GitHub. It doesn't seem to be enabled for this project.

KIS does allow you to 'translate' parts as well - Usually you can move them up a ways using the 'B' key, IIRC.

Just as a note: Changing settings won't be retroactive. It'll work in the future, but not on actions that have already happened. Anyway, the only way to cheat him to not be tourist would be to edit your persistence file. (There are of course the non-cheat ways as well, which should work.)

I don't think realism is the point here.

And probably crew capacity to the docking port. I think Pathfinder has a couple of parts where if you place things right it *looks* like they're coming out of the docking port. (That is: They've got it set up so adding their docking port to their part in the right place doesn't occlude the hatch for that part.)

I don't believe so. On the other hand, it's just a visual thing - it actually works in seconds, so the number of hours in a day is only for the GUI screens. Not that I can't see it bugging people.

Plopping a mock-up on Kerbin is a great idea, I think. There are actually two mechanics that won't be replicated: Homesickness, and Kolonization. (Well, Supplies will be only partly replicated: you won't have penalities.) The latter will increase your production over time, but can be ignored starting out.

Historian: (Check near the end for info on 1.3 compatibility.)

Well, not laughed out of court. But you might be limited to small-claims court.

You're in the wrong thread - those would require changes to MM, and this is the PatchManager thread. (Well, the :FOR idea wouldn't, but I can see arguments either way. I think the current way you can save KSP from actually trying to load things in the first place, and save some RAM therefore, but I'm not sure.)

That won't help unless he's willing to start a new save...

BTW: There's an unofficial build of KJR near the end of the KJR thread which is working fine for me.

Describing it here and hoping someone likes the idea enough to make it is probably good. There might even be a current mod that does what you want, and you just don't know about it. Your other option would be try to learn to make it yourself - if you know any programming it shouldn't be too hard, and there's a lot of help available over in the modder's subforum.

I believe you just need to be in the modules. As for the bracketed functions: When in those modes, the module doesn't do that itself, but it makes any *other* nearby module that's in the corresponding un-bracketed mode more efficient. So if you put it in [Smelter] mode, nearby Smelters will produce more. They're helper modes.

And regular maintenance as well.

My guess was that it's just an oversight - it's a different module, so it's not 'default', and I wouldn't have thought about it either until I noticed that I couldn't collect the data from these parts.

On the ScanSat parts - Your patch adds the scansat *scanning* but not the scansat *experiment*, making your parts strictly worse than the scansat parts as they can't collect science once the scan is done. Is this intentional?

Thinking it runs on a batched process is somewhat misleading - though technically it might be accurate. What it doesn't do is run on an *independent* process. Like most things in KSP, I believe it runs once per physics tick. One of the main properties of KSP is that physics ticks can represent various amounts of in-game time. At standard, they're basically once every frame of the game, in realtime - but you start using the timewarp and they get further apart. The game doesn't try to do a continuous simulation of everything - what it does is record all forces and processes occurring on each part, assume those are static for a moment, and then calculate the result at the end of the moment. Each moment is one physics tick. So, to speed up time in the game it makes those 'moments' longer - and conversely if you have enough going on in your game you can actually have a 'moment' take longer in real time than it does in game time, at which point the game slows down. But the advantage of this system is that every 'moment' (or tick) will take nearly identical time - regardless of how long the moment was. The length of time they take to calculate is dependent on the complexity of the ship and it's environment, not how long the time period that passed was. (And note at higher time warp levels KSP actually simplifies by making some more assumptions.) When arriving at a ship you haven't seen for a while, KSP uses this to catch-up: It runs the time warp on that ship at the maximum speed until it catches up with the present. That speed happens to be one tick is six hours. All logistics does is go 'every tick, check to see if we need to either pull or push resources, and do that'. If the tick is 1/60 of a second, it deals with the resource change after 1/60 of a second. If it's 6 hours, it deals with the resource change after six hours.

I think you could probably work out something with Smart Parts: I'm not sure you could check EC level, but you could do speed or something else I think. Then bind all the solar panels to an action group and have it get fired.

Honestly, for a ground-based base I think just adding more hab time is likely more efficient. If the hab timer is high enough it stops anyway. I mostly see the life support extension being good for colony transport ships, where you'd need it between worlds. (And then you won't have multiple ships within 'base' range.)

No way to train them to be less stupid - but they'll be more productive at higher experience levels.

Actually, it *is* something JC would do. If you perma-prune parts using JC, then they won't be loaded by KSP at all. (Permapruning is a two-step process: You first have to hide the part from both the VAB and the SPH, and then hit perma-prune.)

I meant once it's out. ('*Then* I'll get...')