AccidentalDisassembly

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.

New error to report, unfortunately - I don't know how to describe it (offset/placement issue), but I can describe how to reproduce it reliably. This is on a SLIGHTLY modded install with things like EEX, ClickThroughBlocker, etc. (utilities or enabler mods). Place pod and central tank in VAB as if building a rocket. Place decoupler in radial symmetry (part doesn't matter, just has to be insymmetry), then place another part (tank) on to the decoupler. Scale up the tank that was just placed on to the decoupler (but leave the decoupler alone). Now pick up *the decoupler* and re-place it in symmetry on the central core of the rocket (when it's picked up, it will pick up the scaled tank with it). Important to pick up the decoupler, not the tank that got scaled. When placed, the tank generated by symmetry (on top of the decoupler generated by symmetry) will be offset outward from its decoupler. If you pick up and re-place *the scaled tanks*, they will be repositioned correctly (as a workaround).

Just out of curiosity - I started playing around with JNSQ planets' radii to see what would happen. To make Kerbin slightly easier to ascend from (for instance), is it as simple as changing the "radius = X" value in Kerbin's .cfg file (in JNSQ_Bodies) to a slightly smaller number (maybe 1,500,000m instead of 1,600,000m, or whatever)? This seems to work in testing, but I have no idea how these numbers might be used by other mods or other parts of JNSQ. Would changing that radius value potentially break other things in unpredictable or unforeseeable ways (for someone with my lack of knowledge)? Kerbal Konstructs facilities, for instance? Or will most other things adapt automatically to whatever radius I set in JNSQ_Bodies/Kerbin.cfg? EDIT: If I were to modify the radius value via a patch (if this can be done), would I need to modify it at a particular stage of loading, or would :FINAL work, or something like that?

Made an issue here; hopefully explained how to reproduce it well enough that Squad will figure it out: https://bugs.kerbalspaceprogram.com/issues/27176

I should have thought to test on stock before, but now that I have - I observe (using the values reported by StageRecovery) the same behavior. If I place a parachute from the parts list only once, and it is replicated via symmetry, all of the parachutes *report* the same effectiveness in the editor. If I pick up the parachute from the craft, then re-place it (therefore re-replicating the parachute via symmetry), the effect of the parachutes on fall speed/drag/whatever are now *reported in the editor to be* different. TS not installed. So I can confirm now (and understand/see) what you mean - TweakScale seems to be picking up on the new value, then working with the new value (as it should!); stock KSP is wrecking something about either the stats of the chutes, the drag cubes, models, or whatever else maybe that affects parachutes' effectiveness, but that effect is only made visible (via StageRecovery) in the editor when parachutes are picked up and re-placed in symmetry. The effect is not read, or not visible, or what have you, when scaling up a part in the editor - only when picking up and re-placing. Another thing I noticed to confirm what you wrote - although *in the editor* the values for parachutes in symmetry that have *not* been picked up and re-placed are shown as the same (same fall speed via StageRecovery), like you, I also got different effects in the flight scene: the parachute created via symmetry is always more draggy than the 'original', even if they reported the same stats (whatever is getting picked up via StageRecovery) in the editor scene. So maybe something is happening in terms of calculations when the vessel is loaded into the flight scene, which also happens when the parachute is picked up and re-placed in the editor...? Or the editor scene or StageRecovery is just not reporting what's already there until the part is re-placed, I guess.

Huh, well then ... that's just bizarre. I wonder why the game is re-calculating WAY different values (or at least seems to) when you pick up a part and put it back down Maybe the values were already there, but re-placing reveals them...? Just bizarre. Thanks, Squad! If you don't pick it up and put it back down, I *think* it doesn't make for crazy different fall speeds, but maybe it actually does... I'll have to test this more too. "Lie" here is used in the expression "that's where the problem/issue/etc. lies" - not in the sense of tell falsehoods but rather in the sense of the problem resides there / is "lying" (laying) there, located there - I wasn't trying to accuse TweakScale of lying!

I appreciate the weird behavior of KSP in general, but did you try picking up and re-placing scaled-up parachutes? That's where the (possible) issue with TweakScale seemed to lie, because re-placing them produced massive and readily apparent differences in editor numbers (shown via StageRecovery) and in flight...

Reposting here from Github Issues, in case it's helpful: Unusual behavior to report with parachutes, TweakScale, and symmetry. I discovered this in an install with Stage Recovery, but I don't *think* StageRecovery is causing it - it does reveal the problem in numerical form, though. I *think* this can be reproduced by the following steps (I am able to reproduce it consistently on an install with a number of mods used for testing, e.g. toolbar, EEX, TweakScale latest, I think, Firespitter dll, etc.): In VAB, create craft, place decouplers in symmetry on the craft, place relatively heavy fuel tanks on the decouplers - I used rockomax jumbos. Using something heavy simply helps the problem become more obvious. Result: a rocket with boosters that will have parachutes on top for recovery, basically. Place any parachute on the boosters, also in symmetry - open StageRecovery window to ensure that the single parachute will result in at least some reduction of reported fall speed, and/or some percent of recovery (either stat will reveal the issue). With StageRecovery window still open, scale up the parachute any amount - the percent recovery and/or fall speed stats in the StageRecovery window will improve (slower fall or higher % recovery). Click on the parachute to un-place it, then re-place it on one booster (Booster A) still in symmetry; it will be mirrored onto Booster B. Booster A (where the scaled-up parachute was placed) will report a new fall speed/recovery percent that is close to, but worse than, the stats reported in the SR window before picking the chute up and putting it back down. Additionally, Booster B (the one onto which the parachute got mirrored by symmetry) will now report a much greater percent recovery / much slower fall speed. Testing in flight after picking up and re-placing the tweakscaled parachutes, the booster parts with the chutes DO fall at the (different) speeds reported by StageRecovery - so I assume that StageRecovery is not causing the problem, but instead accurately reporting the new effects of the tweakscaled parts. Log on Github issue.

Threw a couple easy-to-fix issues up on the github in case you don't receive notifications for it! Some quick fixes with brackets and two duplicate patches that can be removed from squad patches (Control.cfg).

Small note: there's a missing opening curly brace on the second patch (@PART[opt_vtol_jumpa*|opt_vtol_bubble*|opt_vtol_egg|opt_vtol_heli*]:NEEDS[KerbalActuators]) in GameData\OPT_Legacy\Patches\KerbalActuators.cfg, just FYI! EDIT: Additionally, there's a double " or" bar in this patch: @PART[AAengine|turboRamJetj_60d||opt_vtol_lpr1]:NEEDS[RP-0] in GameData\OPT_Reconfig\TechTree\OPT_RP0.cfg.

Hello! Small note about configs - each of the following configs has a mismatched number of curly braces, which appears mostly to be the result of a missing closing brace at the end of the file: Check {} in C:\Games\KSP_win64\GameData\ContractPacks\PWP\Milestones\100.cfg Check {} in C:\Games\KSP_win64\GameData\ContractPacks\PWP\Milestones\2500m.cfg Check {} in C:\Games\KSP_win64\GameData\ContractPacks\PWP\Milestones\AtlasII.cfg Check {} in C:\Games\KSP_win64\GameData\ContractPacks\PWP\Milestones\AtlasIII.cfg Check {} in C:\Games\KSP_win64\GameData\ContractPacks\PWP\Milestones\Gilly.cfg Check {} in C:\Games\KSP_win64\GameData\ContractPacks\PWP\Milestones\Jool5.cfg Check {} in C:\Games\KSP_win64\GameData\ContractPacks\PWP\Milestones\LandOnMinmus.cfg Check {} in C:\Games\KSP_win64\GameData\ContractPacks\PWP\Milestones\ReachSpace.cfg Check {} in C:\Games\KSP_win64\GameData\ContractPacks\PWP\Milestones\That'sOneSmallStep!.cfg Check {} in C:\Games\KSP_win64\GameData\ContractPacks\PWP\Stunts\BarnstormRnDBridges.cfg EDIT: Jool5.cfg in particular has *many* missing curly braces, such as on PARAMETER{}s - just a heads up.

If I remember correctly (you can look it up in the TS configs somewhere), 2x engine dimensions = roughly 4x the thrust but 8x the weight (thrust as a function of nozzle surface area, weight as a function of volume). However, those scaling factors might have changed since the last time I looked...