AccidentalDisassembly

Reporting very similar problem to @Apelsin, on a heavily modded install with stuff like GU, OPM, SpaceDustBunnies, EVE, scatterer, tons of part mods... a big heap of mods, some causing other exceptions too (althougb not a huge number... I think...): Log is here: https://www.dropbox.com/s/fhgmw6npi7omlpu/KSPLog_SpaceDust2020-02-18.log?dl=0

Hmmmmmmm, I just tried this on a much less modded install (my testing environment, which has stuff like TweakScale, B9PartSwitch, Interstellar Fuel Switch, MechJeb, KER, vessel mover, part info, etc.) - and in this environment I DO see both switcher options in the editor. So... Some conflict on my main install causing one switcher but not the other to appear? Still very confusing! On the less modded install, I do not get an exception from tweakscale when moving/placing/scaling the OPT drop tank, either. So... uh... I guess somehow another mod is making one of the switchers not appear, and also somehow interfering with TS...? EDIT: I tried on my main install career save. I DO see both switchers on sandbox, and I don't on career. I see an upgrade in the tech tree that gives new B9PartSwitch options to the drop tanks in career. Could there be some interaction between TweakScale and B9PartSwitch modules that are not unlocked/upgraded yet in a Career save...? EDIT AGAIN: I couldn't reproduce the same exceptions at first; tried opening career save, creating new craft with drop tank, manipulating size and contents, and launching. I didn't see TweakScale related stuff at that point. However, then I reverted back to the editor, and *THAT* seemed to lead to TS related stuff. Maybe reverting starts things off...? Not sure, there are still exceptions from other stuff as well. Log is: https://www.dropbox.com/s/ac4gp0dkwngfmno/KSPLog_TSExceptionsReproduced2020-2-18.log?dl=0

Here is the (sadly, also huge) MM cache - I notice on OPTdropTank that there *are* two B9PartSwitch modules, but only one appears in game... very strange: https://www.dropbox.com/s/myiu2ng5vbkam9e/ModuleManager_TSTracking.ConfigCache?dl=0

So far, I can at least confirm that I can now load and fly a vessel that was causing VERY strange behavior before (and is what made me start looking at the logs) - when launching it into the flight scene, the camera would go under the runway, control was lost, camera couldn't be rotated, all sorts of strange behavior, launch clock was at -16 days or something... Now, I can manipulate that vessel in the editor and also fly it; there are still some exceptions, but they're different and A LOT fewer after removing KerboKatz/ASS, RationalHydrodynamics, and PartInfo. I still notice an exception from TweakScale, but I think I have narrowed it down: At first, there were no TweakScale related exceptions in the log. Then I loaded the problematic craft into the editor, manipulated only the OPTdropTank part on it, and reloaded the log - saw exceptions after this action. I changed tank size slightly, picked it up, placed it again, launched craft, I think. I have a theory about a possible reason related to B9PartSwitch patches. The B9 Part Switch patch configs that ship with OPT make me think the drop tank is meant to have two switchers: one for fuel contents, and one more for tank style - either plain, heat shielded, or 'super' (something like that). However, the 'tank style' options do not appear in game - only the ones for switching the contents of the tank. This makes me think there's some issue with a patch, or with B9PartSwitch, or with the combination of these two switchers plus TweakScale on the same part... Or maybe one of those patches is somehow not unlocked yet (upgrades? don't even know if that's possible with B9PS) - this is a career game. Unfortunately, B9 Part Switch related patches are split over many files in OPT and OPT Reconfig and therefore difficult to round up. However, I included a new log and at least the patch related to OPTdropTank's 'tank style' in this ZIP: https://www.dropbox.com/s/e1rmzua7u6hjxwa/KSPLog2020-02-18-second.zip?dl=0 Maybe closer... Thank you for your help!

