GFX5000i

There, I fixed it. The issue seemed to be the logic that tried to find the nodes and the active Gizmo to override the stock behavior. The way that setup ended up with nothing happening, neither the logic activated nor any errors popped up. I tested the new logic by creating and deleting multiple nodes while orbiting Kerbin, but I don't know any edge cases to test more. As a bonus I also fixed the translation for the button "+ Orb" that was displays as "- + Orb". On another note, I found that the Descending Node button is behaving strangely when there is no target (equatorial DN). While in an inclined orbit the AN button will always move the node to the same place, but the DN button will always select a new place depending on the vessel position. I couldn't fix this since the calculation was completely cryptic to me What I could see is that the KSP provides a function to get the equatorial AN, but not one to the DN, so the manual calculation is probably doing something wrong. Edit: I shamelessly copied the code for "Eq Desc" from Maneuver Node Evolved and it worked like DMagic.

I was testing the suspension lock (to use in the default legs to save a lander in the Mun full of Kraken power) and noticed the action group was not working, changed to the code below and seems good now. from [KSPAction("Lock Suspension")] public void suspensionLockAction(KSPActionParam param) { suspensionLockChanged(null, null); } to [KSPAction("Toggle Suspension Lock")] public void suspensionLockAction(KSPActionParam param) { lockSuspension = !lockSuspension; suspensionLockChanged(null, null); }

I've found quite an interesting bug. When using KIS + Universal Storage 2 + Kerbalism(or TACLS) the EVA-X (from US2) will keep adding mass and value to infinity when equipped. Searching for the bug source what I found out is that when an object is equipped the _resourceMass and _resourceCost are not being reset when CaptureItemStateFromPart() is called every frame. This makes the mass and coast of any resource inside an equipped item to be added each frame instead of being recalculated. I made a test version with them being reset to 0 before the calculation (similar to the _contentMass and _contentCost) and it seems to be working. KIS_Item.Equip() > KIS_Item.AlignEquippedPart() > KIS_Item.CaptureItemStateFromPart() KIS_Item.cs lines 739 and 740

Searching the Dev branch on the Github I found 3 places with references to shaders that are now in "Legacy Shaders/" like @sarbian mentioned. I changed, compiled and tested. No more errors in the debug. KSPWheelVesselDebug.setupDebugRenderers() line 236 KSPWheelRepulsor.postWheelCreated() line 144 KSPWheelDustEffects.setupDustEmitters() line 186 On another topic(s): - Two legs are named as "KF Folding Hydralic Leg" - I noticed two leg types deploy/retract too fast (with the exception of the folding leg). A vessel on the ground can hop quite high with that or be stuck on the ground. Using the deploy speed of the leg extension/angle might be optimal. - Suggestion: Animate when changing the leg's angle/extension to avoid similar "hops".

I made a quick test using stock KSP 1.8.1 + Foundries. The mod seems to be spamming null exception errors in 3 specific situations: Standing on the runway (gears, wheels and tracks) In flight (any part) On pause/resume game (any part) These are the most common error origins I found in the output log: KSPWheel.KSPWheelDustEffects.OnDestroy () KSPWheel.KSPWheelDustEffects.onOriginShift (Vector3d o, Vector3d n) KSPWheel.KSPWheelDustEffects.setupDustEmitters () KSPWheel.KSPWheelRepulsor.postWheelCreated () KSPWheel.ParticleSystemExtensions.ext_setEmissionEnable (UnityEngine.ParticleSystem ps, System.Boolean value) The Output Log: https://drive.google.com/open?id=1ehDBtDyVwHcrFiecMYA7F7KwjWppNbUo

In that case this script might not fix your problem entirely. It was made to fix the parachutes not showing when using the search box, but it still consider you have the category.

It adds a filter on the Utility category to hide parachutes. With this they will only show in the "Parachute" category that is created by this mod. If you are looking for a more technical answer: The invert = true change the filter from add (the default) to subtract. The type = moduleName specifies the filter criteria as the internal name of the modules and value = ModuleParachute, RealChuteModule are the default and RealChute modules respectively.

Use these 2 patches instead. They are less likely to bork anything and you won't have to re-apply them every time the mod update. As a bonus, if you use Filter Extensions, it will make the parachutes only show in their own category. If the "Parachutes" category is not showing, use only the first patch.

I've learned here that Module Manager made some recent changes in the syntax that can break some patches. In the case I've noticed SETIrebalance > SETI-ScienceSettings.cfg was affected in the biome changes for crewReport and evaReport. The fix is to remove [*] in both patches, but there might have other patches with the same issue.

I'm using this custom patch to allow any command module to "Collect All" without the need to go EVA. Then I add an action group to make it even easier. @PART[*]:HAS[@MODULE[ModuleCommand]&@MODULE[ModuleScienceContainer]]:Final { @MODULE[ModuleScienceContainer] { %evaOnlyStorage = False %canBeTransferredToInVessel = True %canTransferInVessel = True %showStatus = True } } @zekew11 On a similar topic, I've learned here that Module Manager made some recent changes in the syntax that can break some patches. In this case Revised_Crew_v_EVA_Report.cfg was affected. The fix is to remove [*] in both patches for crewReport and evaReport.

Documentation Suggestion: Add the "Camera Focus" to the list of features and to the list of Default Keybinds in this thread. The feature exists but is not mentioned. Feature Suggestion: I know SHIFT lowers the snap distance and MOD+C / MOD+X can swap between free and snap, but could it be possible to make a temporary swap using MOD+Left Click for offset and rotate. This is easier to use and similar to how it works on 3D softwares.

