AccidentalDisassembly

On a heavily modded install, I tend to get a lot (thousands) of exceptions related to the creation of anomalies (or so I can kind of guess from the log). The exception in question looks like this: Could this be related to having a planet/star pack like Galaxies Unbound installed too? In any case, I notice especially at high time warps that the game also tends to pause for about 1 second periodically, wondering if it's related... Log: https://www.dropbox.com/s/kwsa7hn1rv6ewmj/KSP-blueshift-exceptions.log?dl=0

Huh, I didn't notice the angle myself, but I was pretty focused on the "every next part gets its own slightly less effective parachute" - I'll look for the angle if I get around to testing again. Thanks!

I'm seeing a weird behavior on 1.12.4 with (most recent) TweakScale, and I'm reasonably confident it is a conflict with (most recent) B9 part switch fuel switching. I believe this because on a clean install (only TweakScale, ts companions, Recall) it doesn't occur, and when I add b9 part switch and CryoTanks (which applies fuel switching to tanks so I don't have to), along with CryoTanks' dependencies (CRP + dynamic battery storage), it can be reproduced very easily. I don't *think* it has to do with CryoTanks' boiloff module, because I'm not testing on parts to which that module was applied (I think), but I guess that might be another possibility. Anyhoo, to reproduce, simply install B9 Part Switch, CryoTanks, and CryoTanks dependencies with TweakScale on a clean KSP and: Place part in VAB. Place a fuel tank that has a B9 Part Switch tank switching module applied to it; use radial symmetry and place 2 or more of that tank. Tweak the size of one of the tanks in the symmetry group just created, Pick up one of the tanks, then place it again (still in symmetry), and The tank under the mouse (the one at the point of placement) will have the correct increased volumes, but all of its 'symmetry clones' (not sure of the right term there) will have incorrect volumes equal to the original volume of the part. Just FYI! The workaround is: don't pick up and re-place anything in symmetry after scaling.

Is this exception meaningful? I see it from time to time in the ol' logs, but unsure what's going on. Possibly some kind of anomaly spawning error due to having Galaxies Unbound or OPM or something like that installed? Full log: https://www.dropbox.com/s/f6vznjs2gxbe8in/KSP-blueshiftexceptionmaybe.log?dl=0

Depends on the weight, but yes, it seems possible for it to be problematic with SR - or if you're dropping probes that have juuuuuuust enough parachute power to make them land softly, I guess... In my tests, the difference was big enough to cause destruction for some parts when others landed OK (in flight scene).

