Aelfhe1m

The one from the OP? Try again. It worked fine when I tested just now.

Try these links for more details: Most (fairly) recent tutorial from this site. A video tutorial by "Game Instructor"

One partial workaround is to save your payloads as subassemblies. Then you can select edit on the recovered booster in KCT to re-open it in the VAB and then add on replacements for any expendable parts (e.g. launch clamps, fairings, upper stage) and then attach the payload subassembly. This works quite well for SSTOs or rockets like Falcon 9 where only one vessel is being recovered but if you're recovering multiple parts/stages separately (e.g. Falcon Heavy or Space Shuttle) then I've not found an alternative to just scrapping and rebuilding - at least you still get the funds back for the recovered parts.

OK, It looks like you've got an installation problem. Most of those folder names look like package or zip names. If you open each of those folders inside GameData I expect you'll find another GameData folder inside it and the actual mod contents inside that. And none of the folder names looks like they came from this mod either. (You would see Bluedog_DB, B9PartSwitch, CommunityResourcePack, DMagicScienceAnimate for a minimal BDB install) I recommend moving them all (except the Squad and SquadExpansion folders which are part of the stock game) somewhere else on your hard disc then going through them one by one moving just the contents back into your gamedata folder. i.e. GameData/Omegas_Stockalike_Structures_No_Textures_Required/GameData/OSSNTR should be GameData/OSSNTR If any of the folders has more than one folder inside its GameData folder then they are probably dependencies (other mods that the mod relies on to work) that were bundled with the mod by the author for convenience. When copying those over to your actual gamedata folder make sure to only take one copy of each and if multiple mods shipped the same dependencies then pick the most recent one (you'll often find a .version file inside the dependency's folder that you can open in a text editor to find out which version it is - pick the highest numbered one) Alternatively if that sounds complicated then instead use CKAN to manage installing mods for you.

That's the number one reason I love this mod. That self-documenting/reminder feature is invaluable. Especially when coming back to a vessel which has been in flight for a long time (both in game and IRL). In flight editing would be number 2 although there's a stock implementation of that now although I still prefer AGx's editor. Then there's the more than ten actions and easily assignable buttons for extras outside default 10. I find stock's action sets a clunky by comparison.

Checking... Checking.... I'm back I set up a minimal 1.7.3 to test. Initially didn't see the error but then found out how to trigger it - definitely an edge case. Have the action editor open before going on EVA. Left click on EVA Kerbal to select in editor (blue cross) Board vessel Exception spam Clicking any part on vessel so it is selected before boarding does not cause the spam. It seems to be related to the KerbalEVA object no longer being present.

@linuxgurugamer Spoke a little too soon. I just checked the player.log and there's one exception being spammed to log during flight: AGX Draw cross fail. 3 System.NullReferenceException at (wrapper managed-to-native) UnityEngine.Component.get_transform(UnityEngine.Component) at ActionGroupsExtended.AGXFlight.OnGUI () [0x003fe] in <0331d067141a4e4d8e8c903a006b8e45>:0 It started after Jeb returned from EVA after I sent him out of the craft with the AGx action editor windows active and a part highlighted. (This is probably a bit of an edge case unlikely to happen during normal use) Then after a minute it also started spamming: NullReferenceException ActionGroupsExtended.AGXFlight.OnGUI () (at <0331d067141a4e4d8e8c903a006b8e45>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) Full log here (ignore the LaunchSiteVesselModule errors those are from something I'm currently working on myself) .

