Terwin

MMA would be an awful ting to try and convert to zero-g: effective striking would be almost impossible, and attempting to maneuver would be iffy at best. Something like ballet or gymnastics might work much better. A zero-g ballet or gymnastics exhibition would get people thinking about grace and artistry in relation to space, as opposed to thinking about blood and death in space. Imagine a small troupe of acrobats performing in zero g similar to a group of trapeze artists but without all the swinging back and forth between stunts, using the wall/ceiling/floor along with some carefully placed poles or handles. Could easily become part of the attractions at a space-hotel.('Like no show on earth!').

The ISS is a one-off government funded research station that is more of an international partnership than a research station. If someone wanted to make a much more cost-efficient space station, it should not be too hard to do so. The cost per person in space is also a factor of tradition over need. With an easier to resupply station, built and resupplied by starship, it need not be overly expensive, and much of the monitoring done right now could cover additional stations with little or no extra cost.(monitoring and emergency readiness for one station is not really cheaper than emergency readiness for half a dozen stations) The ore people we get into space, the more experience we have working there, the lower the cost per person, and the safer/more reliable things will get. in short, if you have the only car in the county, you need to retain your own mechanic, but if you live in a city with 10,000 cars, you just hire a mechanic when you need one.

Unless it is an issue of either volume, or the easiest way to have an attach-point for the small-sats was to re-purpose a couple of starlink attach points...

I could see a rocket sleeve which reinforces on the arm and is discarded in the launch tube as part of the plan, but I don't see a way to discard such a sleeve without tearing off the skin of the rocket unless said rocket was floating in a pool of liquid mercury(which would require good insulation from any cryogenic fuels)

I have difficulty believing the structural reinforcement to handle 10,000g of lateral force will be worth it for what, roughly 1/5 of the orbital dv requirement? According to Wiki, 1.3-1.8km/s roughly cancels out the gravitational and drag losses from a launch, so you still need the ~8km/s dv to get to orbital velocity. (and you can get away with a lower thrust engine if you start your horizontal thrust as soon as you are out of the launch tube as opposed to waiting until you are near the peak of your arc.)

I believe they are generated from your game seed(the same thing that determines the distribution of ore) combined with some configuration files(less water on the Mun, and more water on Lathe for example). I am not sure if such files are required or not for planet packs, but I suspect if they are, it seems likely that someone else has already tossed RD a pull request to add them in. I do not believe such a thing exists at this time.

Gas giants and brown dwarfs are much more numerous and much less hostile when it comes to fuel skimming(Primarily H2, so good for reaction mass), although I would not be surprised if stars were used as a substitute to avoid needing to make planets that can noly be used for refueling.

No vessel exists when outside of the physics simulation range. Since the introduction of ISRU, KSP has a 'catch-up' mechanic that will simulate the time since the vessel was last simulated in 6 hour chunks. MKS uses this core mechanic to handle all 'offline' processing. As such, you need to stop by your drilling platforms from time to time to catch them up. There are some mods(such as Kerbalism) which have an actual 'offline' mechanic, but as this is generally done as a replacement for the stock mechanic, they are not compatible with MKS(with behaviors ranging from 'you no longer get anything when offline' to 'MKS is reduced to a set of parts that do nothing but spam the logs with error messages') There is a system being worked on(and greatly anticipated) by RoverDude called W.O.L.F. which has a parallel mechanic and is intended to handle many of the logistics difficulties in MKS(offline production, automated interplanetary transfers, Kraken attacks on large mining bases, etc) and it was suggested that that will be included in the MKS update to 1.9, but it seems that RoverDude has been busy and it has not yet been released.

There is good reason that there are not many hard sci-fi stories in space. even with mostly-hard sci-fi, one of the first things to get tossed is realistic propulsion. It does not make for a lot of suspense when you must follow the highly detailed mission plan within very narrow margins or else you will never get there (or home) alive.

