AccidentalDisassembly

Anyone else having this issue? For me, Better Time Warp Continued seems to mess with maneuver nodes while in orbit. DV requirements tick upwards, MechJeb can't figure out when/how much to burn, etc. A short google told me that this was an issue in a previous version as well - uninstalling BTW fixes the maneuver node issue, but I can't tell if it's some interaction with another mod (of which I am using too many to make it easy to check). Sorry for lack of log, already moved on with game. =(

One possibility: only use KRND for parts that you probably wouldn't tweakscale normally (like command pods or engines) - scaled engines tend to get a little funky, so my compromise was a patch to remove tweakscale from all engines and keep RND on engines (but not on fuel tanks, for instance). Seems to work OK for me.

Small issue that's probably only aesthetic: the RE-4 Buzzard engine's bell isn't aligned/symmetrical with respect to the the top attach node of the engine. Seems like the whole engine is offset a little to one side of that central axis.You can see this if you rotate the engine when attaching it. Probably doesn't matter, but if the engine transform matches the visual model and not the axis of the attach node...

Haven't had a chance to try that out yet, actually; I had started a new career, and now 1.3 has just come out! Distractions.

Really just the tiltrotors, so that you can still adjust one rotor's authority limit (tilt limit) and have it propagate to a mirrored part, without having them tilt when you press B (have to bind it to another action group, just don't want to also have to remember to UN-bind it every time) - if "none" is a valid option, then it's easy peasy: @PART[609prop] { @MODULE[ModuleAeroSurface] { %DefaultActionGroup = none } } I'll find out if "none" is an option shortly, just hadn't given it a try until now.

I think I see what you mean now, and wonder why deploy limits (for moduleAnimateGeneric, I think) don't propagate to mirrored parts in flight like they do in the editor... Do you happen to know what the range of possible values is for the DefaultActionGroup setting inside the moduleAeroSurface (or whatever) is? Could it be set to DefaultActionGroup = none? In which case I'd just make a patch that fixes it up for my own personal preferences. I didn't find any documentation of the possible values by Googling, though admittedly my Google-fu is not amazing.

FYI - in what I think (hope) is the latest version of the patches, MM says there are 4 errors in New_Parts/USI_Cargo_Switch.cfg. I looked a little, but could not figure out what the errors were, sorry.

Didn't know that about mirroring - seems like mirroring is just not one of the things that KSP does easily. =( With respect to the rotors - cargo bays and such have a "deploy limiter" that halts the animation at an arbitrary percent, could that not be used for the engines? It has the same effect on an animation (so far as I can tell) as the authority limiter for the airbrake module, but would require toggling the engine through an action group other than brakes (which would be preferable IMO - sometimes you just want the wheel brakes and airbrakes, and you don't want to change thrust direction, when you hit B). There seems to be some kind of collider funkiness with the tiltrotor as well - Maybe this has to do with the fact that it's an animated part (?), but when in default position, the collider for the blades is above the blades - you can see in this picture that the engine (which is upside down) causes the craft to rest off the ground visually:

Initial reaction: very cool new parts! The Size 2 cargo parts are mismatched, though, FYI. Floors are at different levels between the parts (compare the passenger door size 2 to the new Size 2 Cargo Bay CRG-15, for instance) - it seems to me the floor is placed too low / is too narrow on the new parts, and too high on the old ones, but that's just my "feel." Would be hard to make a 1.25m-based rover and not have the wheels be much wider than the floor bit... I think. EDIT: Also, the kitty turboshafts are automatically set to rotate on the brakes action group - this should not be default behavior. Not sure what that aero surface module is doing in that part. EDIT2: The node_attach on the new fixed landing gear are set with the wrong angle (if there are not node_attach-es defined, that would help the initial placement behavior).

Just checking on the engines - if they're not meant to push something supersonic (without AB), then they're not meant to! Just wondered if that was the case.

Just FYI - several parts' stack nodes have incorrect or missing size values. On the Size 2 Viewer's cockpit, for instance, the node looks like this: node_stack_bottom = 0.0, 0.0, 0.0, 0.0, -1.0, 0.0 While it should read: node_stack_bottom = 0.0, 0.0, 0.0, 0.0, -1.0, 0.0, 2 The parts I've found so far where this is the case: 1. Size 2 viewer's cockpit 2. Mk1 junior liquid fuel fuselage 3. Size 2 commercial cockpit 4. Size 2 droopnose cockpit 5. Mk1 Cargo Bay CRG-50-1 (nodes too large on this one) 6. Size 2 passenger door 7. Nosecone Mk 1 8. Structural fuselage S2 Balance-wise, the Cheetah turbofan seems to pretty much die after about 5000m and/or Mach 0.8 (thrust drops a lot; achieves max thrust at mach 0.7) and can't effectively push an Aeris 4a past Mach 1 or so. Is that intentional? EDIT: Tiger turbofan is similar, max thrust at mach 0.8, while stock afterburning turbofan has max thrust around mach 1.8.