Having an issue with _BuildManager.dll on EVE version 1.11.2.1, on KSP 1.11.1 with expansions. On every game start, I get this in my logs, and it seems (maybe? I'm really not sure) that it *might* somehow cause a big heap of issues for other mods down the line. Or not at all... Is this something anyone else has seen? I have tried this both on a heavily modded install and on one with relatively few mods (mostly utilities like EEX, along with EVE and scatterer on both installs). Both installs get the same error in the same place in the log. Error reads:

That was... extensive! Thank you for that, I will give it a shot. _BuildManger.dll is from Environmental Visual Enhancements (the latest version), hopefully that's not the root issue, because I quite like EVE! By the time I closed the game, the log was ~1 Gigabyte. Ugh. Very unfortunate re: KerboKatz, because KerboKatz (Automated Science Sampler) is the only mod I know of that has the functionality of dropping you out of warp when there's science you can do in a given biome (as opposed to doing what X Science! seems to do, for instance, which is dropping you out of warp upon every change of biome regardless of science availability). EDIT: No fancy control devices, just a generic keyboard and a logitech mouse...

Getting some exceptions maybe related to TweakScale plus B9PartSwitch - or not, I have a heavily modded install with (apparently) many problems and I'm trying to track down what's causing them. Is this meaningful? Log here: https://www.dropbox.com/s/bp4we0wbf9cx1wf/KSPlog_SysHeatOrSomethingElse.log?dl=0 Example here, which may or may not be TweakScale's fault at all (but something seems to make TS cough a bit), given the other problems in the (gigantic, sorry) log:

I'm getting messages in my logs that seem related somehow to SystemHeat - however, it's a very modded install, and there are lots of other issues (apparently, because... problems). Trying to see what's causing what. Is this meaningful? Log is here (sorry, it is enormous; many issues): https://www.dropbox.com/s/bp4we0wbf9cx1wf/KSPlog_SysHeatOrSomethingElse.log?dl=0 What I think is possibly relevant is stuff like this - only because this appears repeatedly in the middle of the string of SystemHeat messages about 'Vessel MODIFIED' / building heat loops: EDIT: May or may not have tracked down potential culprits (Environmental Visual Enhancements --> _BuildManager.dll, or possibly Automated Science Sampler... or... not sure yet).

This might work - I don't see these two properties in other engines, so assume they are responsible for ramp-up / ramp-down. No guarantees: @PART[ntr-gc-25-3] { @MODULE[ModuleEnginesFX] { !engineAccelerationSpeed = DELETE !engineDecelerationSpeed = DELETE } }

Makes sense, thanks. Since reentry / speed in atmosphere isn't the same system, then, I assume it's probably not possible to see 'this many kW of heat are being applied to the craft / to this part' kinds of stats that are available with stuff on SystemHeat loops - too bad! Insane as it is, it'd be fun to know (up front) roughly how much it would take to make a radiator-packed "just point it at the planet" reentry pod and/or an orbital-speed-in-atmosphere plane. Trial and error, here I come...

That's fine, of course. I don't even know if there are real use cases where allowing manipulation of the warp bubble size (upward from where it is right now) for a price would be useful - warp a whole fleet together, if you have enough graviolium, maybe - just an interesting possible feature. I mean, it's certainly not necessary - since, you know, you could just dock stuff to your 'warp tugboat' if you want to warp a whole heap of things at once. But it could be cool for some unknown purpose, I dunno. Another hypothetically useful feature (again, not necessary by any means) might be some kind of 'safety' where the warping ship won't drag other objects along with it (e.g. if you forget where you are for a minute and fire up warp engines a little too close to a station). There, too, the feature doesn't actually need to exist at all, since you can just sub-light away from the station/other ship/asteroid, as you say, but could be a handy thing assuming it's even possible. Another hypothetically handy feature - being able to set how you circularize when you circularize, e.g. circularize into an equatorial or polar orbit, clockwise or counterclockwise, that kind of thing. Not necessary either, but could be cool or handy too. Just throwing stuff out there.

This is proving quite annoying to test - if you use Hangar Extender to make a very long craft with a stack separator (so you get 2 craft that can easily distance from each other in orbit after HyperEdit), then the smaller part of the craft will be obliterated when you use the decoupler. No idea why. Anyhoo, I tested this. I am reasonably confident that it's the root part after all - I made a VERY long craft (~150m) with a CoM at the opposite end to the root part (huge tanks on one end, just a command pod on other). The craft got dropped from the bubble exactly when the root part command pod crossed the 350 meter mark, while the CoM was ~150m further away from the bubble origin point. An interesting feature idea might be to control the warp bubble size with a slider, so that you can either avoid dragging a station with you, or do it on purpose, dragging A LOT of stuff with you in a giant bubble at the price of additional graviolium in proportion to the volume of the sphere... Or perhaps some kind of toggle (if it's even possible) that makes the bubble somehow not interact with other craft. Though based on how Angel said it works (shifting the frame), I wonder if that would even be possible...

