AccidentalDisassembly

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!

Something a bit funny happening with TweakScale (latest), KSP 1.11.2, surface attached parts, ALT-copying, and offsets: copying the satellite part (not as a subassembly, just ALT-copying from the decoupler) causes the solar panels to be further and further offset from the surface-attached robotruss parts. Log as well, but didn't see anything on quick glance: https://www.dropbox.com/s/p96anzx1nsz466g/ksplog_stagerecoveryKKjnsq.log?dl=0

Something going a little wonky when trying (failing, here) to recover stage bits with the combination of JNSQ, Kerbal Konstructs, Sigma Dimensions (downscaled JNSQ to end up at ~1.6x stock size based on my personal preferences) and Stage Recovery - not sure if this is sufficient information, but is what I found in the log: Log is here: https://www.dropbox.com/s/p96anzx1nsz466g/ksplog_stagerecoveryKKjnsq.log?dl=0

Bit late to the party on this, but when I gave KerBalloons a whirl out of curiosity, the speed limiter was definitely *not* the behavior I was expecting and I never would have thought to look in difficulty settings to change it. It appeared to be a baked-in behavior of the mod. Thus: I would leave it off by default, it just doesn't make sense from a player's perspective, who (like me) is probably going to think "big balloon = big lift = go up fast". If for some situations the speed limiter is necessary, maybe a PAW button that rationalizes the behavior would be more intuitive - "adaptive inflation" that tries to maintain X m/s of climb, or something.

I am playing in 1.11.1/2 and do not have this issue at all; perhaps it's some interaction with another mod? I've had no such problem even with various planet packs that use CBK differently (add more or fewer levels of DSN, different strategies, etc.)

With the latest update to Kopernicus, Contract Configurator can choke on something related to the solar panel changes - this is perhaps something the contract pack in question needs to change, but thought it might be useful to bring it up here too: (At least I don't THINK this happened with versions earlier than 35/36...)

Just a note regarding ReStock - The Cheetah and Wolfhound engines aren't altered by ReStock (I don't think...) and changing the patches for them to eliminate the &!ReStock makes the nice plumes available to us ReStock users too! I don't think it introduces conflicts with other Waterfall-based mods, since I have most of them installed alongside that change...

FYI - contract loading error: [LOG 15:36:49.181] [INFO] ContractConfigurator.ContractType: Successfully loaded CONTRACT_TYPE 'FirstFlight' [LOG 15:36:49.187] [INFO] ContractConfigurator.ContractType: Loading CONTRACT_TYPE: 'LandOnGilly' [ERR 15:36:49.192] ContractConfigurator.CompleteContractRequirement: contractType 'LandOnTheMun' must either be a Contract sub-class or ContractConfigurator contract type [WRN 15:36:49.194] ContractConfigurator.ContractType: Errors encountered while trying to load CONTRACT_TYPE 'LandOnGilly' [LOG 15:36:49.200] [INFO] ContractConfigurator.ContractType: Loading CONTRACT_TYPE: 'Jool5'

Trying out BTW to see if it can replace Time Control; first time I took it for a spin, I also didn't have a button, but it was caused (for me) by installing the *master* version of Toolbar Control from Github (just out of curiosity, since it appeared newer than the standard release). When I installed the actual release 0.1.9.4 off github page, as one is obviously supposed to do, it all worked fine. Dunno if that's what could be happening. KSP 1.11.1, both expansions, pretty clean install.

Wish I could delete this; quoted myself instead of editing. Ugh.