You really need to define what this 'dirt' is made of. Moon dirt(lots of silica and Al) is very different from mars dirt(basalt, so mostly calcium and iron) which is very different from earth dirt(lots of carbon and silica) which is is very different from Pluto 'dirt'(mostly frozen gases). The grain size, grain shape and most importantly gamma ray absorption will all vary wildly from each other. Using unrefined dirt for a rocket propellant is sort of like trying to fuel a steam engine using unspecified 'fuel'(could be nitroglycerine one day, and damp wood the next day, followed by gun cotton the third day and black powder on the fourth day, liquid hydrogen on the fifth day and liquid methane on the sixth day, then coal on the seventh day, and you don't know what it is or what it will be, as everything comes in 10kg boxes that you just toss into the burner). The value of using water/ice is that it is very easy to refine(melt it and let the gasses escape while letting solids settle), the value of air is that it is easy to collect(when present). The value of using unrefined 'dirt' is the betting pool on how the rocket will explode when the 'propellant' is heated.

To the best of my understanding, the only way USI-LS can prevent a Kerbal from EVA is if it makes them a tourist and then the game prevents the tourist Kerbal from eva. As this relies on the game mechanic for tourist EVAs, the only way I can see this happening is if you have no life support grace period(default is 2 weeks), and not enough recycling/supply generation for the number of kerbals you have on board, causing them to rapidly transition back and forth between active and inactive crew. If this is the scenario you are encountering, I would recommend setting the LS grace period to a minimum of 1 day to prevent this issue. If your grace period is already 1 day or longer and you have ample supplies and recycling, I would suggest copying your save into a fresh install with only USI-LS and see if you can still replicate the issue. If you can then it would be reasonable to post the save game file and a description on how to reliably reproduce the bug(if possible) in a bug report on the USI-LS github. Admittedly, I have not looked at the code and generally only use the 'become tourists when out of LS' difficulty, so there may be other no-eva mechanics that I am not aware of.

If you watch the show about the new sarcophagus for Chernobyl, they mention that structural metals need to be painted on a regular basis, even when they will not be exposed to the elements, or they will degrade. I would be surprised if pusher-plate hydraulics would not need to be in a protected environment with regular maintenance and recovery/replacement of lost working fluids. Thus far we have some one-shot proof of concept tests using chemical explosives and a bunch of math suggesting that it works in theory. Getting it to work in practice may be a whole different issue.(much like nano-tubes can, in theory, be used to make a space elevator, but in practice, we have neither adequate materials nor even elevators which could be used even if we had the ribbon in place)

That is part of the Global Construction mod(previously ground construction):

While development is ongoing for new parts and features, I am not aware of any additional planning aids that are expected to be incorporated into the mod. I believe there are some external tools(and possibly a mod) that can help with this, but if you prefer integrated aids, know that RoverDude accepts Pull Requests.

The classic Orion will blow itself up in an atmosphere due to the atmospheric over-pressure wave that can go around the pusher plate and crush critical components, not to mention the atmosphere causing the sheet of metal being sprayed at the pusher plate being disturbed by atmospheric effects. (the first bomb does not take the Orion super-sonic, so that blast-wave *will* engulf the craft in a fireball and over-pressure wave if in an atmosphere. The pusher-plate only works as a shadow-shield if there is nothing else around to carry/reflect the wasted nuclear energy) While a nuclear pusher-plate looks like a great idea for deep space, I am trying to convince @Spacescifi that an antimatter fueled pusher-plate surface-to-orbit design is unneeded, incredibly wasteful, and will probably irradiate your launch site. Chemical Rockets benefit tremendously from increasing the scale of the vessel. While a chemical rocket will be larger than a pusher-plate design with a similar payload, I am not aware of anything that would prevent a chemical launch vehicle for any payload that could be handled by a pusher-plate design. And if you are using antimatter for the pusher-plate fuel, Chemical will be cheaper and probably safer. Rockets need to be large enough for Steel to make sense, see Starship and Super-heavy for rockets finally getting large enough that steel makes sense over aluminum and composites. Pusher-plate designs use steel because they are large enough for it to make sense, and any chemical rocket made to deliver the same payload to orbit will be large enough to warrant similar materials. Surface to orbit has lots of issues for Orion, and is well within the capabilities of chemical rockets. While Orion may be the only option for a rapid transit to Pluto, it is a sub-standard option for reaching orbit, and an expensive calamity waiting to happen when you power it with anti-matter for a surface-launch.

The big risk of making bigger rockets is the lack of cost-effective payloads. If you have lots of large payloads you want to launch into orbit, then it is cheaper, easier, and less cataclysmic to just build a huge rocket to launch it as opposed to a pusher-plate design. Designing and building a single use chemical rocket with the same orbital payload capacity as your antimatter-pusher-plate will cost less than just manufacturing the antimatter for your pusher-plate design. When it comes to rockets in general(and chemical rockets in particular) bigger is better. Tank volume grows with the 3rd power and tank surface only grows with the second power, so the larger the rocket, the higher the payload fraction. Follow the star-ship model(lots of redundant engines) and bigger also becomes more reliable. The only thing a pusher-plate launch vehicle does better than a chemical launch vehicle of the same payload capacity is to make your origin uninhabitable. And chemical rockets can be made with greater maximum payload capacity then a pusher-plate using the same materials, because a chemical rocket puts less stress on the materials than a pusher-plate will. All you need is someone with a mission and the funds to pay for it, and you can launch an air-craft carrier into orbit on a chemical rocket even easier than you could with a pusher-plate.

Using a pusher-plate with antimatter is about as smart as throwing packages of c-4 out the back of a chemical rocket. It only makes sense for nuclear bombs because: 1) the cost and weight of a nuclear bomb is about the same regardless of total energy output 2) nuclear bombs have a minimum effective size that is too large to be contained by current materials(at least light enough materials to use on a rocket) Neither of these is true for antimatter, so a pusher-plate design is highly unlikely to be in any way efficient for any antimatter powered rocket.

