AccidentalDisassembly

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.

Not sure what you're referring to; I am aware that the stock patches on the github repository aren't supported, hence they don't work, hence why I tried rewriting them myself. @Citizen247 indicated in his post that s/he was writing patches for the stock parts, and I was curious to know if he had has luck with the stock patches s/he was writing or already wrote.

Have you had any luck with the stock patches? I've tried the ones I found on the Kerbal Foundris github, and they don't seem to function. Meanwhile, I've tried rewriting them myself, but I can't get the retractable landing gear to , well... retract, or steer/sit on the surface of the ground/rotate... Ugh.

Unfortunately I don't know of any contract packs that spawn vessels... maybe this is why! I did see that Vessel Mover has a method for spawning vessels in the flight scene that works (I tried it), I don't know if maybe that could be incorporated into CC... then remains the problem of figuring out how to get the game to activate BDArmory's autopilot and Wing Commander commands (e.g. telling the plane to go to guard mode and move to a point, attack near a point, etc. like you can when controlling a craft or group of crafts)...