AccidentalDisassembly

On 1.11.1 with SSPXR and a heap of other mods, I get a very unusual behavior in the editor. Right clicking on inflatable parts results in a very short (vertically) PAW - around 2 'lines' or buttons tall - with bizarre values and buttons. For instance, there were several copies of a button with the text "New Text", the 'Winston' module had several resource bars with 12345 snacks, things like that. After right clicking and getting that window, then clearing it (only way was removing part from the vessel) , right clicking on all parts is no longer possible. Log is here: https://www.dropbox.com/s/2xow1gfhscmgfve/KSPLog_SSPXRClickingProblem.log?dl=0 Could this be some kind of Snacks patch issue, or TweakScale, or something like that...? SystemHeat...? The *maybe* relevant portion of the log is *maybe* this, which is the point at which I added 4 of the Winston inflatable habs in symmetry and tried to right click to see capacities/inflate/deflate/etc.: EDIT: Bizarre update - leaving the VAB (without saving) and then going back in the VAB (which loaded the craft again, as it had been autosaved) results in being able to click on the inflatable modules, inflate them, deflate them, etc. Seems to work after leaving/reentering VAB, somehow. However, when you do go back into the VAB, attaching the inflatable habs *in symmetry* causes the same problem to reappear. Symmetry seems involved, because placing *one* inflatable hab was OK - could right click it, inflate, deflate, etc. Placing habs in symmetry on radial attach parts caused catastrophic failure. EDIT AGAIN: Could not reproduce on a clean install, but can reproduce with only Snacks installed in addition. Could it be due to Snacks patching in a Soil recycler (converter) to the inflatable parts, or possibly the Soil/Snacks resources? Resolved; had to do with Snacks.

These look fantastic!

The scanners do yield science points, but only after a certain percentage of the planet/body has been scanned (by whatever scan type you're using), I think. Analyzing data and transmitting will return science in rough proportion to how much of the planet was scanned successfully so far.

Question about functionality - [X] Science Here and Now has a stop-warp-on-new-biome feature, but it seems to drop you out of warp simply on entering a new biome regardless of whether the current vessel can do any science in that biome (i.e. has an experiment that hasn't been maxed in the biome, and can run it, and doesn't already have a copy of the run experiment stored somewhere on the vessel). Is that actually how it works, or have I missed a configuration option somewhere? If I am not understanding how X Science's options work (or Science Alert), then much of what I'm about to say is.. uh.. maybe pointless! Anyway, the reason I ask: X Science, Science Alert, and Automated Science Sampler have slightly different purposes, and slightly different approaches to dropping a craft out of warp. Incorporating a couple features from Science Alert/ASS into X Science, or slightly modifying how Science Alert chooses when to drop a ship from warp, would either make X Science the only "Better Science Gathering" mod that's needed, or make Science Alert easier to use. Maybe. (ASS hasn't been updated in a while and SpaceTiger hasn't posted in a while either. ASS works more or less in 1.11.1, but has some strange behaviors - running experiments 3 or 4 times, every time, and some load errors when it doesn't find DMagic DLLs or what have you, and it's All Rights Reserved, and why have two mods checking for science on every biome change, and... etc.) Anyway, the features are: Give Here and Now an additional setting that drops warp on entering a new biome only if non-maxed science can be performed in that biome by the active vessel, and hasn't already been run/stored on the vessel, as opposed to dropping warp on every biome change. I think Here and Now must already 'know' this information, because it seems to use it to determine the button status (yellow vs. gray text, can or can't be clicked to run an experiment) for each experiment and the blue science progress bars next to experiments visualize whether the current vessel already has a copy of Experiment X for Biome Y (dark blue portion of the bar). The use case for this feature is (for example) orbiting a planet or flying over the surface and collecting science as you go; under those conditions, you only want to drop warp on entering a biome where you can actually do more science, since you might cross biome boundaries a lot in orbit and dropping warp on every change isn't helpful. Science Alert provides a similar functionality, I think, but it's tedious to set up: you seem to have to change *every* experiment's option to "not maxed" individually. I'm not totally sure whether Science Alert drops warp simply if you can run experiment X and it hasn't been maxed, or only if the current vessel can get more from the biome/experiment... Again, I might not be understanding how to use the mods, in which case - sorry! Mostly it's just really tedious to click every single experiment over to 'not maxed'; with planet packs that have surface features and such, and with science experiment mods, there can be hundreds of things in the list. There are ~56 ish in the list in stock, I think. Give Here and Now the ability to run all experiments (and/or all but EVA, same as in Science Alert) and transfer experiment data to a selectable container or command pod either manually or automatically (also like Science Alert, but ideally with ASS's ability to pick the container and maybe suppress the science dialog too), thus resetting experiments (including single-run, if a scientist is present) without having to EVA a scientist. If X Science could do those things, it might eliminate the need for any other science-gathering-type mod, like Science Alert and Automated Science Sampler, becoming essentially the best of all three of them wrapped into one: see all the science you have/haven't/can collect, stop warp when you can collect stuff (but not on every biome transition unless you say so, and not if you've already grabbed from that biome), make it easy to collect it (just like Here and Now, ASS, and Science Alert do right now), transfer it, etc. Just a thought. I know you have a big heap of mods, so figure it's unlikely to do a kind of 'mash-up' and slight feature modification like this, but perhaps you'd find it useful too..

