Aelfhe1m

Workshop requires that the KIS container be part of the same vessel as the workshop. If you attached the K&K baseplate to the ground near your vessel then attached the MKS Kontainer to that then that is not part of the same vessel as far as KSP is concerned (easily testable - can you use the [ ] keys to switch between the workshop vessel and the Kontainer). As far as I can see KPBS has no special handling for workshops but simply includes the OSE module into one of its parts. Therefore the K&K OSE Workshop part should not behave any differently (other than configured rates/efficiency) than the standard OSE Workshop part. A test vehicle I made with a K&K OSE Workshop directly attached to a 3.5m MKS Kontainer worked correctly.

https://github.com/UmbraSpaceIndustries/MKS/wiki/Functions-(Med-Bay-and-Colony-Supplies)

Nah, it's a subliminal message to visit Trinidad and Tobago or maybe Holland? or join the rebels? Or be a pirate?

@aquilux Check your log files to see the errors: There's a missing / in #$/mass$. Also you're reusing the same variable names in the decel block so you should use @ (modify not create) at the beginning of the lines where your setting them to mass With those two sets of edits it will run error free.

You could do it like this (note the first set of liquid boosters stage before the SRBs) but I'd prioritise researching specialized construction first to get the standard clamp-o-trons then assemble something in orbit. Also comms are going to be an issue beyond KSOI until you research better antennae. Edit: Oh and I completely agree with @Helmetman about mission planning and smaller payloads rather than just throwing raw delta-V at the problem. For example a mission to (loose elliptical) Eve orbit takes less delta-V than a Mun landing if you use an optimal transfer window.

No 1.2.1 is a hotfix only for compatibility with changes in KIS 1.6+. Enceos' models will be in the next version.

@aquilux KSP uses US spelling for "Oxidizer" (be careful though a few mod authors do not use US spelling for their introduced nodes, keys and names so always check the original) The errors in your commented out section are because you need to use the #$variablename$ syntax everywhere you use a variable on the right hand side of an equation e.g. engineDecelerationSpeed = #$MATHa$

My apologies @IgorZ. I thought the patch that I applied to EVApickup was the reason that this works: But after testing with just KIS (and MM) I see that it didn't extend the range. Now I wonder just which of the many mods I've got in that save is making this possible.

Very good point as increasing a value by 10% increases any other value that's proportional to its cube by 33%!

The first says: The second says: Or to put it more compactly. The first is only exclude SolidFuel and the second is only include Oxidizer. In what circumstance are you seeing it fail? I just did a test and both work equally well detecting an LV-T45.

https://www.reddit.com/r/KerbalSpaceProgram/comments/1gkwjt/the_full_story_of_the_mun_landing_gif/?st=j7tzryg1&sh=12a80de9

@KiloMike The problem may be the sheer size of the 5m Kontainer. In order to access the inventory your Kerbal must be close enough to the kontainer's centre of mass. Try carefully positioning your EVA Kerbal as close to the centre of one of the long faces on the kontainer as you can get them. You can also mod the interaction range to allow the Kerbal to access inventories from slightly further away using a MM patch:

Well you've got two copies of the FireSpitter DLL and some of your mods are slightly out of date but I don't see any that were compiled for 1.2 . Other than that the crash occurs immediately after the log entry: Now it could be a problem with that part or (more likely) with the next step in the loading process which is to begin compiling IVAs. Judging by your GameData screenshot, the first mod with IVAs would be Mk2Expansion. Perhaps start by checking you've got the latest version of that? On a more general note I'd recommend making a copy of KSP outside of the Steam folder for modding. Steam's auto-updates and some of Window's protectiveness about the "Program Files" directories can sometimes cause issues.

You could try the tourism plus mod.

A point on the Earth's surface near the equator has a rotational speed of approximately 460 m/s. So if you re-enter prograde (parallel to the equator) with an orbital velocity v your velocity relative to the surface will be (v - 460) m/s but if you re-enter retrograde from the same orbital velocity your surface relative velocity is (v + 460) m/s or 960 m/s faster. The atmosphere rotates at the same speed as the surface. From LEO your initial orbital speed is about 7.5 km/s so the difference between prograde and retrograde will be around 13%. A lunar return will have a higher orbital velocity at atmospheric interface but since the difference in surface velocities is fixed the percentage change between prograde and retrograde will be less (around 8-10%) but still significant.

Just delete the file GameData/BonVoyage/PluginData/BonVoyage/config.xml. It will get recreated with default settings next time you start the game.

Thanks @Three_Pounds I've merged the PR on GitHub and it will be included in the next released version (soonishTM)

Yep. Working with my test install now. Out of curiosity can you explain what the problem was?

@aquilux Yes you can use your own variables in MM. The code is mostly fine but each line that modifies a value (rather than declaring a new variable) should start with an @. You can then delete a temp variable after you're finished with it using !variablename = delete (the word delete can be anything but MM requires some value after the = sign). Depending on how complicated the arithmetic gets it can need to be split over multiple patches to make sure everything happens in the right order but that shouldn't be needed here.

won't work because :HAS doesn't support OR. If you only want it to affect liquid fuel engines then try using :HAS[@PROPELLANT[LiquidFuel]&@PROPELLANT[Oxidizer]]. Also watch out for bracketing. In both versions in your last snippet :HAS[@MODULE[ModuleEngine*] should not have an extra ] before the next :HAS clause because you want the next clause to apply to the found module not the part. http://anatid.github.io/XML-Documentation-for-the-KSP-API/class_module_engines.html#a0ea45fd55aaf2293a1f2d48da4f23287 High values = faster throttling, low values = slower throttling ModuleEnginesFX inherits from ModuleEngines so all the base ModuleEngines fields should continue to have effect in MEFX.

Just did a test with a clean version of KSP 1.3 and KIS 1.5 and it was reporting no update. Looking in the log it had read the remote v.1.7 file but then decided it didn't represent an update. Not sure what's going on here. Edit: repeated with KIS 1.6 - same result. Also tried without full version of AVC installed but just MiniAVC made no difference.

That's why I put a wild card in the edit part as well.

I think both ModuleEngines and ModuleEnginesFX behave the same for engine spooling so it shouldn't matter.

@aquilux Most of the Squad SRBs already have a built in (fast) response time so make sure you're not seeing their default values. Second to test for PROPELLANT you need to use @ because it's a node (or use ! for not and test against solid fuel). Third - nesting of has clauses is significant - you want the 2nd and third clauses to apply to the module so they need to be inside the first has clause's closing brackets. Fourth - I just realised that not all the Squad engines use ModuleEnginesFX (e.g. LV-T45) so the module name will need to be wildcarded. Oh and finally note that higher values of acceleration/deceleration speed make the engines spool faster (they go from no thrust to full thrust quicker). Not sure if this is your intent but it means heavier engines will respond quicker using the current values.

@Space_Coyote On the thermal overlay red is normal temperature for most parts (it's when they start to go yellow or white you need to worry). Try going into the ALT+F12 dialog physics => thermal and enabling the option to show temperature details in the action menus then right clicking on the various parts. They'll likely all be around 270-300K (0 - 30°C). The Squad crew parts don't show the same thermal overlays as the non-crewed parts for some reason.