Covert

...\Kerbal Space Program\Logs\ModuleManager\MMPatch.log shows what patches were applied and in what order. ...\Kerbal Space Program\GameData\ModuleManager.ConfigCache shows what the state of all the data items was after all patches were applied. Given those and some standard text searching tools (on Windows I like Agent Ransack) you can trace back where the content is coming from.

GT works for me in 1,8,1 without World Stabilizer GT fails to work with World Stabilizer After careful reading of World Stabilizer I have two things to try out when I get time to play again 1) World Stabilizer does not touch craft with Launch Clamps 2) World Stabilizer runs on newly commissioned (pre-launch) craft by default, but can be configured to NOT do so. My theory is that if you use launch clamps OR disable World Stabilizer from touching pre-launch craft - then hopefully it will get along with GT without issue. Will report back when I get a chance to try things out... Reporting Back: Gravity Turn works fine in 1.8.1 + It even works with World Stabilizer if you include Launch Clamps on your craft. World Stabilizer breaks Gravity Turn when it "picks up and nudges" a newly launched craft... So either include launch clamps or set the World Stabilizer config to skip newly launched craft.

My current proposal for a fix. This uses the same directory name as the mod for the timing clauses, moves the command crew clearing to after TacLifeSupport and avoids adding any extra SAS module node to the Near Future and expansion command pods that already have more advanced SAS included. After a quick check run the right result shows up in the Module.ConfigCache. @PART[*]:HAS[@MODULE[ModuleCommand],#CrewCapacity[>0],!MODULE[ModuleSAS]]:FOR[NCRC] { MODULE { name = ModuleSAS SASServiceLevel = 0 } } @PART[*]:HAS[@MODULE[ModuleCommand],#CrewCapacity[>0]]:LAST[NCRC] { @MODULE[ModuleCommand] { @minimumCrew = 0 } }

So there is a small issue from the latest patch. If you don't have TacLifesupport the AFTER[TacLifeSupport] condition cause the patch to be removed. So now the patch only works for users of TacLifeSupport. My fix was :FOR[TacZLifeSupportAfter] which means you still execute when TacLifeSupport is not in the install, but you are after TacLifeSupport due to the name ordering. (But still before all the zzz mods that really want to go last).

Bug repeats for me. Workaround once in the scene is to open the VEL settings panel and tap the Direction button. It makes the pink box show the forward direction for about 10 seconds and then disappear. Once it is cleared from the scene it stays gone until a reload, so you can get it out of the way during docking / landing / EVA maneuvers.

Just want to say thanks for the Righteous Work. MADLAB just pointed out two problems with my install while also teaching me something important to look for in the logs while when installing a new mod. I also fully support checking for "correct install locations" - even if your are knowledgeable it is all to possible to fumble finger an install into the wrong sub directory and not catch it until your game is mucked up.

Thanks for an awesome mod and the quick repair of initial compatibility issues. I like the look and restock plus adds some nice alternatives for craft early designs.

New RealChute.cfg +FAR.cfg is go from me.

@Dante80 - thanks for the additional debugging. Someone with code level access will have to peal another layer, but I suspect the parachute plugins are fighting over which drag cube to activate... Update: Added item to the issue list. Tested locally and conditioning removing the DRAG_CUBE elements in ReStock\Patches\Utility\restock-parachutes.cfg resolves the problem. Removing the drag cube by some other approach would work also. Update: The latest version of Restock/Compatibility/RealChute.cfg from the repository fixes this problem. So fix will likely be in the next release. Thanks to Nerta for the quick turnaround.

Working fine in my 1.8.1 install...

I tried adding Restock last night via CKAN and starting a new save. The aero drag on the newbie rockets was wildly off. (20m/s top speed vs 286m/s top speed for the same rocket in configuration without Restock). (Mark I capsule, parachute, decoupler, a few tanks and swivel) I have not had time to do any debugging so at this point I am just reporting what I see, not making a support request. Hopefully I have some play time this weekend and I can do enough debugging to actually report something with some actual investigation. (I want to check the computed drag boxes in different mod configs...) Has anyone else seen this issue? I have dozens of other mods so I have no idea what the interaction is at this point. Notes after further research: After comparing the before and after PartDatabase.cfg files before/after applying Restock the only thing that jumps out is that the deployed parachute volumes are included in the PartDatabase.cfg for restock. So I am guessing that some combination of (Real Chute / SafeChute / something else??) is causing Restock to use the deployed drag cubes for the parachutes on my rockets... I don't know this for sure, but those are the only parts I see which have big enough drag cubes to explain the massive drag I am seeing.

PSA if you use the BigFatStupidHead patches to Configurable Containers above, it also covers all the storage wedge parts in "Kerbal Planetary Base Systems". Which then gives a lot of snack/fertilizer storage and spatial layout options. (The 4 wedge hub part is very nice for early orbit bases)

Just wanted to say thanks to NermNermNerm for the Mod. You have inspired me to start a new playthrough and will let you know how it goes as I get more experience with the Mod. Also thanks to @BigFatStupidHead for the Configurable Container patches.

Due to some nice features in the C# framework and Squad be careful with impacting API's - you MAY be able to run a 0.25 mod in 0.24.2. If the 0.25 version of the mode does not depend on any of the new 0.25 mechanics, objects or API methods. But unless the mod author has promised support of 0.24.2 for their new version - you are out of luck if it fails - expect no support. e.g. I am running the latest version of Mechjeb in my 0.24.2 game, so far it works great. But I am keeping the old version install file around just in case... In this case there are no new parts between the versions so none of my craft break if I need to go back. Many other mods would be harder to back out.

Thoughts on theorycraft: I am neutral on the idea of drill diversity and finite drill lifespan. The tonnage of X you can mine out per ton of drill bit should be pretty generous (otherwise why mine at all). I agree being able to use MKS to go full circle would be interesting. I am just not sure the interest of this feature is worth the complexity for "casual users" of the mod. I like the idea of prospecting to get actual densities. (Especially if actual densities were somehow per save variable instead of totally hard wired). I am not a fan of resource depletion as a gameplay mechanic. It is hard enough to get a base network setup - having to "migrate to resources" all the time would be annoying and not fun (at least to me...).

Well, you want to deliver LF+Ox since those propulsion systems have higher ISP. Quick back of the envelope, I would expect ~50% delivered mass to be the best you could do using LV-Ns to do most of the delta V work. (I get about 2800 m/s from Minmus surface to LKO and back; you could throw in some Aero braking to shave that a bit on the way down.). With no LV-Ns ~35% delivered. Putting your construction station 700 m/s above LKO (about 3/4 of the way to Mun) would get delivery up to maybe 70%. Of course that would make it 700 m/s farther away from Kerbin for its other deliveries. Gameplay wise it depends on what you find fun. I like getting funds from missions and will use the Davon supply module to get things delivered into Kerbin orbit. (Costs more than would pay to do it by hand, but avoids the tedium of repeated supply launches). Likewise, you could use a supply shuttle to move between Kerbin and Minmus SOI combined with the Orbital Logistics module from MKS/OKS to make delivering fuel from Minmus a lot less tedious (although you would still end up using a lot of fuel mass to get the deliveries made.)

I would not expect this to be a profitable process. So what is your real goal?? 1) Mine resources to make Funds. - Pick a different resource, Karbonite is too cheap per ton to be a reasonable trade good from outer space. MKS/OKS has a couple trade goods and there is a precious minerals addon for Karbonite. Either of those is a good possibility for making profit. 2) Getting Karbonite on Kerbin for running high thrust engines / aircraft - Just tweak the tanks in the VAB - you can buy all the Karbonite on Kerbin you could want. 3) Some other goal we have not understood... In which case please help us understand. For me Karbonite is a way to get fuel any place but Kerbin...