It's definitely that contract - and I managed to salvage the game by deleting that contract and the hotel/casino ones dependent upon it - so far so good!

Am getting 8 module manager errors related to OPT Reconfig 3.1's CryoEngine patches - I think the relevant bits are here:

Sounds like you need to deliver a physical object to a biome, but then it 'eats' the object (makes it disappear, so the game doesn't have to calculate all its bits and bobs) and still lets you use its functionalities to gather/convert stuff

For anyone else who might have encountered this - on a heavily modded install (so conflicts are possible) of 1.11.1 with newest versions of everything I could get newest versions for, every time I complete the investor tour contract, the next craft I launch cannot be controlled, the camera moves to an unusual position, and basically I can't launch or do anything. Reverting works, but launching fails and entails a very large number of nullrefs from a large number of mods. I've done this on various saves and the common denominator is *always* completing the investor tour, then launching a new craft. I have no idea what's going on, exactly, but just a heads up for anyone else who was as confused as I was by sudden game/save-breaking madness.

Awesome, thanks! Yes, I am currently working around by doing just as you mention - first place, then scale. Glad to know I am not insane. I saw that blowfish (? I think?) accepted your PR for the other B9PS fix, maybe s/he can somehow address this in concert with you...? Either way, thanks!

Do you have MechJeb parts on those ships? If not, that may explain it. An alternative: MechJeb for All. Perhaps you had MechJeb for All's config installed previously and deleted it.

@Lisias -- Getting a bug I am able to reproduce reliably on clean KSP. TweakScale 2.4.4.5 (with a couple Companions, but I don't think they're relevant). Happens w/ B9 Part Switch recompile that you provided to me AND the public version. TS 2.4.4.5 hotfix does not change anything. Two separate symptoms, I think, but I am only able to reproduce #1 reliably. SYMPTOM 1: Install only TS, B9 Part Switch, *AND* a mod such as CryoTanks that patches fuel switch options to many tanks. Place a pod and a fuel tank (one that has switcher options); scale up the fuel tank, noting its new fuel capacity. Alt-click to copy the scaled-up fuel tank, place the copy; the copy will have the *base* fuel capacity of the part, not the scaled-up capacity. No exceptions in ksp.log, at least... Symptom 2, which I can't reproduce and may or may not even be related, involves part copying as well: copying a scaled up fuel tank (for instance) will result in a visually larger part, but attach nodes will remain at original positions (original scale). Here is an example of the MM Config Cache for one affected part: On the save where I noticed the issue, I had written a custom patch to remove ModuleCryoTank from all parts; the issue with TS is present regardless of whether ModuleCryoTank is there or not (issue happens on that save AND on a clean save with no custom patches or anything else in GameData).

Been trying to track down a mysterious problem with decoupling (separating one craft from another w/ decoupler or separator doesn't really 'separate' them; switching in flight using [ or ] to the newly-decoupled craft causes phantom forces in both, and accelerating the 'mothership' craft also accelerates the decoupled craft which remains frozen in space, moving along relative to the mothership). Only seems to happen with some subassemblies, sometimes, maybe if the subassemblies have the same name as a craft... I don't know, it's all very mysterious. Sometimes reverting to the editor (after a flight) reverts to a subassembly rather than the whole craft too. Ugh. Anyway, I have no idea what's causing that (KJR? but it doesn't do it all the time on all installations of KSP...?), but I did notice some exceptions from SpaceDust again in the log. The two things are almost certainly unrelated, but posting the log here just in case if helps track down whatever is causing the SpaceDust exceptions: https://www.dropbox.com/s/cp7b2ohgs2okqz0/KSPLog_SpaceDustExceptions.log?dl=0

All I see on the bug tracker is a big heap of confirmed bugs (but not mine, which they apparently haven't looked at), and zero progress on any of them... EDIT: I needed to look harder. Wonder if they're going to patch, and if so, if they'd like to communicate about when that might be...

Small FYI - MM is coughing up a warning related to /ImprovedTreeEnginePlacement/Tree/ITEP.cfg. Not sure what it's about, though, sorry! EDIT: Never mind, found it with a little more looking: [WRN 20:45:12.567] more than one pass specifier detected, ignoring all but the first: ImprovedTreeEnginePlacement/Tree/ITEP/@TechTree:FOR[ImprovedTreeEnginePlacement]:NEEDS[CommunityTechTree]:AFTER[CommunityTechTree]

Having an issue that is causing exceptions in a lot of things, including scatterer, or MAYBE somehow related to scatterer, but.. I don't know, probably not. I have had a very hard time seeing a pattern / being able to reproduce the issue, except that it happens when launching a craft from the SPH / upon switching to the flight scene. The symptom is: upon craft launch, the camera goes under the runway looking up at the craft, the camera can't be rotated, no controls work, lots of exceptions in the log... but it's possible to revert the flight to the editor and the game seems to recover until attempting to launch again. I only have one hypothesis - is it conceivable that Rational Hydrodynamics is somehow interacting with scatterer water effects (like the bobbing effect with waves...)? I installed RH between the last time I could play without issues and this issue appearing, although it's not the only thing that changed. Also updated other mods and installed Science Lab Info, I think. (Updated things like Waterfall, CryoEngines to the latest versions downloaded today). So... probably not scatterer at all, but... maybe? Really messy log here: https://www.dropbox.com/s/es2o9pfmdw9txrc/KSPlog_scatterermaybe.log?dl=0 EDIT: Edited because I saw a whole heap of other issues in the log, so... I don't even know if scatterer is involved, but it seems to end up being affected (exceptions), along with other things.

Small observation about most recent Buffalo. In KSP 1.11, the Buffalo Cargo Tail causes rather insane drag. For comparison - a guppy command pod as the furthest-forward part on a fuselage causes drag of about 3.5. The cargo ramp (while closed, at the back of the craft) creates about *28.0* units of drag (at around 7 or 8,000m). While open, it creates slightly more drag; while opening, the drag varies (seems to be highest in the middle of the animation). Could something like the colliders or meshes or ... uh... other bits.. (?) be causing this, or is it more likely to be a craft shape/configuration issue? The parts on my craft are simply [guppy]-[crewcabin]-[servicebay]-[servicebay]-[cargoramp] from nose to tail, in that order (with various wings and such attached to the sides, engines mounted on the wings, tail on top of the cargo ramp etc.).

FYI, all of these configs still have a mismatched number of curly braces in the most recent version 1.4 uploaded to Spacedock (the one that appeared updated today): GameData\ContractPacks\PWP\Milestones\100.cfg GameData\ContractPacks\PWP\Milestones\2500m.cfg GameData\ContractPacks\PWP\Milestones\AtlasII.cfg GameData\ContractPacks\PWP\Milestones\AtlasIII.cfg GameData\ContractPacks\PWP\Milestones\Gilly.cfg GameData\ContractPacks\PWP\Milestones\Jool5.cfg GameData\ContractPacks\PWP\Milestones\LandOnMinmus.cfg GameData\ContractPacks\PWP\Milestones\ReachSpace.cfg GameData\ContractPacks\PWP\Milestones\That'sOneSmallStep!.cfg GameData\ContractPacks\PWP\Stunts\BarnstormRnDBridges.cfg EDIT: Jool5.cfg is particularly egregious in this respect; especially near the end of the file. Many of the parameters/groups are nested in ways that look incorrect at first glance...

The engines look great! Also the plumes - very nice. One very small (also very... nitpicky? aggravatingly particular? OCD-like?) suggestion - is it possible to change the order in which B9 tank types are listed in the switcher? For LH2 cryo tank options, the first combo in the list is LH2-Ox, then pure LH2; it would be nice if the methalox were in the same order (LCH4/Ox first, then pure LCH4). However, obviously this is such a small thing that it does not really matter, so disregard or not as it pleases you. Out of curiosity - are there other uses for LCH4, like there are for LH2 (in nuclear engines via Kerbal Atomics, for instance)?

Pretty cool! A possibly fun idea, but I suppose not really needed per se given the already existing jump gates - perhaps it could be possible to create one of these 'singularity-type' gates using a ship - or two ships. One ship at the origin point, another ship at the destination, and perhaps both get eaten (and a crazy amount of graviolium consumed on each, maybe) to produce a permanent singulari-gate...? Could be cool! Just a wild idea.

Thanks for taking a look - I managed to get rid of many of the errors, at least for now, but SystemHeat is still in there throwing exceptions at times. I gather that this may be because of other errors, but figured I'd pass along a new log just in case it's useful. Player.log this time: https://www.dropbox.com/s/8o45mj9kcm5y0jn/PlayerLog_SysHeatAndOthers.log?dl=0 Sorry, that log is also gigantic.

That is not correct - you can most definitely use the stable version of Kopernicus that's built for 1.11.1; I'm using it right now!

Whatever you do, don't copy and paste. Use a file hosting service (dropbox, google drive, uh.. pastebin? or something like that) and link to the file instead.

Hooray! I'm glad to have contributed; 9 times out of 10 when I report something, it was actually my fault - so this is a nice change, hah!

Hooray, a lead! That does look similar, at least the IPartMassModifier.GetModuleMass stuff...!

Same exception occurs for me on 1.11.1 - seems to be mayyyybeeee on scene switching? Log: https://www.dropbox.com/s/fhgmw6npi7omlpu/KSPLog_SpaceDust2020-02-18.log?dl=0