Aelfhe1m

There is an absolute limit to how big you can make vessels in KSP (the physics range although they tend to get very unstable before that is reached). Mega structures like HALO rings or space elevators are not possible.

Classic mortar board...

@Jesusthebird Your scenarios are already in the mod (the "no size" option in the mod filter is for radial attached parts). Watch the video in the OP starting from about the 10 minute point.

Several aircraft related autopilot features were added in a dev build a while back. These include most of the core features including fully autonomous landing at KSC or Island runway. I've not used them much myself being principally a rocket person but I did do some rudimentary testing with a couple of basic jets and a simple space plane. Here's a screenshot I took by accident with the GUI still enabled that shows the aircraft autopilot and autoland panels on the left (sorry for the overlap with SmartASS but as I said I didn't really mean to take this).

@Hs.Panda One word of warning. You MUST have a crew member in a seat when the vessel is launched or any inventory that was added to that seat will be lost. Something to watch out for with multi-seat vehicles especially.

Yes, that's probably easiest and cleanest for a simple patch like this but for a longer/more complicated patch there would be a lot of code duplication

The lack of OR in HAS requires a bit of a work around. For example: // mark things we don't want to patch @PART[*]:HAS[!MODULE[IFI_Extreme],!MODULE[IFI_Improved],!MODULE[IFI_Advanced]] { IFIModuleFound = true } // do the patch @PART[*]:HAS[~IFIModuleFound[]] { !IFI_Tech = none } // remove marker @PART[*] { !IFIModuleFound = delete } Relies on the fact that A OR B OR C is the same as NOT(NOT(A) AND NOT(B) AND NOT(C))

@TriggerAu Nice to hear you might have some time to get back to this mod soon. I've just pushed a PR to develop of some code I've been tinkering with to support non-standard calendars for my own game play. It's a bit rough around the edges but mostly works.

@sardia Click the difficulty options button at the top of the settings window. This will give you access to most of the same settings that were available during game start.

The parts that affect KIS/KAS carry are: Part Range Extra mass PAL Manipulator Claw 12m 10t PAL Magnetic Coupler 12m 10t PAL Magnetic Manipulator 10m 6t PAL Crane 16m 6t PAL Forklift 6m 22t

@Bersagliere81 The wrench only allows parts to be surface attached. To node attach parts you need the electric screwdriver. Many parts including the Stayputnik probe can't be surface attached so...

It depends on your launchers staging set-up, especially the TWR and burn-time per stage. I've been using Rescale 6.4x for my latest game and for high TWR fast-to-orbit launchers I use 40% turn shape and 90km turn end altitude. Launchers with low TWR final stages need to be lofted more typically with a 50% or 55% turn shape and 100km turn end altitude. I'll also monitor the time to apoapsis before and during the final stage and may need to adjust final flight path angle (possibly several times) to keep the time within a suitable range. dV to a 150 km to 200 km parking orbit ranges from about 6700 m/s to > 8000 m/s depending on specific set-up. I tend to optimise for price rather than lowest dV. EDIT: Note I'm playing with SMURFF and stock aero (no FAR).

Are you using Contract Configurator for the contract manager? If so then: targetBody = AllBodies().Where(cb => !cb.IsHomeWorld()).Random() That will select a random body that can be ANYTHING except the home world (suns, planets, moons, sigma binary barycentres etc). There are a lot of options in the celestial body expressions to filter it further - see wiki.

https://github.com/UmbraSpaceIndustries/MKS/wiki/Resources

You need an extra HAS after the node name: @PART[*]:HAS[@MODEL:HAS[~model[SSTU/Assets/EmptyProxyModel]]] { %Test1 = 1 } NOTE: You'll need a different filter to catch parts that don't have any MODEL node at all

RESOURCE nodes contain 'name', 'amount' and 'maxAmount' not 'resourceName' and 'ratio' (those look more like INPUT_RESOURCE and OUTPUT_RESOURCE from inside a converter module). You need to calculate how much each unit of supplies should be equivalent to in Food, Water, Oxygen etc. then you can do something like this (not tested):

@Electrocutor Out of curiosity I dropped your stock retextures into a heavily modded game. There seems to be a clash with some mod parts which reuse stock models with their own texturing that prevents some parts from loading. There were only 7 instances of this problem across the MANY parts in the game - mostly to do with drills. Example: The Karbonite drill contains this section in its part config: MODEL { model = Squad/Parts/Resources/RadialDrill/TriBitDrill texture = TriBitDrill, UmbraSpaceIndustries/KarbonitePlus/Assets/TriBitDrill_GY scale = 2,2,2 } For the moment I can just comment out the model lines in your config that clash (or not use your mod until it's finished) but I felt it was something you should be aware of.

Untested but this ModuleManager patch should work: @PART[ScienceBox]:NEEDS[TweakScale] { MODULE { name = TweakScale type = stack defaultScale = 0.625 } }

Which anthem would that be? "Wilhelmus" perhaps? Or one of the many other countries with red, white and blue flags?

@Wragie I can't see any errors specific to KIS in the log at a glance the relevant snippet from the log reads: which is what I'd expect from adding a container to a test vessel and opening and closing the inventory screens and then exiting the editor. But I had to snip out hundreds of exceptions being generated by Kerbal Alarm Clock in between those log entries because you haven't updated to the 1.3.0 compatible version. It's possible the sheer number of exceptions was interfering with KIS somehow. Try starting by upgrading to the correct KAC version. Other mods are also throwing exceptions when checking for dependencies (e.g. BARIS and DSEV need WildBlueTools)

Those exceptions are related to connected living space. Are you using the latest (linuxgurugamer) release of that? If so try this fix:

OSE Workshop defines part recipes based on a global config, extras for certain resources (ablator and solid rocket fuel in default build) and an optional per part config override. (Mods can also modify any of the recipes or add extras via MM). The default configs add part recipes that will require exotic minerals for any parts that have ModuleScienceExperiment or ModuleCommand. (ModuleScienceExperiment also adds a requirement for rare metals, as does ModuleEnginesFX). It's possible that you would see a requirement change if the part you were printing had an update that added one of those modules to its config. You can see what recipes apply to your particular modded build by searching ModuleManager.ConfigCache for OSE_DefaultRecipe, OSE_ResourceRecipe or OSE_PartRecipe or by searching your GameData folder for any patches that contain those node names.

Just add a block like this to your config beneath the folders section for each suit: // use the name of the suit folder here PilotRedSuit { suit_EvaGround_NoAtmo = 2 // default = 1 helmet_EvaGround_NoAtmo = 2 // default = 1 // optional visor_EvaGround_Atmo = 2 // default = 3 } What the numbers mean: https://github.com/HaArLiNsH/TextureReplacerReplaced/blob/master/GameData/TextureReplacerReplaced/%40Default.cfg#L435-L440

No. Although parts modified by MM will affect any craft built from those parts.

The core samples experiment result isn't the same thing as the core samples resource needed by the metallurgy analysis experiment. Use a pathfinder geology lab to generate core samples (it can also run the analysis experiment). Core samples are made from research kits so make sure to have enough.