Johould

For that you are sort of out of luck. Previous discussion in the thread says you can complete the contract only if the current stock prediction matches the target orbit.

That would be correct if you have no scanning data from Duna. The biome colors from the key at the bottom will only show up if you have biome data from running the multispectral scanner. Other colors might come from the resource overlay or SAR scan data.

After using the SCANsat settings window to clear the stock data, I didn't see that log message from changing the threshold or changing scenes, and didn't see the stock version of the flag set in my save. Checking the small map as you suggested shows 100% coverage. It wasn't much trouble to hand-edit the save to set the stock "PLANET_SCAN_DATA" flag. I'll let you know if I do further testing.

I it tracked down to the latest USITools not even trying to set the "bays" bonus. After fixing that the MKS Explainer info seems good.

I've been happily using SCANSat with stock scanning disabled, I just realized I want the tracking station's stock resource information to be populated. Here is somebody's screenshot of what I'm talking about. I don't care about seeing the overlay map, just the percentages and pie chart shown under that button: Thanks, I'll check on the small map. I didn't notice that coverage information. I'll have to check if I get log lines like that (current log doesn't have them, but I don't think I reset the threshold last game and don't have time to fire up KSP right now). I don't think I even see the button for trying to perform a stock scan if I have stock scanning disabled. Your other answer about save format is interesting, but I'm pretty sure what I am looking for is only controlled by the stock `PLANET_SCAN_DATA` nodes. Can you confirm that the stock data is intended to show up in the save if I can see that "Conducting stock orbital resourced scan..."?

Is meeting the "Stock Scan Threshold" supposed to set the PLANET_SCAN_DATA? I have several bodies I'm pretty sure are 100% scanned (definitely enough to get science from the SCANSat analysis), but they didn't have that setting in the save file and didn't get resource information in the tracking station. Is the scan percentage shown in any SCANSat window? Should I see a message when the stock scan threshold is passed? I'm actually just interested in the overall "planetary abundance" numbers shown by the pie chart, if there's another way to view them (turns out the "sifting" mechanic in MKS is driven by those numbers rather local resource abundance at a base).

I see there are not explicit install instructions here, but you shouldn't do anything besides downloading the latest release from the links in the first post in this thread, and putting all the folders under GameData/ in the zip file into your KSP installation's GameData folder. From a fresh KSP that should give you everything from MKS, except the DIY kit is known to be broken. I haven't ever tried MKS without USI-LS, but it's supposed to work - and you should at least see the parts that don't have any life support functionality. (To have a nice game you probably want to install at least USI-LS, KAS+KIS, and the Ground Construction 2 beta). Please include logs if you still don't see the parts or the MKS categories in the VAB. (If are searching for parts by name just typing Tundra won't work, you should search for MKS or for 'Tundra' with the quotes).

Is there any way to configure switchable parts before building them? I didn't notice any options in the workshop UI. (In particular I got stuck with some Mk2 Expansion parts that use IFS to switch meshes along with the tank setup. MKS has many configurable parts too, but those can all be switched after construction).

There shouldn't be any folder named kolonization, and I don't know about any recent MKS hotfixes. The MKS colonization parts are all under "GameData/UmbraSpaceIndustries/MKS". What version of KSP are you using and what else do you have installed? I don't know what happens if you don't have any supply storage at all. Without testing I would guess they would show as "starving" but the starving time would never drop. If you have any storage it should automatically pull over some supplies. At 1.08 supplies/kerbal/day before recyclers even the tiny surface mount has more than enough space to keep a lone drill operator fed for 12 hours - constantly fed even during catch-up processing (also recyclers definitely do share in the same range as habs).

That's a bug. I guess they would both work? That goes away if you reconfigure in the field (I don't remember if changing in the VAB fixes anything). You can fix it by moving the "ModuleSwappableConverter" section in the part .cfg after the options it's supposed to control, maybe something to do with setting up the initial state. That's a bit strange because that file has been in the current order forever and used to work fine. I suppose something changed in USITools.

Strange, an MEU-100 it definitely lost the engineer skill bonus when I separated my test rover. What did you test? I just tested a little two-part rover on the runway, with drills and a non-engineer kerbal on one side of the separator, and the engineer on the other. Drill load was 85% with them docked (3-star engineer), only 5% undocked.

Some kind of number in the VAB would be nice, but it can't be fully accurate when the output mix depends on the planet. It looks like both sifters are currently set up to produce a maximum of 1 unit of resources per 1 unit of resource lode, and 0.25 units per 1 unit of dirt. Each output resource is produced at that rate times its planetary abundance divided by the sum of planetary abundance of all resources except the input of the converter (not sure if you get Dirt output from processing a resource lode). Looks like it's just by units rather than mass balance. The planetary abundance numbers should be available in the tracking station (may not be populated if you use SCANSat, depending on "stock" settings). Resources that don't meet the minimum abundance still count towards the "sum of planetary abundance of all resources except ...". Also, random unused resources from other mods will also add to the total, if you have any (somehow I have "Alumina and Monazzite", which seem to be added by CRP despite nothing using them). Edit: Alumina+Monazzite make up 2/5th of the non-dirt resource abundance on my Mun. No wonder sifting for gypsum for life support isn't going as well as expected. I hope I can remove those resources.

I thought their main point was that when the Ляпуно́в exponent costs you a bit in a relatively short time neither symplecticity nor high order are worth anything compared to higher precision numbers. Lower-order symplectic methods seemed to be a suggestions specifically for the case where you decide you don't actually care about accurate trajectories and just want statistical behavior (or go to leapfrog in quadruple precision). I don't see why getting physically reasonable samples out of an integrator would imply that the samples can be interpolated to give physically reasonable trajectories - a symplectic integrator might preserve energy just fine with a sample every two or three orbits. I haven't see that explicitly addressed in integrator designs, but it seems like a similar interpolation problem from going to ~10 minute steps in the integration of celestials to a per-frame updates on a vessel. 2.5 years : 10 minutes is a bit smaller ratio than 10 minutes : 1/60 sec. I would guess an interpolation scheme could probably be extracted from the way a multiscale integrator includes the effect of the slow-moving variables when making the faster updates, if an integrator otherwise looked good.

Click (left?) directly on the hatch, when the the tooltip "crew hatch" is showing.

Why don't you? Sometimes I have been missing the crew portrait for a Kerbal in a DERP and had trouble getting them out, but when I looked that up I found that you can also click directly on a crew hatch to get EVA/Transfer buttons for all the Kerbals in there. (If you use CLS the DERP pod isn't internally connected to anything, but then I don't think you could get a tourist into the pod in the first place).

"Separator" is just what the drills call the slots where you can change what it digs up. The larger drills have more than one, then you can have one drill digging up several different resources at once, or set multiple separators to the same resource to get more of that resource. Other switchable things call the slots "Bay" or "Converter" or just "Config".

The MEU-100A doesn't need any crew to run at 100% load, while the MEU-100 depends on the level of the best Engineer or Miner on the vessel - just one can boost all drills. The MEU-100 only runs at 5% without any appropriate crew, 25% if the highest level is zero, and another +20% for each star afterward. However fast or slow they are running, either drill uses the same amount of EC per unit of resource harvested. These numbers are before from Kolonization bonuses or thermal limits, which affect both parts identically. The MEU-100A's "100%" is only about 65% as fast as "100%" on the MEU-100, so a 3-star Kerbal in the crew is enough for each MEU-100 drill to product just as much as a MEU-100A. The MEU-100A is also 40% heavier, so by productivity per ton of drills a 2-star Kerbal is almost enough for the MEU-100 to catch up (within 5%). To change the settings from EVA you need an Engineer or Mechanic (these two jobs are also the only ones that can use KAS tools to attach parts), plus it costs the amount of specialized parts, material kits, and EC listed in the VAB. This, plus the whole UI for setting up the separators in the VAB is shared any MKS part that lets you configure the function. It's a bit confusing but at least it applies to everything once you learn it. (the button with the "=>" arrow change the configuration of the part - this is when you pay the resource cost. The "Next" and "Prev" buttons change the selection to the right of the arrow without actually changing the part. In the VAB it's free to just cycle with the first button, but "Next" and "Prev" are worthwhile when changing the setup in the field). I haven't switched drills much, but now I see it only costs 20kgs of consumables to reconfigure a MEU-100 (1% of the drill mass), so maybe it is the most efficient option sometimes. "pull in all resources" is an oblique reference to harvesting Dirt and then running it through a sifter. The sifter part will do exactly what you expected to see from the drill, pushing a little bit of every resource into available tanks (and just dumping the rest). The amounts are proportional to overall planetary abundance.