I've done some basic testing of the recompile in 1.8.1 (with both DLCs) in a brand new sandbox game. So far no errors encountered. Tested: Switch button to use Blizzy In VAB Click button to turn on action editor Assign separate actions on multiple parts to AG 0-9, to higher numbered groups and to "other" groups (RCS, Gear, Abort) Select parts by direct clicking or through part selector menu Parts in symmetry groups auto selected and can be individually deselected Part highlighting (blue crosses, Xs and red Xs) displayed as expected Edit actions after leaving and returning to VAB Save and reload vessel to check actions are persisted Assign labels to actions Make an action show toggle status (ladder up/down) In flight Test each configured action by clicking AGx window button Test actions on 0-9 keys Verify toggle state of ladder shown correctly Right click AGx button for menu Toggle display of key codes Open action editor Change an existing action Change label of action Create a new action Change "other" actions Assign keycode to high number action ("Insert" assigned to action 200) Reset windows Exit and re-run KSP to verify defined actions still present on in-flight vessels Not tested: RemoteTech integration I've never used the Groups feature and so was unsure how it was supposed to behave but it wasn't throwing errors and seemed to do something not entirely unexpected (assign actions to groups to allow some to be hidden/shown at need?) New features in 1.8 that affect AGx: Changes made to actions in stock in-flight action editor are ignored by AGx (not surprised and I don't care much either I doubt I'll use the stock editor again) All parts now have "Toggle same vessel interactions", "Enable same vessel interactions" and "Disable same vessel interactions" actions which were not present in earlier versions and adds some minor clutter

You can use AFTER for ANY name that MM recognises. In this case that would be the top level StationPartsExpansionRedux folder. While it's true the patch (or patch folder) doesn't have any unique identifier I'm not sure it's really needed either so no need to poke Nertea to add a FOR. Indeed in my current game I've modded parts from SSPX myself using :AFTER[StationPartsExpansionRedux] and they appear in the correct part of the MM log