FYI - in the dev branch NFT patch, there's this which throws an error: @PART[XE-100 Xenon Tank] (should be xenon-125-3, I think commented description and part name got swapped). I rewrote the config to be more manageable for my own personal tastes, removing maybe 1100 lines in the process - if you want to use it, you're welcome to: // ========== NEAR FUTURE CONSTRUCTION ========== // ----- Adapters and Docking ----- //Rockomax Skeletal Structural Adapter @PART[adapter-25-125] { %MODULE[TweakScale] { type = stack defaultScale= 2.5 } } //SE-4-OMNI Stack Multi-Adapter @PART[adapter-25-multi-01] { %MODULE[TweakScale] { type = stack defaultScale = 2.5 } } //SM- series stack adapters and radial stack adapter @PART[adapter-125-0625-*|adapter-rad-125] { %MODULE[TweakScale] { type = stack defaultScale = 1.25 } } //Rockomax Skeletal XL Structural Adapter @PART[adapter-375-25] { %MODULE[TweakScale] { type = stack defaultScale = 3.75 } } // S-MINI Radial Stack Adapter @PART[adapter-rad-0625] { %MODULE[TweakScale] { type = stack defaultScale = 0.625 } } //Grip-O-Tron Large Docking Connector @PART[docking-25] { %MODULE[TweakScale] { type = stack defaultScale = 2.5 } } // ----- Trusses ----- //Annular Trusses XL @PART[truss-circular-*] { %MODULE[TweakScale] { type = stack defaultScale = 3.75 } } //Modular Multipurpose Hexa-Girders @PART[truss-hex-*] { %MODULE[TweakScale] { type = stack defaultScale = 2.5 } } //Modular Multipurpose Octo-Girders XL @PART[truss-octo-*] { %MODULE[TweakScale] { type = stack defaultScale = 2.5 } } //Modular Spinal Trusses @PART[truss-spinal-*] { %MODULE[TweakScale] { type = stack defaultScale = 2.5 } } // ----- Batteries ----- //B-12K Rechargeable Battery Bank @PART[battery-25] { %MODULE[TweakScale] { type = stack defaultScale = 2.5 } } //B-6K Rechargeable Battery Bank @PART[battery-125] { %MODULE[TweakScale] { type = stack defaultScale = 1.25 } } //B-10K Rechargeable Battery Bank @PART[battery-375] { %MODULE[TweakScale] { type = stack defaultScale = 3.75 } } //B-3K Rechargeable Battery Bank @PART[battery-0625] { %MODULE[TweakScale] { type = stack defaultScale = 0.625 } } //B-800 Rechargeable Battery @PART[battery-rad-125] { %MODULE[TweakScale] { type = free } } // ----- Capacitors ----- //CAR-EXTRA Capacitor Bank @PART[capacitor-25] { %MODULE[TweakScale] { type = stack defaultScale = 2.5 } } //CAR-8K Capacitor Bank @PART[capacitor-125] { %MODULE[TweakScale] { type = stack defaultScale = 1.25 } } //CAR-1.6K Capacitor Bank @PART[capacitor-0625] { %MODULE[TweakScale] { type = stack defaultScale = 0.625 } } //Radial capacitors @PART[capacitor-rad-0625*] { %MODULE[TweakScale] { type = free } } // ----- Nuclear Bits ----- //MX-1 'Prometheus' Fission Reactor @PART[reactor-25] { %MODULE[TweakScale] { type = stack defaultScale = 2.5 } } //MX-L 'Excalibur' Fission Reactor @PART[reactor-25-2] { %MODULE[TweakScale] { type = stack defaultScale = 2.5 } } //MX-4 'GARNET' Fission Reactor @PART[reactor-125] { %MODULE[TweakScale] { type = stack defaultScale = 1.25 } } //MX-2 F.L.A.T. Fission Reactor @PART[reactor-375] { %MODULE[TweakScale] { type = stack defaultScale = 3.75 } } //MX-EXP 'KerboPower' Fission Generator @PART[reactor-0625] { %MODULE[TweakScale] { type = stack defaultScale = 0.625 } } //MF-1 Nuclear Fuel Drum @PART[nuclearfuel-25] { %MODULE[TweakScale] { type = stack defaultScale = 2.5 } } //MF-4 Nuclear Fuel Drum @PART[nuclearfuel-125] { %MODULE[TweakScale] { type = stack defaultScale = 1.25 } } //MF-7 Nuclear Fuel Drum @PART[nuclearfuel-0625] { %MODULE[TweakScale] { type = stack defaultScale = 0.625 } } //PB-AS-NUK Radioisotope Generator @PART[rtg-0625] { %MODULE[TweakScale] { type = stack defaultScale = 0.625 } } //Whirlijig Nuclear Reprocessor @PART[nuclear-recycler-25] { %MODULE[TweakScale] { type = stack defaultScale = 2.5 } } // ========== NEAR FUTURE PROPULSION ========== // ----- Fuel Tanks ----- //2.5m argon, xenon, lithium tanks @PART[argon-25-*|lithium-25-*|xenon-25-*] { %MODULE[TweakScale] { type = stack defaultScale = 2.5 } } //1.25m argon, xenon, lithium tanks @PART[argon-125-*|lithium-125-*|xenon-125-*] { %MODULE[TweakScale] { type = stack defaultScale = 1.25 } } //0.625m argon, xenon, lithium tanks @PART[argon-0625-*|] { %MODULE[TweakScale] { type = stack defaultScale = 0.625 } } //Radial argon, xenon, lithium tanks @PART[argon-radial-*|xenon-radial-*] { %MODULE[TweakScale] { type = free } } // ----- Engines ----- //0.625m engines @PART[ionArgon-0625*|ionXenon-0625*|mpdt-0625|pit-0625|vasimr-0625] { #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale]{} %MODULE[TweakScale] { type = stack defaultScale = 0.625 } } //1.25m engines @PART[ionArgon-125|ionXenon-125|mpdt-125|pit-125|vasimr-125] { #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale]{} %MODULE[TweakScale] { type = stack defaultScale = 1.25 } } //2.5m engines @PART[ionXenon-25|mpdt-25|pit-25|vasimr-25] { #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale]{} %MODULE[TweakScale] { type = stack defaultScale = 2.5 } } // ----- Lithium RCS thrusters ----- @PART[rcsblock-gridded-01|rcsblock-hall-01|rcsblock-mpdt-quad-01|rcsblock-mpdt-quint-01|rcsblock-mpdt-single-01|rcsblock-mpdt-triple-01|rcsblock-pulsedplasma-01] { #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale]{} %MODULE[TweakScale] { type = free } } //M-2 Cryogenic Gas Separator @PART[cryoseperator-25] { %MODULE[TweakScale] { type = stack defaultScale = 2.5 } } //AIReS Atmospheric Sounder @PART[gasspectrometer-01] { %MODULE[TweakScale] { type = free } } // ========== NEAR FUTURE SOLAR ========== //Blanket arrays @PART[solarpanel-blanket-*] { %MODULE[TweakScale] { type = free_square } } //NIV-18 Curved Solar Array @PART[solarpanel-curved-25-1] { %MODULE[TweakScale] { type = stack_square defaultScale = 2.5 } } //NIV-3 Curved Solar Array @PART[solarpanel-curved-375-1] { %MODULE[TweakScale] { type = stack_square defaultScale = 3.75 } } //SOL-A Expanding Curved Solar Array @PART[solarpanel-curved-deploying-25-1] { %MODULE[TweakScale] { type = stack_square defaultScale = 2.5 } } //Deploying and static panels, free_square type @PART[solarpanel-deploying-*|solarpanel-static-truss-*] { %MODULE[TweakScale] { type = free_square } } // ========== NEAR FUTURE SPACECRAFT ========== //LV-95-6 Orbital Maneuvering Engine Assembly @PART[orbital-engine-25] { #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale]{} %MODULE[TweakScale] { type = stack defaultScale = 2.5 } } //LV-601 Orbital Maneuvering Engine @PART[orbital-engine-125] { #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale]{} %MODULE[TweakScale] { type = stack defaultScale = 1.25 } } //LV-601-4 Orbital Maneuvering Engine Cluster @PART[orbital-engine-375] { #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale]{} %MODULE[TweakScale] { type = stack defaultScale = 3.75 } } //LV-95 Orbital Maneuvering Engine @PART[orbital-engine-0625] { #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale]{} %MODULE[TweakScale] { type = stack defaultScale = 0.625 } } // ----- Fuel Tanks ----- //FL-R-B3000 Monopropellant Tank @PART[monoprop-tank-25-*] { %MODULE[TweakScale] { type = stack defaultScale = 2.5 } } //FL-R-A750 Monopropellant Tank @PART[monoprop-tank-125-*] { %MODULE[TweakScale] { type = stack defaultScale = 1.25 } } //FL-R-C6000 Monopropellant Tank @PART[monoprop-tank-375-*] { %MODULE[TweakScale] { type = stack defaultScale = 3.75 } } //FL-T6000 Service Tank @PART[servicetank-25] { %MODULE[TweakScale] { type = stack defaultScale = 2.5 } } //FL-T9000 Service Tank @PART[servicetank-375] { %MODULE[TweakScale] { type = stack defaultScale = 3.75 } } // ----- RCS Thrusters ----- //RV-105x5 RCS Thruster Block @PART[rcsblock-aero-5way-1|rcsblock-orbital-2way-45-2|rcsblock-orbital-3way-1|rcsblock-orbital-4way-1|rcsblock-orbital-5way-1|rcsblock-orbital-linear-1|rcsblock-orbital-2way-45-1||||] { #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale]{} %MODULE[TweakScale] { type = free } } // ----- Structural and Utility Parts ----- //SD-01 Radial Engine Pod @PART[engine-pod-*] { %MODULE[TweakScale] { type = free } } //LT-POD Landing Assembly @PART[landingleg-pod-1] { %MODULE[TweakScale] { type = free } }

