Terwin

e=mc^2 thus m=e/(c^2) It takes a lot of it, but you put enough high-energy photons together and you get a m where g>c

I thought @MatterBeam was dismissing development costs, not operational costs. The operational costs that were indicated as follows: refueling from earth: $$$ per ton (see per-ton launch costs elsewhere for exact numbers) Atmospheric scoop: 1 falcon-9 launch to LEO to put the craft into space providing ### tons of liquid nitrogen and ### tons of liquid oxygen per year of operation over and above the needs of self-fueling(operational life-span TBD but expected to be measured in years or decades) Lunar or asteroid refining: large/expensive mining and refining infrastructure that will take a long time to set up and will need a way to operate long-term without human presence (admittedly the moon/asteroid argument is not terribly clear and should probably include references to the cost to deliver replacement parts due to the high degree of wear and tear on mining equipment for a good apples-to-apples comparison)

It sounds nice, but the question is, why is this not yet being done? 'No one ever thought of it before' gives a nice ego boost but is hardly ever true. Refilling a tank in space has never been done as far as I know, and there are numerous issues with doing so. Off the top of my head: * re-compressing whatever was maintaining pressure in the tank while the previous fuel was taken out, * rendezvous/docking * making a sufficiently tight/secure connection for transferring a cryogenic liquid without letting it evaporate or boil off I suspect that if Mr. Musk can successfully refuel his as-of-yet-undeveloped ship in space, then we will have a better idea of what is needed for a successful refueling. Until then, a self-fueling pusher craft could probably be quite useful if you can convince enough clients to include your required docking facilities so you can push them to their desired orbit.

Sounds like lessons learned with the Making History DLC will make it into the game before the DLC is even released! (Assuming the base surface stability is related to reliably placing vessels on the surface for the mission creator, and I see no reason for them to be different)

If you are willing to go with used parts, you can probably get a reasonable upgrade for a fairly small expenditure(Goodwill computers may be a good option to look at if you have one you can access, but other used computer stores can also be pretty inexpensive, especially just buying bits and pieces, perhaps under $100 if you can either reuse your power supply or get a cheap adapter). It really sucks when real-life gets in the way of the things we like to do, but it is still important to realize that KSP is only a game, and things like Food/Rent/Medical Bills take precedence, no matter how much we might wish otherwise.

I too am a fan of RoverDude's USI suite, but if you have multiple vessels with MKS parts in logistics range(150m to 2km) I believe that is currently causing a slow-down due to the extra background processing for local logistics, especially if you have drills running. Also, a mod need not be large to have a major impact on the amount of processing required per tick of the game clock(Even having several unattached docking ports can slow down play due to them each checking to see if any other docking ports are in range when that vessel is loaded) Chatterer is probably the only QOL mod I am familiar with which I would be comfortable saying is unlikely to have a negative impact on game speed.(KER is *probably* ok as is primarily reads pre-calculated values but I am not 100% sure) Any other mod with a .dll file could be responsible for your slow-down(or possibly a combination of two or more of them).

When you upgraded to 1.3 was that a case of a fresh install where you copied over your save game and installed updated versions of your mods, or did you just plot 1.3 on top of 1.22 and hope it would work? Same for the downgrade, was it a fresh install, or might you still have artifacts from 1.3? Artifacts seem like the likeliest reason for your 1.2.2 install not working the way it did before. Also be sure you have the right versions of your mods, as incompatible mods can cause problems as well. The big change for 1.3 is localization, and I could see how that could take an additional chunk of memory, it could also put a bunch of stiff inyour KSP folder that would not be over-written if you just tried to install 1.2.2 on top of it. If you only have 10 mods, might I ask what they are? Perhaps one or more of those are more resource intensive than it would seem. An additional option is try out a fresh 1.3 or 1.2.2 install in a new location on your Hard drive and see if it has the same issues as your current save game. It is possible that something about your computer changed around the time you switched from 1.2.2 to 1.3 and that is the source of your problems.(settings changes, malware, etc). Note: Recommended System Specs: * 2.0Ghz Dual Core CPU or higher (preferably higher) * 4GB RAM * 512MB Video Card, Shader Model 3.0 * 4GB Free HD space * Windows Vista, 7, 8 or 10 * An Intel-based Mac running Mac OS X 10.8 or higher * A Debian based Linux distro * Chromebooks are NOT SUPPORTED

Ok, so rock can be used as reaction mass And rock can be had for free even in space. Infinite dv! I may need to check out how well a mass driver/counterweight powered engine works...

With the default difficulty settings I was able to unlock all level 5(90 point) technologies without entering orbit or leaving the Kerbin SOI in 1.0. As Supersonic flight is a level 6 technology, requiring only a single level 5 tech, which in turn requires only a single level 4 tech, it should be pretty easy to unlock it without leaving kerbin. It may well be easier to unlock it by going to the moon, but that is because this is a rocket game and not an airplane game, and going to the moon is one of the things that almost everyone tries to do early on, and thus become more practiced at than flying around kerbin visiting every single biome.