How do you test integrators? Looking for a bit of background on integrators I found this article, which included a point I hadn't seen before: Most notionally symplectic integration schemes are only exactly symplectic in infinite precision, and otherwise have an error floor no better than random accumulation of roundoff errors (with an aside about "symplectic lattice" integrators), or far worse if rounoff errors are biased. That's only relevant if you want answers better than about your numeric precision times the square root of the number of timesteps. IAS15: A fast, adaptive, high-order integrator for gravitational dynamics, accurate to machine precision over a billion orbits Abstract: They designed an integrator around a non-symplectic scheme chosen so systematic error should be far below machine precision and then implemented it with much care to limiting roundoff error and avoiding biased roundoff. Without relying on a symplectic design, they felt free to include an adaptive stepsize and can support non-conservative forces like radiation pressure. Looks pretty interesting, but perhaps higher precision and longer timescales than you want? I also realized another thing while reading that, from their discussion of dynamic timesteps. If you need to set a timestep to get 100 or so samples per Mun orbit, that's already much smaller than it would take to get 100 timesteps per Moho orbit. I found a few papers on multiscale integrators, but it seems like using multiple timesteps for gravitational problems is still pretty experimental.

That shouldn't throw things off too badly compared to the dedicated hab parts. Most have at least 5 months of bonus hab time per crew capacity, unless they have a significant multiplier, or the Karibou's 0.24t "emergency shelter" at 1.2 months and 2 crew. For highest-tech bases, the Tundra Hab ring has 10 crew and almost 500 months bonus hab time. I haven't played with a lower science multiplier, but I haven't had too much trouble with the default time either. Have you considered letting hab time expire on the way home from Minmus? If not that might make the default settings manageable. If the hab penalty is on the default "grouchy" then fairly low technology is enough to safely return a grouchy "Tourist". Either any probe core to take over when it's close enough to Kerbin for the internal antenna to work, or just leave Minmus on a direct reentry trajectory (may require a heat shield, and don't forget to arm the chutes before the crew goes on "vacation"). If you build a separate lander and return capsule then the default setting give you 15 days of hab time, which should be plenty to arrive and science, though I'm not sure that saves mass unless you will be landing several times and have unlocked enough to refuel in orbit. Arriving in under 7 days takes a bit more ΔV than the cheapest Hohmann transfer but it shouldn't be too bad . I think a good Mun assist can get you to Minmus periapsis before 5 days with only a little more dV than needed to reach a low Mun flyby in the first place.

