AccidentalDisassembly

Cool, thanks!

@blackrack Looked great in the pictures, then figured... sure, why not, I've never patreon-ed anyone before. Result? Holy mother of pearl, it's a masterpiece. Well done.

Out of curiosity, is there a way to rearm a craft while in flight in addition to transferring ammo from one craft's container to another? Is it possible to re-populate the bombs or missiles that were on pylons when a craft was launched after it's dropped them? Or would a kerbal have to re-place them manually (assuming that's possible)?

Can confirm that with 2.4.6.19 on 1.12.5, the issue with B9 Part Switch and symmetry persists, just FYI in case that's useful info!

Just an opinion from a player/user, and an opinion that doesn't matter much since I'm not the one making the mod, but here's how I think players similar to myself might experience the mod you're describing - most all of it sounds like a great idea, basically a jump drive, but there are a few bits that might introduce some frustration -- I would suggest architecting the system to allow the timing feature to be optional, and abstracting it out (when turned off) through a simpler system. Just an example, not necessarily the 'right' idea: whatever your target destination, the underlying game idea is that you may or may not arrive exactly where you want: in 'simplicity mode', simply calculate a larger or smaller sphere of possible arrival points around the target destination (based on a kerbal engineer's skill level, maybe even stupidity, where higher skill = smaller sphere, maybe also based on any gravity wells on the line between you and destination) and you'll end up somewhere (random? not sure) in the sphere without having to try to time the movement of a dot. The semi-skill-based approach to jumping could be interesting, but it also could be seen as something one of the *kerbals* would be doing, and something where kerbal stats in KSP2 (whatever they will be) will actually matter - the player instead interacting with the game world in a more commander-type role... just a thought. The sphere size or deviation of the initial line to target (or whatever other confounding factors) could be shaped similarly by any combination of crew skills; maybe pilots would be better at reducing the confounding influence of other gravity wells, or at jumping from nearer/farther from a body, or better at jumping out of an atmosphere...etc. I think being unable to jump to an arbitrary distance/point in space might prove frustrating - I would argue that it might be nice to plan this as an optional feature too (for increased difficulty); another way of making celestial bodies influential in jumps might be simply to modify the area of arrival probability depending on how close the intended point is to a celestial body, and/or giving a (bigger or smaller) velocity to the craft upon arrival, or other things like that. What does this snagging mechanic do, though? I'm not sure I understand this part - if a planet is almost directly in between you and where you're jumping, does that mean you'd end up at the Whipping Post (if there is one) and not your destination? Or would a whipping post just make the sphere (or whatever shape) of possible arrival locations smaller, so to speak, if you're trying to jump to a point near it, all else being equal? Edit: In any case, I think the underlying jump-drive-type idea is a good one, lots of interesting possibilities with how it could work (or send you hurtling straight toward a gas giant on accident - whoops...!)

Is the issue of "using stock construction, dropped parts weigh 20 tons regardless of their actual weight" phenomenon a known issue? It happens when (for example), rather than placing a deployable science experiment via the correct method (the little place button in the lower right corner of the icon when it's in a kerbal's inventory), you do this instead: Enter construction mode Click on part from wherever it is (in a container's inventory, in a kerbal's inventory) Mouse over open ground near the constructing kerbal - part will appear orange (if not blocked) Click to drop part on terrain; part will drop, and about 1-2 seconds after dropping it, it will magically weigh 20 tons Quite annoying! The workaround of Cheats -> Ignore max weight for construction definitely lets you fix it, but... kind of janky

Cool, thank you!

Any luck with the b9 part switch + pick-up and re-place issue? I seem to remember some version of TS fixing this exact thing in the past...

Does Galaxies Unbound in any way alter the asteroid sizes or resource contents of asteroids/belts in the stock system, esp. the asteroids that tend to come into Kerbin's SOI? With GU + Lich + Alpha Centauri installed, I only see asteroids of a given class (like 'Medium' or 'Small' or whatever) that are MANY times larger than normal - up to (what appears to be) hundreds of meters across and weighing tens of thousands of tons. Without GU + systems installed, they go back to what seem to be more 'normal' sizes. The issue with this is that asteroid redirects are basically impossible with the bigger sizes - it's cool that they exist, but it seems like everything got multiplied by 10 or 50 or something, assuming GU actually does anything with asteroid sizes...

For those with the expansion packs, is it possible to add a check that detects their presence and adds all the IR parts to the stock Robotics category? Would be handy, but obviously not terribly important/crucial. I got the same error as stk2008 about multiple versions of scale_redist, perhaps because I have tweakscale installed as well; removing both scale .dlls from IR does not seem to cause problems *if* tweakscale is installed alongside, at least for now...

All of this is spectacular. The columns of clouds make me wonder whether the same volumetric magic could be applied to rocket smoke as well... +1 passenger on the eager anticipation train.

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