I like both of those ideas - the logic seems sensible to me, e.g.: Kerbals can last for X hours/days (user defined via difficulty setting maybe) on EVA without food (and/or without a fresh air resupply or other resources) - cargo parts with relevant resources increase total hours/days before penalties on EVA. Beyond X hours/days, penalties apply according to settings (reputation loss, fainting, death...), or something like that. Kerbal becomes absolutely voracious after EVA if snack cycles missed & no snacks in cargo part, attacks the snack cart upon reentering a vessel, making up for missed snacks by consuming <appropriate quantity>. Kerbal refills suit (so it's always ready to go) upon reentering craft as well, so X Fresh Air (or whatever other resources are enabled/used) are consumed after EVA, depending on how much time the Kerbal spent outside (representing how much air, oxygen, water, whatever was depleted from the suit during that time). Cargo parts (air canisters or whatever) are also refilled during that time, so resources are consumed according to Total Original Capacity (including cargo parts) * Time Spent on EVA / Max EVA Time (defined by settings and/or reasonable max time per unit of air assumed to be in suit and augmented by cargo part, etc.). Maybe.

Couple of bees and a couple observations so far (constellation pre-release you just posted) - for what they're worth. Note: not on a clean install! But mods are fairly common ones. BEE 1: Gave the Konstructor a whirl - created a craft with a bunch of preloaded resources, the big orbital shipyard, command pod, and the ground shipyard test part. If you launch from VAB, then build a craft (such as the Jumping Flea), the craft will be constructed successfully, then detached from the ground shipyard test part. In my case, I put the ground shipyard test part on the side of the craft and built from there, so the flea fell off after completion. After completion, active vessel switches to the one you just built; if you then switch back to the constructor vessel, you can't select the same craft to build a second time unless you first select a different one. If you try to select the same craft (e.g. jumping flea again), the select ship dialog will pop up, you can pick it, but nothing happens when you confirm. If you first select a different craft, then it seems you can pick the just-built craft and build it again. BEE 2: When picking crafts in the "Select a Ship" dialog, an odd behavior if you pick an autosaved ship (in my case, specifically the autosaved version of the konstruction ship I launched to test it) - picking a not-autosaved ship gives a solid gray square as a preview, but picking an autosaved one gives this (looks like an image with MK-33 mod parts, maybe...?): BEE 3: Under circumstances I don't understand, building a ship in orbit using the KS-500-O (big one?) will cause the built vessel to be propelled at very high speeds away from the vessel that built it (also causes forces on the vessel that built it). First time I tried to build in orbit with a very simple station, no problem - the built craft poofed into existence maybe ~20 or 30 meters from the construction station. NOTE: Not a clean install, but not a massive heap of mods either. Second time I tried (new station craft, new save), I had a bunch of other parts (containers, girders, whatever) attached radially to the station and also a bunch attached to the KS-500-O, and the built craft goes flying off when finalized... Third time I tried (same station craft & save as second try), the construction station was instantly obliterated without any explosions (it just vanished), and rather than flying off into the distance, the built vessel remained (apparently) fixed in place where the station used to be, kind of ... wobbling. Maybe a conflict with Kopernicus... Log: https://www.dropbox.com/s/vpiwdsejg3vgcni/KSPlog_newMKSwithKopernicusmaybe.log?dl=0 OBSERVATIONs: Mostly stuff that I think would be nice for the player if it's not already planned, essentially -- Would be really handy to be able to transfer resources (fuel, EC, whatever) and crew to a built craft before releasing it/finalizing it/making it pop into existence Building is instant; will construction take time or can it be made to take time? Just curious, doesn't really matter one way or the other. It would also be handy to keep the built craft attached (somehow) to the construction station/pad until released, à la EL Maybe also handy to have a specific point on the construction station (the end of an arm that extends from it? some selectable docking port on the vessel? a stack node like the ground shipyard test seems to use?) where the built craft will appear... EDIT again: Random bee #5 having (I guess?) to do with the Light Globe's drag cube or something: EDIT AGAIN: A log from a very modded install with some WOLF exceptions -- https://www.dropbox.com/s/yww8z46w7xp172t/KSPLog_WOLFexceptions.log?dl=0

That makes sense, IMO. No need to calculate/track/resource-ify stuff beyond that; how would you even eat a snack in a spacesuit anyway? (Fresh air being a different question, but presumably all spacesuits have air tanks, because, otherwise... death and stuff.) EDIT: I guess the one use case I can think of is sending a kerbal in a spacesuit into orbit and beyond, no craft, but somehow with a backpack of supplies. Which is fun(ny), but... maybe not typical enough to bother cooking up a whole workaround.

Huzzah! Thanks for looking into it.

@Angel-125 - in conversation with @Lisias, I've been trying (or rather Lisias has, because I lack the knowledge to contribute much) to figure out an issue that may or may not be caused by Snacks - but the problem can definitely be reproduced using Snacks (and not other mods, like USI LS, that also place stuff on the parts in question). I may be jumping the gun, but figured I would post here too in case you might have insight. The problem arises with the combination of Snacks and inflatable habitation parts from Stockalike Station Parts Expansion Redux. Symptom is nullref-inducing, click-blocking, and PAW-mangling right click behavior on those inflatable parts while in the editor. On a clean KSP install with only Module Manager, SSPXR (+dependencies, like B9 Part Switch and NF Props and such), and Snacks, you can reproduce the problem by doing the following: Enter the VAB, create a craft using any part. Attach radial attach points (or whatever) in symmetry to that part (has to be symmetry) - this is only to provide stack nodes that allow you to attach inflatable habs with converters in symmetry as well. Attach an inflatable SSPXR hab such as the "Winston" one-ended 1.25m inflatable hab (or others, including the hitchhiker or what have you) to those radial attach points' stack nodes - use symmetry. Right click on one of the Winstons (or whatever) you just placed; PAW is mangled/shortened and you can no longer right click on any other parts. If you exit the VAB and return to it, reloading the autosaved craft, you will be able to right click on the inflatable parts, inflate/deflate, etc., but if you try the same process again, same result (at least for me). I tried patching a resource onto the SSPXR parts thinking it could be HabUtils inflater thing somehow interacting with resources - no problem there. Inflate/deflate works fine, right click works fine etc. inside and outside editor. I also tried using USI-LS, which patches its 'Start Habitation' module thing on to SSPXR inflatable parts as well. Couldn't reproduce the problem. Log here: https://www.dropbox.com/s/klfc5pud6w52m1l/SSPXRClickProb_KSP.log?dl=0 MM cache here: https://www.dropbox.com/s/gp0a08g113bl6fi/SSPXRClickProb_ModuleManager.ConfigCache?dl=0 EDIT: Sorry, I should have bothered to test other non-inflatable parts. It does not have to be an inflatable part; this also occurs with things like the PTD-5 Sunrise Habitation module. It just needs to be a part with Snacks stuff applied (a converter, seems like) and also B9 switchable stuff.