AccidentalDisassembly

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

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.