Editing this down because most of what I had written became moot when I did more testing. Ugh. Long story short: When I try to reject heat from an SRB or from reentry/really fast flight in atmo, I seem to need a crazy amount of radiators, but I can't see where to find out how many. Is there a way of knowing how much total heat is being applied to a vessel while in flight at a given point in time, so I can test and see how much cooling would be needed for a hypersonic craft X at speed Y, or a reentering craft, or a craft with too many SRBs or something? (As opposed to numbers/simulations in the editor that seem to account for stuff like reactors/drills/etc.) Also - when testing with Heat Control to understand better how SystemHeat works, I noticed (on the launchpad) that graphene radiators had 'cooling efficiency' (or similar phrasing) at ~ 28%, while large stock extending radiators had ~88% (in atmosphere). Is this a function of the heat of the SRBs not being 'hot enough' for the high-temp radiators? ~30 large deployable stock radiators successfully cooled three kickback SRBs (infinite fuel on) I used for testing craft/engine heat rejection, but even 80 of the graphene radiators couldn't stop them from overheating... EDIT: should perhaps note that I'm also using the extra SystemHeat patches, if that's important...

My guess is that the station's center of mass needs to be inside the bubble for it to get dragged, and the whole craft would either get dragged or instantly released when the CoM isn't inside anymore (due to it drifting away, if it's drifting away) - when I tested this, slipping outside the bubble was instantaneous and affected the whole craft, not part by part, so I can only assume you'd either drag another craft or not, and there's no middle ground involving ripping pieces off of it... but I guess we'll find out!

Just now tried that - as near as I can tell, it has whatever velocity it had, like the warping ship still does when it exits warp too. Thus: if you match velocities with the object before warp, it will stick around. So, something like this, in my experiment: Build ship in 2 parts, one decouples from other. One part can warp, other can't (or can, probably doesn't matter). Hyperedit into orbit; now ship is moving on whatever vector it's moving on due to orbit. Decouple and warp. After stopping, both craft dragged in bubble still have same velocity as before warp. While warping, when debris/other part of craft drifts ~400m from the warping ship, it slips outside of bubble; it seems to act exactly as if you cut throttle on a warping ship (maintains original velocity) at the position in space where it slipped outside the bubble. If you warp away and warp back to the debris, you'll 'pick it up' in your bubble again if you get within ~400m (or whatever), relative velocities still maintained, and it can slip outside the bubble again (and will then hurtle off into space at whatever definitely-slower-than-light-speed velocity it had). With objects NOT moving with roughly the same velocity as the warp ship... Fun fact - you will still 'pick it up' in your warp bubble, and the object will bounce around a lot (because of very different velocity) until it happens to land outside the bubble, whereupon it will start moving according to whatever velocity it had before it got dragged by the bubble. E.g. warp straight at an asteroid at low warp and you'll snag it in your bubble. Then some jerkiness will happen (it will appear to move around very violently, jiggle/bounce) until it gets 'spit out'. After experiencing number 5... It would be really handy to also have a button to 'match velocities with target for X graviolium' so you can intercept things that aren't planets, like an asteroid or a stranded ship... then you can tow the asteroid wherever you'd like it to go Or perhaps that would be too cheaty, since it might remove the need for any other form of propulsion on the ship. Dunno... If you do warp up to an object with very different velocity... let's just say that catching it in your bubble involves a certain chance of collisions. I don't think it takes any more graviolium to warp with a massive asteroid in the bubble than normally... but that would be interesting, if it's feasible to somehow count 'total mass in the bubble' or something.