I imagined that would be the case. My script is working, so the issue is (kind of) solved.

They were missing from the search box system. When I made the first change they appeared in Utility while still being in Parachutes. Additionally, they also appeared when I used the search box. The new script hide them from the Utility without using category = none. That way they still appear in the search box and in the Parachutes category. The only drawback is that the script only works if you have Filter Extensions.

Now that you mentioned it, they are really showing up in both places. With that in mind I made a personal script for Filter Extension to change each parachute to "Utility" and then added an exclusion filter in the Utility category to hide them, now they will only appear in one place and are still searchable. If anyone want the script, just create a .cfg file with these lines: Example: GameData\My_Patches\MM_RealChutes.cfg @PART[*]:Final:HAS[@MODULE[RealChuteModule]|@MODULE[ModuleParachute]] { @category = Utility } @SUBCATEGORY[Utility] { @FILTER,* { CHECK { type = check invert = true CHECK { type = moduleName value = ModuleParachute, RealChuteModule } } } } My suggestion for a more clean result is to not make any category changes in the mod's code, instead add them to the FilterExtensions Default config (or make a small cfg to integrate with it) and suggest the players to use FilterExtensions. This makes every mod focus on each area, but also make the mod dependent of another for a feature it already has.

For some time I have not been able to find any of the parachutes using the VAB search box and it seems some other people are having the same issue, so today I took some time to search in the code and found the problem. All parachutes are set to "category = none" and, for some reason that I don't know, makes them unsearchable. To solve that I changed all categories to the game default "category = Utility". This change had no negative side effects in my game, but I have some other mods like Community Category Kit and I don't know if there is a reason for those lines, so further testing might be necessary. Below are the files that I made these changes. RealChute\Parts\cone_double_chute.cfg RealChute\Parts\radial_chute.cfg RealChute\Parts\stack_chute.cfg RealChute\Parts\cone_chute.cfg category = Utility RealChute\ModuleManager\Stock_RealChute_MM.cfg (delete all lines with) @category = none I hope it helps.

I was not asking anything, just pointing that the IVA problem disappeared in your version and your crew transfer block solved a big problem.

(I forgot to send this answer earlier, sorry) I forgot to mention that was in my 1.2.1 recompiled version. When I tested your version in 1.2.2 the strange IVA was not there anymore, it might have been a problem from one of the IVA mods I had installed (mostly from 1.0.3). Your latest version now blocks crew transfer, now the most critical problem is solved. I'm curious about how you did it, will take a look on the code another time to learn . Useful info: You might want to add this official request to the main post for tracking purposes.

That happened with me once. I fixed it by moving the CKAN executable to the KSP root folder.

I am glad the fix helped but the mod is still has some bugs. These are the known issues I noticed while playing and testing: Too many seats in the vessel at launch will take a while to transfer all kerbals. Could break the vessel. Transferring a kerbal to an occupied seat will eject one of the kerbals. . . forcefully. A vessel could be considered to have more internal crew space than it actually has. (+1 for each seat) This mod seems to add an IVA to the seat so activating the internal view will show a big IVA on each external seat on the vessel. Most of these problems are related to how the game handles external seats and crew transfers: To move to an external seat the kerbal must be on EVA and with the camera focused on. You cannot directly add a kerbal to the seat by code. This mod is just a workaround. I could not find any way to cancel or block a crew transfer. The only fixes I can imagine: SQUAD implementing this mod as default or adding some public functions to directly add a kerbal into the seat by code. SQUAD adding an event handler for before the crew transfer happens, with info on the target and origin modules. Remove the default IVA view or replace it with a smaller one. The good news is that if you use the mod as intended (adding a few seats for a rover/lander/plane and not making a bad crew transfers to them) it will work properly. Unfortunately, I do not know much about KSP’s code library so I hope this information help @linuxgurugamer or anyone else when making any future changes to the mod.

if you change the check from vessel.HoldPhysics == false to vessel.HoldPhysics == true the transfer will happen before the physics is activated and if you remove this verification completely the transfer can happen anytime. I've been using without it for some time and doesn't seem to have any problem while solving the phantom forces.

I've been poking around in the code, made some rebuilding and testing. Rebuilding the code with the latest version seems to make the mod work(1.2.1), but... The process made by the mod of transferring the kerbal to the external seat seems to generate some mystical forces. Add more seats and kerbals and you'll have a very powerful force still unknown to kerbalkind. Changing the IF statement in line 75 of the code from vessel.HoldPhysics == false to vessel.HoldPhysics == true seems to have solved the problem, but...(again) I don't know why this logic was made and could revive issues that were already solved. Specially since this is the first time I touched a mod so this could go very wrong at some point. Alternative Solution: While this mod is not fixed, I recommend to use WalkAbout to place a kerbal outside the facility and move him/her to the vessel.

I would like to give a suggestion in changing some parts in the tree. Part: Universal Storage: Atmospheric Sensor Reason: the Atm. Sensor is in the invention node, so its U.S. part probably should be there too. Part: Universal Storage: Science Bay Reason: Together with the first U.S. adapter (QuadCore) Part: Universal Storage: KIS Container Reason: Together with the first U.S. adapter (QuadCore) and first KIS Container FROM dmUSAtmosSense @ generalConstruction US_1M110_Wedge_ScienceBay @ simpleCommandModules US_1R110_Wedge_KISContainer @ advConstruction TO dmUSAtmosSense @ scienceTech US_1M110_Wedge_ScienceBay @ generalConstruction US_1R110_Wedge_KISContainer @ generalConstruction