AccidentalDisassembly

Gorgeous! With respect to the EVE stuff, my current best guess is the second number in one of the volumetric layers settings, and also the fact that GU has two volumetric cloud layers VS. one in AVP. In GU's Kerbin clouds definition, the lower volumetric layer is set with: "area = 15000,4", whereas AVP uses "area = 15000,3" - the new version of EVE Redux suggests (through their testing) that increasing these numbers has a very significant impact on performance, because when they tested with "area = 18000,6" it massively reduced frame rates... Perhaps that's what's going on, although I don't really know what those numbers are doing, so... Have not yet had a chance to test changes either.

I'm not sure if it's the same thing as Trappist-1e, but I'm also noticing perhaps slightly less performance of GU graphics stuff (compared to something like Astronomer's pack), and my uneducated guess is it might have something to do with the settings for volumentric clouds (or something like that) in the GU EVE configs - at least for Kerbin. Just a possibility, or possibly subjective and meaningless.

These are fantastic! Am I correct in assuming they'll be outer-ish planets, or will some of them be in between the existing bodies in the Kerbol system?

Huh... well, in that case, then just allowing for setting up the auto-trim for level-ness and the total ballast to neutral, then keeping things that way (not disabling on keypress) should probably be enough, then, I imagine...? Easier! Hooray.

Very cool! A couple suggestions, if you're open to them: Both Maintain Current Depth and Auto-Trim are switched off if the player presses any keys (i.e. WASD) - however, sometimes you want to help the system out (get your ship to level itself faster?), or make an adjustment, or deviate for a time from your depth for some other reason (avoid hypothetical obstalces - do those even exist underwater?) without having to re-set the system after. It would be great to allow user inputs (and allow for accidental key presses too) without disabling the systems, which would then try to return to depth X / attitude Y after the user is done doing whatever it is they wanted to do. Would be handy to be able to set the depth (numerically) to maintain as well Adding a button to maintain neutral buoyancy (adapting to depth as the player zooms around underwater) would be a really cool feature, allowing the user to effectively point themselves in a direction and apply thrust to go where they want - especially for zippy little crafts. I imagine this would combine features of auto-trim and dive control - the sum of all ballast required to keep the ship neutrally buoyant at Depth X is distributed in ballast tanks such that the craft would, if stationary, have a level posture without roll (à la auto-trim), or something like that... Then you can flip your craft around, roll, dive, climb, etc. at will, and while the total ballast changes to keep you neutrally buoyant, the ratios in the tanks stay the same so that you don't have pitch/roll forces on the craft other than the ones you apply (I think). I dunno, could be really neat.

Unfortunately there appears to be an issue with spawning Kerbals for contracts - when you accept a contract to retrieve Kerbal X, that kerbal appears in the roster and what appears to be a copy of that kerbal (same name) also appears on the map/in the flight scene. It is possible to load your target kerbal in your craft before taking off as a result. Perhaps there's a way to make only one of them?

With the prerelease installed, I am noticing an issue with science: after installing the prerelease, when a kerbal goes on EVA from a rover while around the KSC, the EVA-ing Kerbal will be able to run a whole heap of experiments (plant life, something related to big and small icebergs, object analysis...). The experiment text on some experiments mention 'cells in the "tree" are similar to ones on Kerbin' and the body Blalo, so I assume this behavior is caused by something in how GU is setting up experiments, and I haven't noticed this behavior before. Anyone else notice this in a career game w/ the prerelease GU? Also, just a suggestion - it would be nice to decouple GU scatterer/EVE visuals, specifically for the stock system only, from the rest of the package and make it optional - if (for instance) you are using OPM alongside GU, packages like AVP have configs ready-made for OPM planets while GU does not. It's certainly possible to go pull out only the OPM planets stuff from AVP, but it would make more sense just to allow the user to install something like AVP (or whatever other stock visual pack) and GU, with GU stock visuals being an option if the user wants to go that route. EDIT AGAIN: I do notice, however, that it appears you can just delete the _stock folders in the GU EVE/Scatterer folders; maybe that's the easiest option?

Some MM errors on the newest version (hopefully) of OPT Reconfig - relevant portion is here, I think:

https://www.google.com/search?q=tetrahedron

It's conceivable (but I don't know for sure) that any issues with Pood's OPM VO could cause general problems with scatterer/eve - might affect GU's stuff as well. Just one possibility among many. I am not the best diagnostician, to start with, and it's also pretty hard to say much without a log file (which I only know how to read in the crudest possible way). Others will be more knowledgable, hopefully.

Couple things: The __LOCAL folder is almost certainly in there by mistake - possibly (from what I have been able to glean) an artifact of people making mods on Mac or Linux, zipping up a folder, and not looking for hidden folders getting ZIPped with others, or something like that. You don't have the latest version of Module Manager - almost certainly no significant effect from that, but worth updating nevertheless. Some other folders look suspect, or not, hard to know - For instance, what' s "Patch"? Poods OPM Visual Overhaul may or may not be up to date with latest versions of scatterer/EVE, can't remember on that one.

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