This is fantastic, thank you - also found it very fun that you could warp up to a chunk of debris (or another ship) and warp away with it. Really cool effect. I didn't notice in game, actually, but now that I think about it - if you have another ship / debris / asteroid in your warp bubble, does it take more graviolium to move or do you move at a slower max speed? Would be an interesting way of tugboating asteroids or space stations around a system...

Small FYI on latest (I think) release - these two files have mismatched/misplaced curly braces - in Tundra400.cfg, the PART {} closes before some of the modules (right before ModuleInventoryPart), for instance: GameData\WildBlueIndustries\Buffalo\Parts\FuelTank\Tundra400.cfg GameData\WildBlueIndustries\Buffalo\Parts\Utility\Wagon2u.cfg

Is it possible to calculate distance to the nearest object instead, or something along those lines? For me, anyway, from a gameplay perspective, it would be pretty cool to have maximum speed be more variable - in a specific sense, though. If it's possible to somehow get 'nearest celestial', then perhaps it would be possible to make it so that the further you are from any body, the faster you can go; if you go straight up from the plane of the ecliptic in a system, you'd be able to gain speed pretty fast (as opposed to potentially going near planets in the plane), that kind of thing. If it's not possible to do that easily, and if right now the speed is just based on "SOI type" and updates when SOI is updated, is it possible to vary the speed based on distance from the central point of the SOI? So that, for instance, if you transition into the Jool SOI, you can move faster near the edge of the SOI than at the center... which would be somewhat similar in effect to a continuously variable max speed. Likewise, the acceleration / deceleration effect would be taken care of implicitly if max speed were a function of distance from the center of an SOI (assuming that's even possible). I dunno, just kind of throwing out some random thoughts, with possibly very little basis in what's practicable. Makes sense, thanks! Just have to remember to shut down the engine if I'm not using it. Easy enough. The problem (in my mind) is multi-part, but it boils down to: difficulty settings take many clicks to turn on and off, aren't 'visible' (mentally or literally on the screen), and this specific feature is something that would be easier to use with an active 'circularize now'. For instance: 1. You arrive near a planet, but don't want to circularize yet, because maybe you want to get to a different altitude than the one you happened to cut throttle at, or ... whatever reason. The option was on in the settings, you forgot; goodbye graviolium. 2. You turn the option off in the settings, maneuver a little bit to where you want, then want to circularize: back into the difficulty settings to turn the option on. 3. You do some kind of landing using a small craft, get some science, forget you have auto-circularize on; now you're off to the next body: oops, auto-circularize again when you didn't want to circularize yet, goodbye graviolium. Now you have to go through the steps of changing the difficulty setting, doing a maneuver, turning the difficulty setting off again, then turning it on again when you want to circularize... it is far simpler, faster, and more intuitive from a gameplay perspective (and much more predictable!) to simply have a button - this also prevents guesswork like "at what altitude does auto-circularize kick in for this body? is it safe to stop at 5,000km alt and reorient for a maneuver, or do I need to turn the setting off, then back on...? Hopefully that makes any sense at all!

This is VERY COOL. I do have one suggestion regarding warp rates - is it possible to alter whatever check/equation is determining current maximum warp speed in order to make a smoother 'ramp up' of max warp speed based on distance from a body/star/sphere around a barycenter/whatever? As it is at the moment, the instantaneous jump to 1000x warp speed at the boundary between planetary/interplanetary/interstellar is a bit jarring, and if you're pointing in sliiiiightly the wrong direction when you hit the boundary... zoom! Is there any way of doing something like: Current max warp speed = max ship warp speed / 1000 * number of arbitrary useful distance units (1M km? 1B?) between ship and nearest celestial body" or similar? Or is it too expensive to calculate something like that? EDIT: Also, just out of curiosity - graviolium is consumed by engines when not actively warping, and rate of consumption does not seem to change when warping at 3000c vs. 3c - is this as intended? EDIT 2: Second suggestion - the auto-circularize feature is very handy, but not easy to use; can it be made a PAW menu button or similar ("circularize now for X graviolium"), as opposed to a setting in difficulty stuff?