Great! I thought the Universal Storage 1 parts were lovely, but the old balance made them often uncompetitive even if I just wanted a wedge worth of some resource. The new models look even nicer.

Orbits have corners when zoomed in too far, like when a stellar orbit passes through a planetary SOI. It shouldn't be too expensive to put more points where needed or maybe to draw a smooth curve with shaders, but I haven't seen a mod like. Is this something mods can change?

The general idea is that more drag is tolerable on parts producing more lift. An option to highlight by lift/drag ratio might be helpful for tuning wings For reducing unnecessary drag I'm not sure what formula might be useful. Perhaps divide lift of a part by overall lift/drag ratio to get a "proportionate drag" and subtract it from the actual drag, so wings stand out less.

Very useful. The envelope view helped me greatly improve a design that turned out to just need some tiny adjustments to wing pitch. Something is definitely a bit strange with the pitch input graph - the AoA stable with zero input changed after adjusting only the authority limiter slider on the only pair of control surfaces active for pitch. (this was at the upper-right of the flight envelope, where pitch had gone unstable and the pitch input graph was a sawtooth, something like 0.4 up to say just below 0 AoA, large input down to say just above 0 AoA). For the ranges on the flight envelope graph, it would be nice to have the option to focus on a small area without increasing detail, for faster updates when trying to fine-tune a part. Computing the whole graph only takes a second or two, which is usually pretty nice, but adds up when trying tenth of a degree changes. Allowing a higher maximum speed would be useful to see more of performance with rockets on, and also to see the full air-breathing performance range of some mod parts like Mk2 Expansion's scramjet. I accidentally left the rockets enabled on one spaceplane before checking the flight envelope, and there was actually a relatively narrow corridor of altitudes with excess thrust as the speed went up to 2000m/s. Designs with nukes might need attention to aerodynamics for an especially long time after rockets are on. I'm not really sure how to use the lift and drag highlighting to improve a design. It seems like the most drag usually comes from the lifting surfaces, making it a bit hard to tell if a change is good from looking at the modes separately. Maybe a few more modes could usefully combine the information? Lift/Drag would probably be good for adjusting wings, some other formula could probably help pick out disproportionately draggy parts (drag/lift wouldn't help with lift-free parts. Maybe a straight offset to drag like subtracting lift divided by the airplane's overall L/D ratio).

I was missing the EVA portraits on any ship with an occupied HERP. Turns out it was already fixed but the fix didn't make it into the 0.11.0 release. There is already an issue saying that: https://github.com/BobPalmer/ExplorationPack/issues/146 The fix is just one line, a path in the IVA, so it was easy to make that change in my GameData.

A further oddity - the Ranger inflatable hab module shows both "Start Hab-Common" and "Start Hab-Quarters" buttons. Putting the "ModuleSwappableConverter" after everything it is supposed to swap somehow works around the problem.