It may just be fire codes: any structure intended to hold people needs to have multiple avenues of escape in case of fire. I think there are stairs, and the elevator, but I also don't think Elevators count as an avenue of escape in the case of a fire, so they have zip-lines.

I don't think you can use CKAN with older versions of KSP. It will get the latest version of each mod and apply those on your current KSP, meaning you are using a MKS version built for 1.8 or 1.9 on 1.3.1 which would have compatibility problems. If you want to play on an older version on KSP, you probably need to go to RoverDude's git repository and find the MKS version released for 1.3.1 and install that. Looking in a 1.3.1 instance I was using 3 years ago, I had MKS 0.53.2 installed (from 2017.03.06; 0.53.x looks like the 1.3.1 versions)

Instructions for getting/posting your logs are here: I would be helpful if you also indicated: 1) what other mods do you have installed (some have conflicts) 2) How did you install the mods(manual, CKAN, other? CKAN will occasionally mess up, so uninstall/reinstall of the mod may help) 3) what steps have you take thus far to allieviate the issue(uninstall/reinstall, fresh copy of KSP with MKS as the only mod, etc)

In most cases it will be Fig 2 over the short term, but if one side of the satellite is heavier than the other, then it will slowly change to Fig 1. The relative scale of the difference will determine how quicly that happens. For example, the moon is unbalanced, and so it is Fig 1, with one side always facing the earth. This is because the heavier side will be pulled more strongly than the lighter side when it is not facing either directly towards or directly away form the planet, causing rotation to either speed up or slow down until the rotation exactly matches the orbital period.

No black hole is stable without a constant in-flux of matter. Smaller ones evaporate more quickly, but every single black hole that is not growing is shrinking. https://en.wikipedia.org/wiki/Hawking_radiation

Dependency management is a hard problem because it relates to handling dependencies on 3rd party libraries that will usually have their own dependencies, generally version specific dependencies that may conflict with the dependencies of other libraries you wish to use. But I fail to see how making a feature optional has anything to do with needing additional 3rd party libraries which may have conflicting dependencies with libraries already in use. Also, with encapsulation, you just make a best guess as to what you will need, and any time you need to add new stuff you increment the version of the api. (removing stuff or changing stuff that may break existing code are generally higher-order version increments). No need for perfect prediction, just a 'this is what we need now'. You just use a factory class to load up the appropriate version based on what is wanted (Like calling DataLayerFacory to get either PostgresDataLayer or OracleDataLayer depending on which database you are using for this deployment)

If I remember correctly, the problem comes from the maximum possible heat transfer from a part. Radiators do not look at what is needed, but they look at what is the maximum that a part can use. That amount is deducted from what is available, then it checks the next part. Once all the radiator capacity is allocated, everything else is treated as not having any radiators. So even if your reactor is only running at 5% and producing minimal heat, radiators are allocated to it as if it were at maximum heat and needs to use all of its maximum heat transfer, leaving nothing left for your drills. As colonization bonuses can increase the production(including heat production) by > 500%, a lot of MKS parts(including reactors and drills) have a maximum heat transfer that will allow them to operate at that rate without exploding. Unfortunately, that means that if you are using whole-ship radiators(the ones that extend in stock), you will need to have several times as much radiator as you actually need when you have a low colonization multiplier so that they can still work with a high one. I think RoverDude had the max heat transfer really high before, but after discovering this quirk of the game, reduced it to a more moderate level(this is the 'fix' that was made), but that level is still several times the base need. Does that make things clear?

So long as you have some distance beween your drills and PDU(ie PDU is not parent or attached to parent of drills) you can generally get past this sort of wonkyness by using fixed radiators attached to the parent of the drills. I think the issue was reduced but could not be eliminated due a combination of how radiators work in KSP and MKS colonization bonuses. If you are landed, you can also use the MKS heat-sink part to provide a lot of cooling without bulky radiators.