Thank you for these - going through this process solved the issue with disabling Luhman/Kormann binary also breaking scatterer/EVE on Kerbin! You mention in the video that it would be nice to name files according to the in-game system names (the kerbalized version) - this would indeed make things A LOT clearer. It might also be handy if files were organized by system rather than by type - for instance, if the folder structure didn't lump all planets together (under Celestials), but rather grouped things by star/barycenter, with a subfolder for planets within that system - something that would make it as easy as simply deleting a particular folder in order to disable a system (or specific body), if that's possible. For instance: pre-place all scatterer and EVE assets in PluginData folders, referenced from configs (with :NEEDS so that they're disabled if scatterer/EVE isn't present) provided in the main DL and in folders grouped by system; In order to disable an entire system and its visuals, then, all you have to do is delete a given folder from "GU/Celestials/<SystemNameHereAsFolderName>" - or, if you want to delete only specific planets, you could delete the folder "GU/Celestials/<SystemNameHere>/<BodyNameAsFolderName>" or some such. Of course I'm not sure if that's exactly possible to do - but renaming things according to in-game names (at least) and reorganizing the folder structure would make things a lot easier for the end user, if it is possible.

I may have found some minor causes of the issues with disabling certain planets and whatnot - or not. I'm not sure how MM handles mismatched braces. Anyway: in all of these .cfg files, there is a mismatched number of opening and closing curly braces {} -- GameData\GU\Celestials\_00\_AsteroidBelts\Ross154_Asteroids.cfg GameData\GU\Celestials\_00\_AsteroidBelts\_EpsilonEridani_Asteroids.cfg GameData\GU\Celestials\_System.AlphaCentauri\08_Narath.cfg GameData\GU\Celestials\_System.EpsilonEridani\02-4_Borr.cfg GameData\GU\Celestials\_System.EpsilonEridani\03_Æl.cfg GameData\GU\Celestials\_System.Trappist1\Trappist_f.cfg GameData\GU\Configs\GU_Patches\DOE\KK_DOE.cfg GameData\GU\Configs\GU_Patches\Singularity\SingularityLich.cfg GameData\GU\Configs\GU_Patches\Singularity\SingularitySgrA.cfg GameData\GU\Configs\GU_Patches\Singularity\SingularityVanMaanen.cfg GameData\GU\Configs\GU_Resources\GU_Settings\LqdHe3.cfg GameData\GU\Configs\GU_SettingsFiles\RemoveLenseDirt.cfg EDIT AGAIN: Link removed. Curly braces make little difference after all, too!

Hooray! I think. That's great news and also not great news (because, well... who wants to find problems?), but still definitely great news.

With scatterer/EVE and GU, I'm getting some floating terrain features (midair rocks on the Mun, for instance) - anyone else have this? Or have I installed something incorrectly, maybe? Latest Kopernicus bleeding edge (75, I think).

Hello! I was playing around with disabling certain stars/systems in GU-GENERAL_Settings.cfg and found that disabling the Luhman system also breaks Scatterer (and maybe EVE) on Kerbin. If I switch these settings from 'True' to 'False', scatterer water, atmosphere, etc. on Kerbin no longer functions correctly (water vanishes, leaving a kind of 'blue basin' effect; atmosphere no longer looks correct, weird shadows on planet in main game screen after load and in flight/tracking, odd-looking clouds, etc.): Luhman_BROWNDWARFS = False Luhman_PLANETS = False At least I *believe* it's these two settings. I switched three others to 'False' as well (specifically: LOAD_KSS_Objects_TheALL, LOAD_MamaJek, and LOAD_Singularity), but they seem to have no negative effects. Changing the Luhman settings back to 'True' restored scatterer effects. Hopefully easy to reproduce it!

Sounds good! Workaround is fully functional so far as I can tell, so it's not a huge deal in any case! Thanks for the time you put into this.