Not sure if anything can be done about it, but there's an interesting bug in stock 1.12.4 that I think has been around for a very, very long time - it has to do with parachutes and is easy to reproduce. Make a rocket in VAB, then, in radial symmetry, connect two or more things with identical mass (a tank of ore, let's say) to the craft through decouplers. Put 1 or more parachutes on those things, also in symmetry. NOTE: It does not appear to matter if you do this in symmetry or if you place each part individually, a similar effect will be visible regardless, I think. Set staging to activate parachutes on decouple, launch, go to 500m (or whatever altitude, it's easier to see with more falling time -> higher parachute altitude, and with certain ratios of parachute effectiveness to test-weight mass), then decouple the ore tanks, activating the parachutes. Observe the falling speed of the ore tanks when slowed by the chutes - in principle, they should fall at the same speed (or very, very close) before and after the parachute opens fully, because the properties of each parachute should be exactly the same, and the mass of the tanks, mass of the contents, etc. If you test this with a dead weight, the (several) dead weights you decouple will fall at very, very close to exactly the same speed, except for any tiny variations in drag they might encounter on the way down. Note, however, that each tank will fall at a different speed when the parachute is involved. If you try this with more and more parts in radial symmetry (for convenience), each new presumably identical part will have its own speed different from the others, and (I guess?) therefore its own parachute properties; 2 parts in symmetry will fall at 2 different speeds, 3 parts will have 3 speeds, etc., and each additional part in radial symmetry seems to fall faster than the last / have a parachute that appears less and less effective than what the 'default' parachute should. So... I guess... if you have multiple parachutes on a vessel, each one you place does less than the last one...? Or if you decouple 2+ things from your ship, each new vessel/debris/entity (whatever the game considers them) gets slightly different parachute properties...? I don't know what this means, but it's pretty weird. Fun Kerbal bugs! It would be awesome if it could be fixed, but I guess February is around the corner, too...

EDIT OF THE EDIT OF THE EDIT : Here you go! Commented updated version of the original config. Updated versions of both the B9PS config and the tank definitions to bring them in line with values found in Stock and in other mods, such as NearFuture stuff and MKS stuff. Top part of the config is the B9PS switcher applications, bottom part is new tank definitions. Also avoids Tardis-like fuel capacities on some Buffalo parts. I've tried it out on my heavily modded install, and so far nothing has exploded.... YMMV. Note that I have updated the Tank definitions for most things, but wasn't sure what volumes to give to certain things, like for TAC resources or FreshAir etc. for Snacks FreshAir; made guesses where I could, left at 1:1 ratio where I didn't want to guess. This may or may not be the 'correct' way to handle volumes, but I'm operating on the "1 unit of base volume = 1 unit of LiquidFuel" principle and applying multipliers to tank definitions as seems appropriate. https://pastebin.com/UGyAeKAj

Might just be my modded install, but looking at the B9 PartSwitch fuel tank types and switcher configs, it seems that a number of parts (like b2FuelTankModule and b2FuelTankModuleShort) only get Ore as a switchable tank in the absence of WildBlueTools/WBIOmniStorage. It would seem seem like they ought to get at least liquid fuel / LFOX, maybe CryoTanks types if that's installed, etc - just FYI!

FYI - Here's a list of .cfg files in the latest version of GU that have mismatched opening and closing curly braces, along with the number of (opening braces, closing braces). Not sure if these mismatches actually will produce problems, of course, but... they might: '/gu/configs/gu_patches/rescale_sigma/10x.cfg': {'braces': (5, 6)}, '/gu/_systems/_alphacentauri/_celestials/04_kaith.cfg': {'braces': (95, 94)}, '/gu/_systems/_epsiloneridani/_celestials/_asteroidbelts/asteroids.cfg': {'braces': (67, 65)}, '/gu/_systems/_lich/_configs/gu_patches/_singularity/singularitylich.cfg': {'braces': (2, 4)}, '/gu/_systems/_tauceti/_celestials/06-04_celae.cfg': {'braces': (41, 42)}, EDIT: Also of note, here is a list of files that can't easily be read due to an encoding error, presumably - possibly need to ensure valid utf-8. No idea if this will affect anything, no clue how KSP handles encoding/decoding, but if it's silently failing to read these files because it's looking for utf-8 and using a similar encoder/decoder to default Python 3.11... who knows!: KSP_win64/GameData/GU/Configs/GU_Patches/ResearchBodies/GU_ResearchBodies_Main.cfg - 'utf-8' codec can't decode byte 0xfb in position 15487: invalid start byte. KSP_win64/GameData/GU/_Systems/_AlphaCentauri/_Celestials/01_Alva.cfg - 'utf-8' codec can't decode byte 0xb0 in position 1055: invalid start byte. KSP_win64/GameData/GU/_Systems/_AlphaCentauri/_Celestials/02_Blalo.cfg - 'utf-8' codec can't decode byte 0xb0 in position 659: invalid start byte. KSP_win64/GameData/GU/_Systems/_AlphaCentauri/_Celestials/03_Orus.cfg - 'utf-8' codec can't decode byte 0xb0 in position 617: invalid start byte. KSP_win64/GameData/GU/_Systems/_AlphaCentauri/_Celestials/05_Cail.cfg - 'utf-8' codec can't decode byte 0xb0 in position 911: invalid start byte. KSP_win64/GameData/GU/_Systems/_AlphaCentauri/_Celestials/06_Syro.cfg - 'utf-8' codec can't decode byte 0xb0 in position 985: invalid start byte. KSP_win64/GameData/GU/_Systems/_AlphaCentauri/_Celestials/07_Elno.cfg - 'utf-8' codec can't decode byte 0xb0 in position 615: invalid start byte. KSP_win64/GameData/GU/_Systems/_AlphaCentauri/_Celestials/10_Sian.cfg - 'utf-8' codec can't decode byte 0xb0 in position 1103: invalid start byte. KSP_win64/GameData/GU/_Systems/_AlphaCentauri/_Celestials/11_Elius.cfg - 'utf-8' codec can't decode byte 0xb0 in position 3247: invalid start byte. KSP_win64/GameData/GU/_Systems/_AlphaCentauri/_Configs/GU_Science/GU_Science_AC.cfg - 'utf-8' codec can't decode byte 0x92 in position 187: invalid start byte. KSP_win64/GameData/GU/_Systems/_AlphaCentauri/_HomeSwitch/02_Blalo-Home.cfg - 'utf-8' codec can't decode byte 0xb0 in position 1065: invalid start byte. KSP_win64/GameData/GU/_Systems/_EpsilonEridani/_Celestials/02-3_Rhan.cfg - 'utf-8' codec can't decode byte 0xb0 in position 677: invalid start byte. KSP_win64/GameData/GU/_Systems/_EpsilonEridani/_Celestials/02_Thythe.cfg - 'utf-8' codec can't decode byte 0xb0 in position 953: invalid start byte. KSP_win64/GameData/GU/_Systems/_EpsilonEridani/_Celestials/03_Æl.cfg - 'utf-8' codec can't decode byte 0xc6 in position 140: invalid continuation byte. KSP_win64/GameData/GU/_Systems/_EpsilonEridani/_Celestials/04_Tias.cfg - 'utf-8' codec can't decode byte 0xb0 in position 1296: invalid start byte. KSP_win64/GameData/GU/_Systems/_EpsilonEridani/_Configs/GU_Science/GU_Science_EE.cfg - 'utf-8' codec can't decode byte 0x92 in position 240: invalid start byte. KSP_win64/GameData/GU/_Systems/_EpsilonEridani/_HomeSwitch/02_Rhan-Home.cfg - 'utf-8' codec can't decode byte 0xb0 in position 1014: invalid start byte. KSP_win64/GameData/GU/_Systems/_Lich/_Celestials/02_Poltergeist.cfg - 'utf-8' codec can't decode byte 0xb0 in position 592: invalid start byte. KSP_win64/GameData/GU/_Systems/_Lich/_Configs/GU_Science/GU_Science_Leethe.cfg - 'utf-8' codec can't decode byte 0x92 in position 187: invalid start byte. KSP_win64/GameData/GU/_Systems/_TauCeti/_Celestials/04_Aquel.cfg - 'utf-8' codec can't decode byte 0xb0 in position 650: invalid start byte. KSP_win64/GameData/GU/_Systems/_TauCeti/_Celestials/06_Arceus.cfg - 'utf-8' codec can't decode byte 0xb0 in position 914: invalid start byte. KSP_win64/GameData/GU/_Systems/_TauCeti/_HomeSwitch/Aquel/02_Aquel-Home.cfg - 'utf-8' codec can't decode byte 0xb0 in position 976: invalid start byte.

I like Far Future Technologies and Blueshift, personally!

There is an additional situation where I can reliably reproduce the sound cutting out issue. Can reproduce by doing this: 1. Load a game with only Stock stuff (with expansions, in my case) and TimeControl. 2. Start hyperwarping at any accelerated speed. 3. Switch to map view and back. If you switch while hyperwarping, it will cut out sounds. If you switch when NOT hyperwarping, it won't.

Huzzah!

Zip here: https://www.dropbox.com/s/n8j9j8hc097a70l/GameData_AVC_ZeroMini.zip?dl=0

I receive the same error with fresh 1.4.1.7 - deleted old folder, installed the new. Log: https://www.dropbox.com/s/ye0j7mbn2thqypq/Player_log_KSPAVCinstall.log?dl=0

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.