Since the patch in SSPX does not specify any pass information (before,for,after etc.) then it will be applied near the beginning of the patching process during the legacy pass. So any valid AFTER[] would come later and override its settings. That lets you use after with the top level folder name (or final if this is a personal patch and not something you're going to distribute). Then include the settings you think should apply and they will overwrite whatever the SSPX patch applied. e.g. @PART[sspx-habitation-125-1]:AFTER[StationPartsExpansionRedux]:NEEDS[USILifeSupport] or @PART[sspx-habitation-125-1]:NEEDS[USILifeSupport]:FINAL If the patch you were trying to override had included a before, for or after then one trick is to pick another mod that is sorted after it in alphabetic order and use that mods name. ModuleManager applies patches in the order - Patches that run at the same pass level are applied in order of path and filename (e.g. a/1.cfg, a/2.cfg, b/1.cfg). This is why I keep all my personal patches in a folder named ZZZ_Custom then I can use :AFTER[ZZZ_Custom] to come very near the end of the patching order but still have room for LAST or FINAL patches that might need to run even later.

In your own mod or referencing some other mod? If the sub-folder contains a DLL then that DLL name will be added to ModuleManager's list automatically (for example USI-LifeSupport and KolonyTools are DLLs that are inside separate sub-folders of /GameData/UmbraSpaceIndustries). Alternatively a patch inside the sub-folder may define a unique name using a FOR (never use FOR outside of the mod owning the name) e.g. FOR[FelineUtilityRover] is defined by a patch inside folder /GameData/KerbetrotterLtd/FelineUtilityRover. A list of the names defined in your particular install can be found near the start of the ModuleManager log ([KSP]/Logs/ModuleManager/ModuleManager.log)

You can only have one AFTER or NEEDS per patch. Because AFTER defines when a patch is run it must have a single value but NEEDS can refer to multiple mods so the following would be valid :AFTER[modA]:NEEDS[modB,modC,modD] Sub folders are valid inside NEEDS but not AFAIK inside BEFORE, FOR, AFTER (although I haven't tried this recently and it might just be missing from the change list).

You can adjust the Global Construction build speed by adding a user settings file (see below posts for more info):

Yes, try the following ModuleManager patch: @STRATEGY_LEVEL_EXPAND[PilotFocus] { @EFFECT[CurrencyOperationByContract] { contractType = Recovery } } Simply copy the above code into a new text file and save it somewhere in your GameData folder with a .cfg filename (I suggest GameData/ZZZ_Patches/strategiaRescueAndRecovery.cfg)

There's very little information available to show in the editor and the way the vessel is represented in the API is very different. I really should disable the Historian overlay in non-flight views to avoid a useless mess. Do you have reproducible steps or a log for this? Trying to debug "it sometimes doesn't work" can be a bit tricky... I think your layout there is actually using <LandingZone>. Baikerbanur is a mini-biome not a selectable launch site at least not in stock (with Making History). That sounds like a good idea. I'll look into it.

Minor update - version 1.8.0 for KSP 1.8.1 (download from SpaceDock or GitHub) Recompile for KSP version 1.8.1 NOTE: this version has had basic testing in 1.8.1 (with Making History and Breaking Ground). I did not test the Kerbal Konstruct or KSCSwitcher specific features. Like the 1.7.3 version I published earlier this version does not display the name of alternate stock launch sites (e.g. Island Runway) in the <LaunchSite> tag.

Minor update - version 1.3.3 for KSP 1.7.3 (download from SpaceDock or GitHub) Recompile for KSP version 1.7.3 Sorry for the long silence folks. I've had some significant health issues that I won't go into here but they've made concentrating on anything a serious challenge. KSP 1.8.1 recompile is being tested and I'll post it very soon.

Not the problem in this case unfortunately. OSE Workshop creates its own independent config nodes which are being read by the loader. The only thing shared with the other mods is the name of the resource (ablator). It looks like there has been some change in the way that the config node reader or co-routines work in the latest version that is causing the loading code in Workshop to fail for installs with a larger number of parts. It works OK with just Wortkshop and stock parts or even with a few small part mods but adding KSPIE or any of the other larger part mods seems to trigger this error. I'll keep digging and if I can't figure out how to fix the current code I'll change it to use an alternative loading method that I know does work.

@Leandro Basi and @COL.R.Neville OK, I confirmed this with KSPIE installed alongside my test build of Workshop. I didn't get the Ablator recipe error but it's almost certainly related. Not sure what's going on here since the recipe loading code hasn't changed in 2+ years. Maybe it's the upgrade to a new version of Unity in KSP 1.4. I'll investigate and find a fix.

Version 2.3.5 for KSP 1.4.x - GitHub - SpaceDock Recompiled for KSP 1.4.x

New version 1.2.5 for KSP version 1.4.X - download GitHub or Spacedock Recompile against KSP 1.4.2 Fix NRE in recycler window Refactor window drawing code Add handling for "vintage" EVA kerbals from Making History if installed Sorry for the delay folks but I've been quite ill for the last couple of months and I am only just getting back into KSP.

@chrisl To access another root level node you use #$@...$. Also you don't use #name like that - it would be [#name[XXX]] but can be shortened to just [XXX]. Try this: PART { . MODULE { . CAP { name = Adapter-2-1-Short volume = #$@SSTU_MODEL[Adapter-2-1-Short]/volume$ } } }

@Li0n, @Angel-125 I've already posted a reply on the pull request that I don't think this is the correct fix for this MM error. Here's a copy of my reply for the thread:

On the dev thread

The heads folder where this mod's textures reside only affects in-flight Kerbals. To affect Werner and others you need to add the correctly named textures to the TextureReplacerReplaced/Default folder. I tested that this still works (although I couldn't find all the texture names) : Werner von Kerman: Default/wernerVonKerman_head Gene Kerman: ??? Motimer Kerman: Default/kerbal_old Linus Kerman: Default/kerbalHead Walt Kerman: Default/kerbalHeadBeard Gus Kerman: ??? There are also either two or three separate textures for the ground crew in VAB/SPH one of which (the guys in the hard hats) seems to be Default/kerbalHead as well. The guys in the lab coats and the guys near the doors waving the guide batons don't use Default/kerbalHead but I'm not sure what texture they do use.