AccidentalDisassembly

A general set of guidelines that might help, no promises: 1. Many mods require other mods to function, or are themselves split into multiple parts. For instance, GU requires Kopernicus, which is composed of two parts: Kopernicus itself, and ModularFlightIntegrator; Kopernicus and everything else that uses Kopernicus also requires ModuleManager. Always check for mods' dependencies. Sometimes these are noted clearly on a mod's main forum post, sometimes they're not - you may have to do some looking and definitely need to do some careful reading, possibly even most of the time. In the case of GU, you'll need to read the "How to install" section on the first post of this thread. HOWEVER, the link to Kopernicus included in that description is incorrect - instead, go here and download the version of Kopernicus for 1.11 (it's the ZIP with 1.11 in the name): https://github.com/kopernicus/kopernicus/releases 2. Most mods, but not all, are packaged in such a way that they try to show you how to organize folders by the way they are organized in the .zip file you download. For instance: when you download GU, you get a ZIP file with a series of folders inside it. Always open the folders and look around for a moment - you're looking for a GameData subfolder (if it exists). If it does exist, then the mod intends for you to put the folders *inside that GameData folder* into KSP's GameData folder. If no GameData folder exists inside the .zip file, then the mod probably intends for you to put whatever folder(s) you see in the .zip (without digging) into KSP's GameData folder. Because mods are all made by different folks with different ways of thinking, the folder structures inside ZIPs aren't always the same. Sometimes, you have to make educated guesses as to what's intended. 3. The inside of your KSP GameData folder should look like this if you've installed GU correctly, *with its dependencies* - of course, you might have other folders in there too, but at least these should be there along with whatever else you've got going on. (Note: ModuleManager is also required for just about every other mod out there, and it will generate some files that will appear in GameData after you run the game with it installed.) Pic here: 4. Some parts of some mods are optional, such as the 'visuals' and Parts bits of GU. You can choose whether you want those or not. If you do, they may have additional dependencies. 5. The general logic of mods is thus: They're going to give you a .zip, and inside that zip will be one or more folder(s) intended to go into <KSP Directory Here>/GameData. Make sure the mod has any other mods it needs in order to function, and look around inside the .zip file to see if there's any obvious hints as to which folders are supposed to be the ones that go in GameData.

Just now had a chance to look at the issue I was having again - it may or may not be related to Recall, but it seems to involve Extraplanetary Launchpands too. Removing Recall and trying it again will allow adding fuel lines on new craft, but not on the old one that used to have Refunding. This was happening when the fuel line was added: Seems like perhaps an interaction between Recall and EPL, because on previous iterations of this save, I was using EPL just fine - behavior changed with installing Recall --.7.7, *I think* (low confidence). Or the aftereffects of some other interaction, or... I really don't know at this point, I can still sometimes reproduce it after removing Refunding stuff, so... Ugh.

Having an issue I think is related to Recall/Refunding (see log here: https://www.dropbox.com/s/3e4odf1dtmaunko/KSPLog_Refunding.log?dl=0) In editor, I can't put external fuel ducts between parts - connect the fuel duct on one end, and it won't then connect on the other. just picks up the part again. I don't know if it's related to Refunding, but when looking in the logs, I saw a number of errors that is (I think) equal to the number of parts in this save... Passing along the log in case it's useful, whether or not that's actually related to my editor issue.

Based on issues with TweakScale (caveat: I don't really understand what's going on), it is *possible* that this recovery issue is a bug with KSP itself. Just a thought, but only based on vague dot-connecting (there's an issue with recovering parts with TweakScaled parts as well, it seems; might be somehow related...).

Took the new version for a spin! Noticed some slightly odd behavior with some exceptions in the log as well. KSP 1.11.2, not too many mods (dev-ish install). I think (hope) it's installed correctly w/ Kopernicus and whatnot. In Kerbin's deserts, this happens - the vehicle looks visually like it's going over terrain that is more undulating and uneven than appears in the image; when it's going "up" some invisible terrain, it rises up as shown: Log with exceptions: https://www.dropbox.com/s/ganwdxhi67loxp9/KSPLog_parallax_exc.log?dl=0 The exceptions didn't seem to correspond to any particular behavior, but.. well, there they are.

Sadly figured out I was simply misundestanding you AFTER hitting reply. Ugh.

I mean to say: after changing settings, you need to restart to generate the patch file, which seems to be generated after parts load. (Maybe?) Then restart *again* to have the patches applied by MM - two restarts in total. That's what the dialog boxes suggested needed to happen, at any rate... EDIT: I am dense. You are saying what I am saying.

Really like the idea of this mod, much more sensible than KIFA, seems to me. Couple things I've noticed so far: 1. The "include tanks" radio button setting does not hold between restarts; I think it actually does apply the patches, but the button itself doesn't remain checked 2. It takes two restarts to apply patches if settings are changed (e.g. include tanks) - it seems like you then need to start up, change settings, then restart to generate the patch that corresponds to those new settings. Then KSP Part Volumes tells you you need to restart again to apply the patch just generated. Fantastic mod!

The image was in fact in advanced - sort by manufacturer mode, so maybe it's working as intended! I simply hadn't seen it before, wasn't sure if it was meant to be that way

Something I have noticed about this change - the patch for these tanks is written like this: @PART:HAS[#manufacturer[OPT*Division],@MODULE[ModuleB9PartSwitch]]:NEEDS[B9PartSwitch,FarFutureTechnologies] However, this results in antimatter tanks are being added to many inappropriate parts that happen to have B9 Part Switch and the OPT Division manufacturer. For example - this applies antimatter tanks to all engine parts that have switchable ISPs, such as the "Downswell" (which uses B9PartSwitch to change response profiles). Perhaps ModuleCommand, ModuleEnginesFX, and ModuleRCSFX could be excluded (these are the ones I noticed, at least) - something like this, assuming I actually wrote it correctly: @PART:HAS[#manufacturer[OPT*Division],@MODULE[ModuleB9PartSwitch],!MODULE[ModuleCommand|ModuleEnginesFX|ModuleRCSFX]]:NEEDS[B9PartSwitch,FarFutureTechnologies] Secondly: there are two patches applying two different antimatter tanks to parts that currently have them. For instance: This is the offending portion of the OPT_FFT.cfg patch, which doubles up antimatter tanks with the same HAS criteria. Looks like the one inside the fuel-tank-adding patch can simply be removed: EDIT: Also, not sure what's going on here, but Part Upgrades are visible as parts in the editor somehow (at least on a sandbox game) - and they're cargo parts! 'Refunding' is from KSP-Recall (to fix refunding issues with TweakScaled parts), perhaps related? Or perhaps Cargo Part is getting added by KSP Inventory for All, or something...? Odd in any case:

Not a problem! Just posting stuff in case it ends up being useful information.

I think I already reported this before, but just confirming that the latest 2.4.4.6 (still?) has an issue with symmetry and B9 Part Switch switchable tanks (B9PS 2.18 latest, with CryoTanks and dependencies as a test case, no other mods) - if you place a tank in symmetry, scale it up, pick it up with the mouse, and re-place it, all but one of the tanks in the symmetry group will revert to the part's original fuel capacity. One of the parts will retain the correct maximum capacity, but the actual contents in the tank will be set to something close to (but not exactly the same as) the part's normal capacity (in this case, 133.2 Ox, 1998 LH2), like this: I overwrote the log on accident, sorry!

Is there a way to stop IR from creating its own part category when Breaking Ground is installed, since it already has a Robotics category? Appling @category = Robotics doesn't seem to stop the IR DLL from swooping in and re-categorizing everything...

Think I may have discovered an issue with Recall - it *seems* to be connected to asteroids. Went on an asteroid-grabbing mission, grabbed asteroid, brought it back to Kerbin... can't revert to the space center. Bunch of exceptions from Recall... Log here: https://www.dropbox.com/s/igyykbmx6m8q1dj/KSPlog_recallexceptions.log?dl=0

You can actually still select the parts when they're below the floor if you can mouse over them juuuuuust right - hopefully Angel will have a fix, though. Mysterious behavior indeed, I would not have connected it with Snacks! either except for the issue with symmetry stuff that I found out about a while ago and that Angel already fixed.

With JNSQ, I had a similar issue, I think - after I manually edited some ocean stuff, on the next load the ocean was gone. I think I just reinstalled scatterer to fix it, although I'm not positive about that. I may have also reinstalled JNSQ configs related to oceans... Now, however, something got rid of JNSQ's very nice sun flare and I don't know how to get it back! YMMV

Roger that. Just throwing it out there; it's one aspect of KSP that I really wish existed, so I could send a mission off and then go busy myself with other stuff that needs attention and time-warping. Maybe KSP2!

Makes sense. I'll just patch back in the categories and cross fingers. FWIW I did reproduce the copy bug, it appears 100% certainly Snacks related; I tried a completely clean KSP 1.11.2/MH/BG install with only Snacks (EDIT: and ModuleManager). Without Snacks, all parts alt-copy normally; with Snacks, crewed parts get sent under the VAB floor. Can be seen on hitchhiker (for instance).

The SSPXR parts are also getting the cck-lifesupport tag, but they show up in two categories... Somehow the three stock parts that Snacks patches (Mk3 shuttle, hitchhiker, and mk2 crew cabin) are having their category removed, but other parts are not. ModuleManager config cache confirms that Mk3 Shuttle cockpit has category = none, for instance, but the SSPXR parts have category = Utility (still). The tags are similar for the parts; it's the category that's been removed. For instance, the SSPXR inflatable hab 3 has these tags: tags = sspx base contain outpost statio (stor tube inflat beam expand (hab liv ball dodge volley winston cck-lifesupport ...and the Mk3 Shuttle cockpit has these tags: tags = aero aircraft armageddon bruce cmg command control ?eva fly gyro ?iva moment pilot plane react shuttle space stab steer torque willis cck-lifesupport But somehow the Mk3 Shuttle cockpit is getting set to category = none... Is it possible that this could result from patching order? The SSPXR patch adds the tag cck-lifesupport in the :FINAL pass, while Snacks doesn't use :FINAL...? There is no other patch in my GameData that references the Mk3 Shuttle cockpit apart from Snacks' patch that adds cck-lifesupport... I definitely have no idea if the copy problem relates to Snacks, but since there was a copy (ish?) issue with Snacks before, figured... well... maybe? No clue really, though. EDIT: The copy issue is definitely Snacks-related; edited original post to reflect as well.

Also getting two funny behaviors related to Snacks!, @Angel-125 - or rather the first one seems to be for sure, and the second one is just... I don't even know: EDIT: First one might just be CCK doing its thing, but second one is definitely Snacks-related: Behavior 1: when Snacks and CCK are installed, several parts don't appear under their normal categories (Utility, Pods, whatever), and instead only appear under the Life Support category. These include (so far, that I've seen): the Mk3 Shuttle cockpit (should also show in Command/Pods) the Mk2 crew cabin (should show up under Utility too) Lynx life support bag, container, and module (which should also show up under 'Rovers', probably) The 2-crew Mobile Processing Lab from the ScienceLabInfo mod (should also be under Science) The PPD-12 itinerant service module from SSPXR (should be under Utility too, I think) OPT K and J mobile labs (which should be under Science too) By contrast, parts that DO appear in more than one category (as they should, in both Utility and in Life Support, for ex.) include these: SSPXR's Volleyball, Winston, and Eclair inflatable habitation SSPXR's 1.25m Sunrise and Star hard-sided hab modules (This is on a career save, so there are probably other parts affected like this, but I don't have everything unlocked/researched.) Behavior 2 that may have nothing to do with Snacks at all, or maybe it does I can reproduce with only Snacks and ModuleManager installed on clean KSP 1.11.2 with BG and MH: when alt-copying parts in the editor (same very modded career game), I can alt-copy many parts with expected results (copy of part appears picked up under mouse cursor). However, some parts (such as SSPXR habitats, greenhouse, the Hitchhiker..) perform a magic trick when alt-copied, and one of two things happens: a) the part gets duplicated, but placed centered, unattached in space and not 'picked up' by the mouse - UNDER the VAB floor!; or b) if the part has been rotated in the editor and THEN copied, it will appear slightly ABOVE the VAB floor. Visually, the copied parts sometimes do not appear transparent (as they normally do when floating unattached in space), but are in fact neither attached nor selected. This made me think maybe, somehow, in some way, whatever fix was made regarding Snacks! + alt-copying SSPXR parts could be having an impact here because *I THINK* the common denominator is that all of the parts that get sent under the floor when copied have crew capacity, and all of the ones that copy with expected beahavior have only resources/converters/whatever, but no crew capacity. Log: https://www.dropbox.com/s/1y2o4wd8f93l43f/ksplog_snackscategoryandcopying.log?dl=0

One thing I would find super useful personally - execute next maneuver node whether or not the craft is currently focused in the flight scene. And then execute the one after that, and then the one after that... So you could essentially queue up commands in a given vessel to happen at appropriate times, like on actual space missions (by creating and then queueing/assigning maneuver nodes as the 'commands'). That way, you could leave your mission to run without needing to switch to each vessel that needs to execute a maneuver at specific times, and then switching back to the flight scene you want to focus on, and then switching again... Of course, you can use KAC to set alarms for maneuver nodes now, but you still have to perform each maneuver on each craft every time something needs to happen, instead of abstracting some of the maneuvers and 'letting mission control take care of it', in a sense. It sounds like this is probably outside the scope of what you're interesting in doing, but thought I'd throw the idea out there as a potentially interesting one that would permit more strategic mission planning as opposed to micromanaging maneuvers.

They're certainly possible distances, if they're measured in meters - 2000km diameter planet, I think.

If I am understanding correctly, the proposed approach does not eliminate or force anything - it simply adds a button to docking ports that says something like 'enable constructo-mode' (or some vaguely similar kind of functionality with better verbiage). If you don't want to enable constructo-mode, you can... just... not click on that feature. If you don't click on it, presumably the stock docking ports work just like stock docking ports normally do. Or perhaps I have misunderstood, that is frequently the case. EDIT: In any case, I do agree with the idea that one could accidentally press such a button. Assuming that's actually how it will/would work, a "Are you sure you want to weld this stuff?" dialog box seems prudent.

Ah! I had completely forgotten that the IR parts aren't actually using TweakScale anymore (ModuleIRVariant instead, looks like)! My brain is living a year or two in the past it seems. Will do that, thanks!

When figuring out what went wrong with something else in my logs, noticed a nullref from Waterfall - possibly from an RCS effect on one of the NearFuture (Spacecraft, I think? Can't remember precisely) RCS parts. Log here: https://www.dropbox.com/s/p96anzx1nsz466g/ksplog_stagerecoveryKKjnsq.log?dl=0 Just in case it's useful!