Don't think any hard-coding is going to happen, based on what I understand - think we're all talking about something that would be completely controllable via config files.

Just wondering - why does fusebox duplicate stock battery parts but not make any changes to them? They do appear in the editor (with editor extensions installed, I think) and they've all got the same part name...

Hmm, yes, I see your point - seems sufficient just to have one tech as a solution then. And it probably wouldn't be ridiculously hard just to make two different scaletypes (one for 1.25m engines, one for 2.5m engines, or whatever) if it turned out to be more effective for whatever reason. In which case it might be possible to make that process even easier by making TweakScale patches based on a part's bulkhead profile... it would rely on mod authors' rigorous application of bulkhead profiles, but it could radically simplify things as well... Hmmm....

RetroFuture used to have this kind of control surface, I think...

That would work in the same way as the first half of what I was throwing out there; the rest was an attempt to think through how it might work if scaling were limited by ratio rather than the list of scaleExponents. Then, the splitting of values with commas and semicolons was an attempt to think about how finer control (if that's even needed) would be achieved. One other thing that occurs to me and makes the creation of scaletypes annoying even if we have relative scaling values - a different set of techRequiredPlus and techRequiredMinus would need to be created for parts that appear at different places in the tree (maybe...) - and different patches again for someone using CTT or other tech trees. Is it possible to "read" the tech tree in-game and find "higher" techs? E.g. read the tech that unlocks the part, then read the techs that require that tech?

Maybe scaletypes could look something like this: SCALETYPE { name = stack freeScale = true defaultScale = 1.25 suffix = m scaleFactors = 0.1, 0.3, 0.625, 1.25, 2.5, 3.75, 5.0, 7.5, 10, 20 incrementSlide = 0.01, 0.025, 0.025, 0.025, 0.05, 0.05, 0.1, 0.1, 0.2 relativeScalingLimit { increment = 1, 2, 3 //meaning "up or down one, up or down two, up or down 3 from its default on the scaleFactors list" //Or, for more advanced control: increment = 1,0; 1,1; 2,1 //meaning "can go up one and down none; can go up or down one; can go up 2 and down 1" scaleMultipleLimit = 2, 3, 4 //// OR: scaleMultipleLimit = 1.5, 0.66; 2, 2; etc. //this value OR increment could be defined, but not both: this one would control ratios rather than use the scaleFactors list //value of "2" would mean "can be doubled or halved at given tech," value of 3 would mean tripled or reduced 2/3, etc. //could apply same kind of fine control in the alternative case, which would mean "can be 1.5x bigger or scaled down to 0.66x at minimum..." etc. techRequired = whatevertech1, whatevertech2, whatevertech 3 //names of techs that unlock each increment or ratio limit } } If what I wrote even makes sense... it might be nice as well if there were a way to override that limit on a per-part basis without having to write a new scaletype, but it might not be essential. So, for example, you could easily create a patch for all engine parts (let's say) that would add some variable, like "relativeScalingOverride = 1" that would only ever allow those particular parts to be scaled up or down one notch, no matter what the relativeScalingLimit says otherwise. Alternatively, it could be possibly simply to define only one value for "increment" within a scaletype, and make one scaletype for engines and one scaletype for everything else. That'd be pretty easy too. If it looked like this: relativeScalingLimit { increment = 1 //or increment = x,y *Or, alternatively:* scaleMultipleLimit = 2 //or scaleMultipleLimit = x,y } Then tweakscale could maybe interpret that to mean "never allow this part to scale up or down more than one increment in the list of scaleFactors applied to it." Same could be done using scaleMultipleLimit as a fractional value +/- instead, or something. Dunno if that's useful.

Yeah, that's my gripe too, and the reason I haven't already made a set of configs to make this all work =) I think that it must be possible to still allow complete flexibility of configs (specifying stuff however you want) while creating the possibility for a relative/ratio restriction for scales - maybe a setting within a scaletype that you can have (or not), rather than something inherent to how TS works, right? I dunno, not much of a coder and therefore not really sure how to help and/or think through how it would work in meaningful programming-ese. =(

The problem with the existing config interface is (I think, though there is a good chance I have misunderstood how things work currently) that the logic is very different from the intended result of the +/- limiters. Right now, I think, you can specify a tech required to unlock a particular size within a scaletype, right? This creates a slew of logical problems as a result of using the same scaletype applied to parts with different original sizes, ultimately. The only way to fix that - and you're right, it definitely could be done - is to create a big heap of different scaletypes for different scenarios. One scaletype for every size of part, really, and then possibly some extra scaletypes for special cases. Then, if you want to use a mod with non-"standard" sizes, like BlueDog or HGR or what have you, that means you have to re-do every single scaletype to accommodate new sizes. That is way too complicated. The logic of the +/- limiter is essentially "we get better at adapting any given design to different-than-intended sizes as we get better materials technologies" (or engine techs, or whatever), and it automatically adapts to any number of size increments the user wants to use. The difference is that it only takes a few adjustments to affect the logic of scaling for all parts - no need to write a complete set of custom scaletypes and re-patch every part in the game in order to use this logic. In addition, it also allows for more interesting possibilities regarding different types of part - for instance, the +/- limit makes a lot of sense for engines. It seems strange to be able to take a 3.75m engine design and scale it all the way down to 0.625m. But if there were logic built in to tweakscale that allows for control over the ratio you can scale a part to rather than the particular value in a scaletype... Again, a person could account for this with the existing config interface, but only by creating a big load of scaletypes and overhauled patches every part. Monumental amount of work vs. changing a few values in one setting in one config somewhere. That's my $0.02 anyway, and why I think it would be a useful feature. EDIT: probably even more useful if you can define limits (absolute or tech-based or whatever) by different modules present in a part...

To piggyback on this, a feature I requested a long time ago would accomplish a similar thing - it would be neat if a part could only be scaled X increments up or down from its defaultScale, within whatever scaletype it's using, until a particular technology was researched. E.g. a 1.25m tank could only be scaled to 1.875m and down to 0.625m until you research large-volume containment: then it can go +/- two increments in the scaletype, so still 0.625m at the bottom (or whatever is the lower bound), but now 2.5m or 3.75m at the top end, and so forth. Could be neat, but maybe a lot of work...

Just FYI - there is a long-standing issue with TweakableEverything and TweakScale for some kinds of parts. For example, with TweakableEverything applied to reaction wheels, rescaling a wheel will change the torque settings to negative values (in the right-click menu in the editor). After launch, the wheel will provide torque, but I can't really tell how much (compared to normal). If you simply scale a 2.5m wheel (for example) really large, then launch without messing with the torque sliders, it will not provide torque commensurate with its (rescaled) size. After scaling in the editor, you can then modify the values to give the part gobs o' torque, or whatever. However, after launching with a part that's been tweakscaled, returning to the VAB/SPH will result in a reset of the torque values to the range allowed by the unscaled version of the wheel. I don't have any idea if this is a TweakableEverything issue, or a TweakScale issue, just thought it could be useful to describe!

Hmm, in that case I am just going to take another guess at what's going on - since you have things transferring to a container, the experiment appears to ASS to be the same thing multiple times (same experiment, same biome, same trip?), and so only one copy is ultimately getting stored in the container. In that case, maybe you DON'T want transfers? I don't think ASS is set up to figure out how to store multiple goos (or whatever else) so that you can get a biome in one go... not sure about that, though.

Run-once experiments won't be reset unless the science is transferred out of them (like to a command pod). Double check to see that you've got transfer set up (right click on the icon in the toolbar, I think).

Nope, couldn't figure out how to make even 1 PR, sadly...