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...).