Are you using the 64bit version? Do you have any mods? How much ram does your system have? Generally using a lot of mods in the 32bit version is bad for stability, visualization mods in particular tend to take a lot of memory. If you have less than 4gb of ram, it may still be a good idea to avoid visualization mods in the 64bit version as well, just because you do not have large amounts of memory available. While memory usage was a problem in the 32bit version, it has become a much less common problem in the 64bit version, and Garbage collection has had a lot of focus in recent versions as well(this relates to reclaiming memory that is no longer needed) so making sure you are on 1.3 is a good idea as well.

I would expect ADHD would be a major problem because you are sitting in a cockpit with great visibility while passing a lot of interesting stuff(clouds, rivers, lakes, cities, buildings, birds, other planes, etc) and you must remain focused on piloting pretty much at all times or risk getting into an unrecoverable situation where you and any passengers will probably die(possibly taking out another air or land vehicle at the same time and killing even more people) I do not know the requirements with regards to previous conditions, but if there are such limitations it is probably due to the the possibility of a recurrence.

Those are not the ones posting with these problems, and even if every other post started with 'kerbalism is not compatible with MKS,' there would still be some few who still post asking about it. At best putting a note about 'Kerbalism changes core functionalities such that MKS will no longer work' on the first post will only reduce and not eliminate those asking about it. It is just a question of at what point is the effort spent on keeping people from making those same mistakes better put to other purposes due to diminishing returns.

hopefully not for very long, as there supplies are being produced(although if some of the kerbals are greedy and do not share, I could see some going tourist while others are perfectly happy)

That is probably an issue where the ship with hungry Kerbals docks with a 'superior' vessel, and as such the kerbal vessel becomes a component of the other vessel. Much like transferring kerbals to a new vessel without bothering to space-walk. Kind of makes me wonder if you were to have a vessel with hungry kerbals, remove all kerbals from the vessel, then put them back in(possibly doing a scene switch first), would they re-set their starvation timer?

I believe Ground Construction(or making something similar) was a prerequisite because he wanted base modules that were of a size that is infeasible to launch. So no reason he could not start including larger structures in his next release, if he has time to work on them.(I think I even remember some potential models being shown at one point)

Plenty of space in there for an earth-sized planet once they get their detection sensitive enough to see if one is actually there...

You should have a R&D button on the toolbar, click that and the last clicked part will show up in the upgrade window.(you may need to add a part to the work area to be able to do research on it, but I do not think it even needs to be part of a vessel, just the last part you drug around on the screen.

I tried enabling gimbal to help with to an unbalanced load I was not aware of until after I lifted off from the Mun. It only worked within one degree of freedom, and once it just flopped around wildly within that arc. I also remember seeing the one degree of freedom problem in 1.2 which is why I always disable the gimbal. I have not yet tried adding the update patch to see if that fixes the issue.

If you turn off the engine gimble, you can use the lightbulb from the most recent Atmoic Age release without problems in 1.2.2 or 1.3(the gimble can go wonky, but everything else works just fine)

If your hab time if 50+ years, then timers stop and it is listed as 'indefinite' for all kerbals at that base. At that point I think the only benefit of using colony supplies in hab modules is to let you use Kerbal Reproduction. Except it is the EVA'd kerbal that needs the material kits, not the craft, so if they do not have access to the kits(local resources), they cannot expand the module. For specific child parts(mostly collapsed ranger modules, I think) the mass gets moved to the parent with 'mass transfer' enabled, but I am pretty sure that aerodynamics are not ignored for those parts. I believe that there is a specific attribute that indicates if a part can be affected by Mass Transfer on it's parent, meaning that it will mostly affect USI parts.

Sorry, you said Pioneer module previously. I was referring to the Duna, Tundra(2.5) and Tundra(3.75) Kolonization modules. I think he larger ones require less Colony Supplies per kerbal that they service. The main reasons for having a kolonization module would be if you are space restrained(can't fit/carry enough hab-space/multipliers to get to 50yrs) or you want kerbal reproduction(a bonus feature of hab modules that you can turn on)

I think kolonization modules are more efficient as far as colony supplies used per kerbal(if you have enough kerbals to use its full capacity).

Several modules require material kits to inflate, those need to be inflated by a kerbal on EVA. examples: Ranger workshop, inflatable hab-ring Inflatable without material kits(can be done from within the vessel): Ranger storage module, inflatable 'hut' (forget the name)

Logistics + pilot is only needed for pulls, mining stations are fine with either an empty logistics module or one of the unmanned refineries that were added recently, either option will provide push-only functionality.

That depends on how long the kerbal has been a tourist(ie without whatever made them a tourist) from : https://github.com/UmbraSpaceIndustries/MKS/wiki/Functions-(Med-Bay-and-Colony-Supplies) I believe that means that if you have a single tourist in a 3.75m med-bay they should recover after approximately one hour of treatment for every two days they were a tourist. I'm pretty sure that you need a scientist on board as well(possibly needs to be in the med-bay, not sure if they will take part of the time multiplier). Colonization modules will affect all kerbals in the craft, if there are enough active hab modules, to cover all kerbals on board, then none of their hab timers will count down so long as the hab modules are active and supplied.(if you do not have enough modules, I think the timers are all slowed down by the appropriate percentage)