Fizban, under CommunityResourcePack you can go into the Karbonite and MKS folders and tweak the resource definitions. I don't see why you would need to though. You can already get small amounts of everything but Karborundum and water on the launchpad - and you can get just buy a small container of karborundum or water for testing. There is no need to tweak the resource amounts to try things out at KSC. And if you just want to test an MKS production line, you can just fill a container with Minerals, Ore, Substrate and Water in the VAB.

MKS/OKS has two different logistics facilities. Proximity Logistics (which automatically moves things between ground bases within 2000m) and Orbital Logistics (which moves things any distance within the same SOI as long as you have the fuel to pay for it in the craft which has the 15t logistics hub). As a gameplay note: In my game I have added the Devon plugin to the EPL rocket part containers and into several of the OKS inflatable containers (fuel, lifes support, repair parts). I would rather pay Devon logistics for routine orbital deliveries instead of making them myself!

Thanks for all your hard work on this mod, I (and I am sure many others) really appreciate it! And I know software maintenance while in a crunch is a pain - so many little details that can go wrong...

I find it much easier to fix the tech progression speed by multiplying up the tree value with the tech tree multiplying tool (it in the external tools section) rather than having to change all the science defs. I find a 2:4 multiplier makes for an interesting game. Combining tech cost ramping with mission controller extended to give a multiplier on part prices, KIDS to put a multiplier on ISP effectiveness and you can pretty easily tweak the difficulty to suite your taste without have to make a lot of edits...

Mun landing contract scan starts but never finishes (I tried waiting it out both in Physical and Warp). It keeps telling me it is ready to scan, but it never finishes. I tired a short hop to get it to reset - no help. I can also confirm that your plugin will not recognize a Kerbol orbit for either sub-goal recognition or to enable the scanner either. (It says - you must be in orbit to scan...) But these missions started before CE patch, so they may be residual issue from earlier. Taking a quick look at the persistence file I think they come from the same problem - they both still show the inOrbuit goal as incomplete, even though I was definitely in the required orbits...

Thanks for the update - This continues to be a must have Mod for career play - thanks again for the continual improvement and maintenance!

Now understanding its your mod and you have creative control... I stongly disagree with the current contract offer approach, it is not good game design: a) It is inconsistent with stock (blocking up the list with contract for places I have not been and techs I do not have). It is inconsistent with other contract mods. (Extra Contracts only offers missions to places in reach and for tech you have). c) It is inconsistent with successive revelation, it introduces all techs and destinations right at the beginning. d) The current User Experience is horrid (as it stands now you spam the contracts list with lots of contracts for places I have not been and tech I don't have.) I have to repeatedly drop lots of science station contracts to get to anything else. [A major part of this is not something you can fix, stock needs to have some kind of contract filtering so you can quickly exclude offers you do not want...] The mod really needs to filter what it offers based on tech available and locations opened. If you really like your current design and refuse to change or if it is too hard to fix; can you at least offer a config option that will let us turn off your contracts altogether? I am more than happy to pay for my station science with funds I get elsewhere. But the current out-of-context contract spam is not good. As an additional request - when playing with a construction time mod or house rule construction times, your contracts of of short enough duration to be impossible to meet (once again - unlike stock contracts). Would you please make your mission time configurable via a multiplier or something so that those using such mods can adjust the lengths appropriately. Thank you for your kind consideration.