AccidentalDisassembly

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.

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).