AccidentalDisassembly

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...

Hooray, it works! Thanks!

Is this meaningful? Why is there a DLL included with the NF companion, anyway...? Trying to figure out what exactly is preventing me from loading KSP..

I'm not sure I understand the first part of that, was the < in red supposed to be >? If so, yep, that's what I was thinking - I guess another way of conceiving of the "increase hyper warp by Y" would be to allow the user to define a list rather than one specific increment: Like with better time warp continued (I think), the user could define the specific multipliers for slow-motion and hyperwarp that are chosen/switched to when pressing the < and > keys. For instance, a user might want very fine control over warp between 0.5x and 1x, but only one jump from 0.1x to 0.5x: perhaps a list such as <---0.1x, 0.5x, 0.6x, 0.7x, 0.8x, 0.9x. [1x - turned off], 1.2x, 1.5x, 1.8x, ... ---> with whatever number of increments the user wants. Or, a user might want to have to press only a few keys to go from standard stock-alike speeds of 1x, 2x, 3x, and 4x, to ludicrous speeds - maybe they could set up their list of warp factors to be something like: <--0.25x, 0.5x, 0.75x, [1x - turned off], 2x, 4x, 8x, 15x, 27.5x, 66.29x--> If the user can also define the physics factor to use at each of those speed multipliers, then physics accuracy could be turned down at the same time to allow for the insane speeds like 27.5x physics warp and whatnot (sort of kind of similarly to how you can, right now, bind "decrease physics accuracy by Y" to the same key as "increase warp factor by Z"). Not sure if that makes sense. Either way - the way you describe, or a more custom "list" would be fantastic if it could essentially mimic the behavior of the stock system (1x is turned off, > turns it on and speeds things up, < slows it down or, if you slow it down past 1x, it goes into slow-mo, which is I think what we're both thinking)

I don't think you can have two things in FOR[], but I'm not sure about that... Secondly, be very careful with :FOR - if you use it, it tells ModuleManager that those things are installed! My understanding is that you should never use FOR unless there is a very good reason to do so.

Ah! Looked in the config. I think maybe it's just because that one part doesn't have a "tags= ...." entry in the config, that's all.

I didn't even know you could do that with MM! Interesting. Glad I got in the ballpark of the problem at least. One small note about the most recent version, just noticed as I was taking it for a spin (loads fine!) - one cockpit is not successfully captured by the category:

@JadeOfMaar --- With the new OPT Reconfig, KSP also hangs while loading for me - on part h_2m_em_fm. While looking through the patches to figure out what was going on, I notice one instance of empty OR pipes in a module manager patch ("||") that may or may not cause problems.: MainUtilities.cfg, line 146. Or not, I don't know. However, the real issue is with OPT_CCTanks.cfg. Two things: It applies a CC patch to h_2m_em_fm (and other parts) even if the user hasn't installed CC but has installed any other AT mod, because ConfigurableContainers DLL is packaged with AT_Utils, unfortunately, so it's always there if the user has installed something like Ground Construction. The patch leaves a variable in the ModuleTankManager module that causes the hang. Blue stuff is a suggestion, red stuff is what seems to be the problem: Anyhoo, disabling only OPT_CCTanks.cfg lets me load, so... probably the Tag bit? EDIT: I just realized - are OPT_Legacy and the other OPT interoperable? I always thought they were mutually exclusive, because one was called.. well.. legacy!

Okie doke! Two small things I noticed in the APP Companion so far: There's an empty plugins directory - not really a big deal. In AirplanePlus_Utility_TweakScale.cfg, three parts are engines - they could be moved to the engines config, and they might need the "#@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }" : S1APU S1p5APU S2APU That's all I've seen so far!

In case someone hasn't reported it - the J Edgar VTOL engine is missing a node in one of its variants. The following SUBTYPE needs the green bit to be added: SUBTYPE { name = #LOC_M2X_JedgarF transform = Engine_base transform = Fairing transform = Pivot node = bottom node = top addedMass = 0.25 } EDIT: Also, I think the Fairing transform needs to go to the variant above it... Possibly. No fairing appears when attaching a part to the engine using the variant with 1/2 structure and a free stack node in the rear.

Small suggestion for the next version - in Zs_ProbesBeforeCrew.cfg, the patch that creates the telemetry experiment applies it only to un-crewed parts. However, contracts generate requests for that experiment for all sorts of situations, including things like "send a scientist here and perform telemetryReport". It stands to reason that a crewed capsule should be able to send telemetry too, no need for an additional probe core on the vessel. So: @PART[*]:HAS[@MODULE[ModuleCommand],#vesselType[Probe]]:NEEDS[CommunityTechTree] <-- Deleting that would be a convenience! { MODULE { name = ModuleScienceExperiment experimentID = telemetryReport etc. etc. } } Just a thought.

Hi @Lisias - I'll take a look at the APP tweakscale when I get a chance I am having a strange behavior with the combination of TweakScale and Stage Recovery. From memory, I am reasonably certain this can be reproduced with only TS and SR installed (and KSP recall and whatnot, on 1.9.1), but I have not verified that. I should say: I don't know whether this has anything to do with TweakScale, so... sorry if it's a Stage Recovery thing instead. Here's what happens: Using symmetry, place a non-scaled parachute on a part (like a booster nose, in the image below). Stage Recovery calculates a velocity in m/s for both boosters. Scale up the parachute. When you do this, Stage Recovery calculates a new value... HOWEVER: The calculated value changes if you pick up the part, then place it again, and If you pick up the part and place it again, the calculated values will be significantly different for the two parts/assemblies in symmetry, like so: (The NC-02R is renamed by Community Parts Titles, here, and the other one is simply not visible, hidden on other side of the right-hand booster) Is this TweakScale somehow upscaling the part somehow again when picked up and placed after scaling the first time, or is this Stage Recovery reading a weird value...? I don't know for sure whether this has any actual consequence in game, either, or whether it's just a quirk of the VAB...

Small suggestion for the UI - TimeControl's warp is by far better than stock warp, so far as I can tell. Would it be possible to make a setting where the stock time warp controls (, and .) activate hyperwarp using the same kind of behavior as stock? For instance, if hyperwarp is turned off, pressing "." once turns it on and sets the speed to 2x; pressing it again increases to 4x (or any number of steps/intervals defined by the user)? At the same time, it would be good to be able to bind increase/decrease physics accuracy to those same keys (as is possible right now with custom hotkeys). By the same token, it could be possible to simply include slo-mo in that scheme, such that pressing the "," key while at 1x physics warp turns on slow-mo, etc. If Time Control can't replace the stock physics warp, it would be great to be able to include the on/off behavior of stock timewarp, like this: Instead of replacing stock warp, set custom keys for warp actions, as is possible right now Also allow an option for turning on hyperwarp when the custom key to "increase warp" is pressed, and turning off hyperwarp when you've decreased it back down to 1x (So, basically, emulating the stock behavior of the , and . keys for turning on/off timewarp, but attaching that behavior to custom keys, if the stock system can't be replaced) This would be nice primarily because you can avoid having to have an extra hotkey to activate and deactivate HW, and also avoid forgetting what setting you had left HW at when you turned it off, only to turn it on (via hotkey) and suddenly find yourself in 20x physics warp while pointed at the ground... Whoops. Hope that makes sense.

Well, these work 100% better than the ones I tried - maybe I goofed by not removing TweakScale or something. One thing I do notice is that the patched stock gear jitter and bounce around quite a lot (under certain circumstance I can't figure out, but not all the time) while stationary or moving, have you noticed this as well? EDIT: For kicks, tried patching the RoveMax XL3 - results in the image. No clue why the top suspension part thing is scaled down due to the KF patch (unpatched stock part on the left for reference). Mysteries.

Just a heads up - In an upcoming version of SCANSat, it appears all the part names are changing, and old parts won't be researchable... In ContractPacks/KerbinSpaceStation/BaseMissions.cfg, on line 78, there's a reference to one of the old part names - I *think* that the new equivalent part name (the lowest-tech SAR scanner) is scansat-sar-paz-1 (as opposed to SCANsat_Scanner2). However, I'm not exactly sure how the new parts are going to function; I just happened to run into this when testing things out.