AccidentalDisassembly

Yeah, that's one possibility - it was kind of a first try. But as a default behavior, you wouldn't have to write any tech patches with the system I was thinking of in my last post - only apply the TS module and make sure the defaultScale was correct. But it wouldn't stop you from doing exactly what you propose (by just doing what you've written). My more recent post had a better idea (IMO) than the first one with the ScaleUpTechs etc.

I see what you mean, and my particular solution is really just a stab in the dark. I also don't really understand what TWEAKSCALEBEHAVIORS do and how they could be applied to tech limits, so there's that... Maybe this can already be done with TWEAKSCALEBEHAVIORS, but I think you'd still have to write a very large number to account for mods, different tech trees, etc. - but since I don't know how they work, maybe I'm WAY wrong...! The underlying change I'm proposing can addresses exactly the problem you're describing. I'll try another example, maybe this will illustrate... Let's say you have 10 tech nodes in the game (T1-T10) and only one part (Part, 2.5m diameter). Part is unlocked at T3, and nodes T4-T10 all depend on unlocking T3, so they're in T3's "line" (or however it's called). If you allow TweakScale to consider 1) the tech node that unlocked Part, and 2) how many tech nodes beyond that node have been unlocked unlocked, then you could do this: T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 Part unlocks Part can now be incremented by one scaleFactor up and/or down (or two, or however patch defines). Therefore Part can be 2.5m, 1.875m (or whatever the next step down is), or 3.75m. Part's size can now be incremented by additional scaleFactor(s) up and/or down (controllable by how the patch is written for Part) etc. Now it doesn't matter how many scaleFactors there are, because TS is allowing the part to be scaled relative to its defaultScale, not linking specific sizes to specific techs. It's linking how much bigger/smaller to how much tech, and thus automatically takes into account the part's original size (defaultScale). Additionally, the user doesn't even have to know what techs are in the current tech tree (so modded tech trees just work, regardless of where the part is) - the degree of scaling is based on unlocking tech nodes relative to the part's own techRequired. If a user wants to control things more arbitrarily, that can be done right now (because of how inheritance works on SCALETYPES and such). If the part (still 2.5m) now unlocks at T6, as below, it doesn't matter, and the user doesn't even have to know that the part is in a different node now - they can simply define (via the original patch that applies TS to the part) whether the part can be scaled as soon as it is researched (and how much), how many additional tech nodes it will take to scale the part more (and how much more each node will allow), and so forth. T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 Part unlocks. According to settings, perhaps no scaling is allowed (yet). Or perhaps scaling up or down one scaleFactor is allowed even on unlock - however the patch writer determines it (on a part by part basis). Part can now be incremented up and/or down by one "stop" in the scaleFactors list Part can be incremented up/down two scaleFactors or can be scaled to any scaleFactor >= X and <= Y - if there are thousands of scaleFactors, include all scaleFactors between those values To address the problem of users creating any number of scaleFactors, maybe it is possible to have the scaling logic work like so: "Allow this part to scale up or down by X scaleFactors, but if that doesn't allow the part to scale to size Y, allow all scaleFactors until size Y is reached". Or, the entire thing could be based on ratios only, where additional tech unlocks a higher maximum multiple of the original part size (and therefore all scaleFactors comprised therein). Does that make sense? BUT: the specific way it works (how exactly tech controls scaling, which precise techs give what benefits, and so forth) is not what I'm trying to convey at the root. I'm just attempting to use arbitrary examples to show the underlying change in logic.The point I am trying to make is not to say that this specific system (one tech node = the part can go up and/or down one "size", or whatever) is good. The point is the relative logic that would make a system like this possible, as opposed to the current implementation, which requires a prohibitively large number of patches referencing specific tech nodes by name (and/or specific scaleFactors, and so forth). With that underlying logic, a lot of other stuff could be done using inheritance (kind of like how things work now) - like, for instance, writing some parameters in only one SCALETYPE (stack, for example) that effectively say: "No part with this scaletype can be scaled down to a size less than half its original size until <some tech> is researched" while the user could override specific conditions within a Part's individual TS patch (like you can do right now).

Noticed an odd behavior that I think is reproducible. Here are the steps: Fire up KSP, go into SPH or vab, place a CRFP tank. Mouse over the CRFP tank, press F for widgets, modify tank shape (does not matter how). Press CTRL-Z to undo modification - the modification reverts. Pressing several times walks backwards through the last modifications; this is awesome. Mouse over CRFP tank, press F - problem: widgets cannot be summoned until KSP is restarted. Switching to another scene (switch from VAB to SPH or vice versa) won't fix it.

The freescaling issue could be resolved easily no doubt. But for the rest, it's not an error in the code, it's simply the core logic of how TweakScale works with techs, which is not capable of doing things in such a way that would make sense in the game (unless you write a very large number of SCALETYPES and/or part-specific patches, and then another very large number of patches for every other tech tree (like CTT or one of the others), and every mod, and so forth - it gets insane very quickly). This could be a very interesting addition, actually - it wouldn't resolve the core issue, but I think it's a cool idea! Yes, one possible logic would be to go by groups of parts - but even then, the way TS works right now would make certain things very very difficult to implement (needing almost one SCALETYPE per part, functionally). Try this thought experiment: You have 5 engines (E125, E1875, E250, E375, E500) with diameters 1.25, 1.875, 2.5, 3.75, 5.0. They unlock at techs T1-T5, and there is another tech, T6, somewhere in the tree. You unlock scaling for these engines when you research T6 with this SCALETYPE: { name = stack_techlimited_forEngines defaultScale = 1.25 scaleFactors = 0.625, 1.25, 2.5, 3.75, 5, 7.5 techRequired = T6, T6, T6, T6, T6, T6 } This is not a problem if you are ok with how it works: All parts that have this SCALETYPE will all be able to scale to all of those values (0.625 through 7.5) as soon as this tech is unlocked. The moment you define different techs for each one of those scaleFactors, the resulting behavior for scaling certain parts become illogical in most cases. But what if you want to be able to scale E125 But now: what if T6 is a "miniaturization" tech? What if you want to make it so that all of these engines can be scaled down (and only down, and only one size smaller than their original size - which ranges from 1.25-5m - so that the "miniaturization" tech doesn't magically let you make 5m engines 0.625m? Now you have to write a new SCALETYPE for every size of engine. Then you could write a SCALETYPE for wing parts using a relative type (like surface, or free), not a big deal. But then - what if you don't want to be able to scale down really advanced engines (that appear at T7) until you research T8? New SCALETYPE for each engine size of advanced engines. And then - what if you want to be able to unlock engines progressively, letting you scale your earliest engines bigger and bigger the more advanced you get in tech, but NOT allowing your newest engines to be scaled really big or really small until you research a couple tech nodes beyond theirs? Now you're writing a SCALETYPE for each part size that occurs in each tech node. So if there were an additional logic introduced, where you could create limits relative to the part's original size and also relative to the tech node that unlocked the part, it would be a much more powerful and logical system in many cases, and a whole lot easier to write patches for. Only some of the problem can be solved by using scaletypes that are already relative (like surface or free), but that has an additional downside, namely that ratios are a lot more annoying to use than diameters with things like fuel tanks. Don't know if that will clarify anything...

There is an issue with how TweakScale deals with tech stuff, and it prompted me WAAAAAAY back before Lisias' time to request a change in how TS handles tech. Didn't get traction, sadly. But if you walk through what will actually happen if you define things like you're proposing, there is an issue because specific techs are tied to specific scaleFactor values, not to ***relative*** scale sizes. I will try to illustrate, please correct me if I am not understanding how this actually works. For the sake of clarity, let's assume there are only 6 techs in the game (Tech1-Tech6) and only 2 parts in the game (a 0.625m PartTiny, and a 5m PartBig). Let's also just assume that PartTiny gets unlocked when Tech1 is discovered, and PartBig gets unlocked when Tech2 is discovered. Now, assuming you use this: { name = stack freeScale = true //This here causes other problems with tech unlocking + scaling defaultScale = 1.25 suffix = m scaleFactors = 0.625, 1.25, 2.5, 3.75, 5, 7.5 incrementSlide = (doesn't matter for the purposes of the example) techRequired = Tech1, Tech2, Tech3, Tech4, Tech5, Tech6 } PartTiny unlocks at Tech1, but can't be scaled yet. Unlocking Tech2 allows it to be either 0.625m or 1.25m. However, because it can freeScale, It can most likely be scaled to 1.249999999 before unlocking Tech2 - not that big a problem, but it's a limitation of using freeScale in conjunction with tech unlocks. That makes sense - you discover the next tech (Tech2 is after Tech1), you get to scale the part. However, now you've unlocked PartBig at Tech2. When it is unlocked, the possible scales available to it are 5.0m AND 1.25m AND 0.625m - but only those 3 scales. You can see how that's a little funky. Then you discover Tech3, the scaleFactors available for PartBig will be: 0.625m, 1.25m, 2.5m, 5m. Specific techs allow specific diameters, not changes in diameter. In theory, the way a user would expect it to work is: a part can be scaled more and more (maybe only up, maybe up AND down, maybe only down, depending) the more tech nodes are unlocked after the part's own tech node. Or maybe the logic would be more similar to: "This part can't get smaller than it is right now (not than a specific diameter) until you unlock [Tech X]." Neither case can be covered by how TS works now without a huge number of custom patches. Using a different SCALETYPE (like surface, or free, or other types that aren't related to diameters) doesn't really fix the problem, because you still have to write scaletypes or patches for every flavor of part. The more parts you introduce, the more it breaks down: imagine a part that unlocks at Tech 6, but it's a 0.625m part, and you don't want it to be able to scale to 2.5m until Tech 7... Thus you have to define a very large number of SCALETYPEs (or unique patches per part, alternatively) to account for different parts of different sizes unlocking at different nodes and needing other, different nodes to unlock other sizes.... I think that it would be necessary to implement a different logic to handle things in the way the user would expect (go farther in tech tree = more options for a given part). Something like: Part's max/min scale = its original scale +/- one scaleFactor per tech node unlocked after (in the tech tree) its own tech node. Or you could make TS recognize something like this: @PART[thepart] { %MODULE[TweakScale] { %type = stack %defaultScale = 5.0 (or whatever) %ScaleUpTechs = TechNodeName, TechNodeName, TechNodeName... // first node allows one upward increment in the SCALETYPE, 2nd allows two, last unlocks embiggening completely %ScaleDownTechs = TechNodeName //If there's just one name here, then discovering this tech lets you do any scale < original // Or, if ScaleUpTechs and ScaleDownTechs aren't defined for the part, then it can scale freely from the start // Or, you could use a different logic, like: %ScaleUpTechs = 1 //One node after the part's node is required for each increase in scale defined in the SCALETYPE } } There are probably other (and better) ways of doing it than that!

Small FYI: in GameData\AirplanePlus\Spaces\zerointerior\internal.cfg, there's a missing closing curly brace at the end of the internal config. May or may not matter, just in case!

The APP parts are definitely compatible with KSP 1.9.x, they're just parts like every other part (most of them, at least) - and the patch is definitely a .cfg and I definitely fired up the right KSP. The patches do get applied to many parts, just not some parts... And if that patch works for you, it should work for me too! In theory. I just don't know what else in the directory could be interfering... EDIT: I found at least one error in the patch! Maybe that was it. Trying again. EDIT: Wow, I should have used my own error-checking tools. I missed a closing curly brace in the patch, and that was the issue. It is fixed in this file here (same file name and dropbox link as before, overwritten): https://www.dropbox.com/s/nqs7yv9tujqv7f2/TweakScaleCompanion_APP.cfg?dl=0

@Lisias - If you'd like, here is an AirplanePlus TweakScale config I wrote. It makes some assumptions about how parts should be scaled based on what the default TweakScale configs do with stock parts (mass exponents by part types). HOWEVER, for an unknown reason, despite looking like TweakScale's stock patches, my patches for APP engines and crewed parts do not seem to get applied - there are no scaling controls for these parts in the editor, but other parts (like wings, cargo bays, whatever) work fine. For reference, here's what the included TweakScale patch looks like for a stock engine chosen at random - this engine is scalable in the editor: @PART[miniJetEngine] // J-20 "Juno" Basic Jet Engine { #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = stack defaultScale = 0.625 } } Here's what an example of one of mine looks like - this is an identical format (except for the TWEAKSCALEBEHAVIOR, of course) to every other patch, most of which work - this engine is not scalable in the editor: @PART[S2APU]:NEEDS[TweakScale&AirplanePlus] { #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { } %MODULE[TweakScale] { %type = stack %defaultScale = 2.5 } } ...Whut? I should note that TS didn't provide any warning about these parts - only the standard 9 stock parts that fail sanity checks (because of variants). Log: https://www.dropbox.com/s/8i8zitff2zkq8db/TweakScaleAPPPatch_KSP.log?dl=0 Some APP engine parts use FSTextureSwitch (or meshswitch), but even engines that do not have any switchers also fail to get scaling controls in the editor... just in case that was an issue. Anyway, here's the config if you want to use it as a TweakScale Companion: https://www.dropbox.com/s/nqs7yv9tujqv7f2/TweakScaleCompanion_APP.cfg?dl=0

Was in 2.0.0.0, based on .version file

I am not sure if this issue is related, but using ReStock and ReStock Plus (latest versions) in combination with (I think... but not 100% sure) DMagic Orbital Science and also the newest DMModuleAnimateScienceGeneric download installed at the same time, such that there are 2 Dmagic Folders in GameData (DMagicOrbitalScience and DMScienceAnimate), creates an issue. I thought it was KRnD at first... It may also involve an interaction with Automated Science Sampler and [x] Science! too - and, while there are other utility mods installed on my test game, I don't think they're related to the issue... Whether or not the symptoms occur without ASS and xScience, they are readily visible when the two are installed, so they're helpful. Symptoms are: With RS/RS+ and DMagic Orbital and the new DMScienceAnimate and ASS and xScience, mystery goo and materials bay experiments *appear* to be collected (for example, you can right click on the parts and gather science, or you can use xScience's here and now function), but the experiments are not stored, and are also therefore not transferred automatically by ASS; they're then inoperable, there's no option to reset, and they register "No more samples can be collected" if you try to collect science from them via the right-click menu. Other, not-single-run experiments seem to collect and get transferred normally. The weird thing about this problem is that the issue goes away when either RS/RS+ or the new version of DMScienceAnimate is removed, but having both together makes some kind of problem. Anyway, I think it's possible to reproduce by doing this: 1. Install RS/RS+, ASS (normal download from ASS thread), and [x] Science!; use the most recent xScience DLL from the last page of the [x] Science! renewed thread. 2. Start career game with lots of funds and science, unlock appropriate science parts, put them on a craft, launch it on the runway (or probably wherever). 3. ASS will auto-collect (depending on how settings have been configured) everything but the mystery goo and materials experiments. Using [x] Science! here and now to collect mystery goo and materials won't produce any result; right clicking on the experiments and collecting will result in "No more samples can be collected." (I think). 4. Removing RS/RS+ will allow experiments to function as normal - or, alternatively, leaving RS/RS+ but removing the new DMModuleAnimateScienceGeneric.dll (which I got from here, I think: https://github.com/DMagic1/DMModuleScienceAnimateGeneric) will also return experiments' functions to normal (and allows ASS to auto-collect and transfer, and also allows xScience Here and Now to collect experiments) Here is a log where I go through that process with RS, RS+, Dmagic Orbital, this DMModuleScienceAnimateGeneric (https://github.com/DMagic1/DMModuleScienceAnimateGeneric), ASS and xScience installed: https://www.dropbox.com/s/s4t2nlbuct91mn9/KSPLog_ReSTcokScienceThingWITHrestocks.log?dl=0 Here is a log with the same setup where I start a game and do basically the same thing, but removed only RS and RS+: https://www.dropbox.com/s/oka0ahzlx0ys4hw/KSPLog_RestockSciencethingAFTERremovingRestocks.log?dl=0 Hope any of that makes sense.

Out of curiosity, is this kind of ERR message meaningful? Saw a whole heap of them in the ol' log (here: https://www.dropbox.com/s/76bt110xt5vjhar/KSPLog_TUError.log?dl=0)

Saw this business pop up in my log, don't know if it's meaningful: Log is here: https://www.dropbox.com/s/76bt110xt5vjhar/KSPLog_TUError.log?dl=0

Small FYI: in GameData\AstronomersVisualPack\AVP_Scatterer\Planets\Kerbin\atmo.cfg, there's a missing curly brace at the end of the patch.

Small FYI - In the file GameData\RealPlume-Stock\TantaresLV\delphini_us_engine_s1_1.cfg, the final patch is missing a closing curly brace at the end. Dunno if that actually causes problems, but... just in case.

FYI - both of these files are missing closing curly braces at the end (don't know if it makes a difference, but just in case...): ContractPacks\ExplorationPlus\ExplorationPlus-Orbit.cfg ContractPacks\ExplorationPlus\ExplorationPlus-ReachSpace.cfg

Does anyone happen to know of (up-to-date) contract packs involving BDA, e.g. "intercept this craft" style missions, or "go blow this thing up"? I tried to find and test some fairly old ones, but they did not seem to work (vessels didn't spawn, no waypoints, things like that).

AH! one other possibility: Does the patch need to apply to parts specifically with ModuleScienceExperiment? If so, there simply isn't a patch for that in AllYall.cfg, the only patches that I see that have "ModuleScienceExperiment" have to do with other conditions too (kerbal EVA stuff)..

I don't know if this is the issue with the MM patch, but it is one thing I noticed: Currently AYA_Science is being added to all parts that have any module whose name begins with DM* --- this seems risky, since it will capture DMModuleScienceAnimate and also DMMagBoomModule and DM...everything else. Maybe better to have DMModuleScience* or DMModuleScienceAnimate* instead. This *MIGHT* cause duplicates depending on exactly what order patches run in, because: This also may or may not be the issue, but for DMagic parts, there are two patches applying AYA_Science to DM* parts - one in AllYall.cfg, one in AllYall_Modsupport.cfg. Bonus, for me anyway - I did not know you could nest HAS: things in ModuleManager! Now I know.

Aha! I see that now. The issue was that the USI TweakScale patch acted after my custom one, which was meant to overwrite it; since the USI patch doesn't use the %MODULE / %defaultScale etc. etc. (instead simply adding a defaultScale or whatever), it creates a second copy. It seems to me that all TS patches (including bundled ones) should be written in the format: %MODULE[TweakScale] { %type = whatever //Add if no type exists; overwrite if it already exists } This would solve duplicate patching; the patch applied latest in the order would overwrite values rather than creating another TweakScale module. But then... it's not really the fault of the USI patch, of course! That would be mine... oops. With respect to the MiniAVC stuff - it is very frustrating that modders still bundle that with their most recent versions. Ugh. I deleted all the copies of MiniAVC I could find. Regarding the weird stuff with other DLLs, that is also very strange, since I just recently updated many of those mods and the DLLs listed in the errors are present in the appropriate directories in GameData... strange...

Gave this another try today - I opened KSP, started new sandbox, went into VAB, placed command pod, placed containers, then duplicated a few times, closed KSP. Here's a log: https://www.dropbox.com/s/mprtwdcovxmyyc1/KSPLog_TSDuplicationMaybe.log?dl=0 Here's a craft file I saved right before closing the program, in case that's useful: https://www.dropbox.com/s/qr9n8ak3u9o9aw6/TweakScaleDuplicates.craft?dl=0 EDIT: Oops, I should have said: KSP 1.9.1 with KSP Recall.

Sounds cool! Again, I don't actually know if that feature is *really needed* or anything, just something I thought could be useful. One note about the latest non-beta version of TS - I am able to reproduce a bug that goes like this: 1. Place part in editor that has FSfuelSwitch module switchable tank types. Scales fine. I used a Kontainer part from MKS; they have the FSfuelSwitch written into the part cfg. 2. Using ALT, duplicate the part and place. Right click on the new duplicate part. The duplicate will have two scaling controls (left and right arrows with scale size) in the right-click menu. Using the top control will still scale the part correctly (I think). The bottom control doesn't do anything, looks like. 3. So - seems like something is getting duplicated with the part when it shouldn't, maybe? Not sure if that's a known issue or not!

Additional FYI - in some patches, incorrect values are set for base volumes of things like ore tanks. For instance, in Oretanks.cfg, this is what's written: The @ refVolume *= 5 part makes all of these tanks hold 5 times as much ore as they should, since the refVolume is already based on the max amount of ore.

Not exactly - what I am suggesting is not really about cost or calculating cost, but I guess it would have an effect on cost if you wanted it to. Really, I'm just musing about a more versatile way for TweakScale to calculate what *any* value (like mass, wheel strength, rotation speed of a thing, resources consumed by a generator, whatever) becomes when the part is scaled up or down. NewValueWhenScaled = OriginalValue * ScaleFactor ^ ExponentDefinedInConfig --> Right now, this is the formula for changing *every* value that is easily modifiable by the user (mass, resource amounts, solar panel output, even the KIS inventory volume and number of rows/columns in the KIS Companion). I know that the exponent in this equation can be defined at every level (either by TWEAKSCALEEXPONENTS, or overridden by a SCALETYPE or even on an individual part's TweakScale Module). But: If "ExponentDefinedInConfig" could be a *mathematical function* rather than just a single numerical value, it would allow for more flexibility in the numbers you get when you change a part's size. With appropriate functions, this might also lead to more realism (I don't know), or maybe it would just prevent really weird values (like what happens now with engines sometimes). Example: What if the formula for an ISRU part's converter output could be defined as: NewOutputValue = OriginalValue * ScaleFactor ^ (1 + ScaleFactor/4) I don't think that particular equation makes any sense, but the point is that the exponent is a function rather than a numerical value. Interesting results might follow if (unlike me) you wrote a little function there that makes sense. For instance, maybe you could make the efficiency of an ISRU part (or whatever) go up or down *at different rates* depending on how *much* larger/smaller the part gets with respect to its original size. Right now, all you can do (without C#, apparently) is define the numerical value of the exponent - but maybe defining a function that determines that numerical value based on other factors, like scale, would be a useful thing to do. Truly don't know if that's the case, though. The point of doing that would be to simulate the idea that a thing like an ISRU part would get more efficient (per unit volume of the part) as it gets larger, but ALSO having diminishing returns on how much its efficiency increases as it gets scaled larger and larger and larger. Or, for example - in real life (I don't know, just supposing), I don't think it's always the case that fuel tanks weigh 8 times as much when scaled to 2x size in all dimensions. But once you get to an insanely large size, they might (because of materials science that I don't understand, or geometry, or something) increase in mass more than 8 times if scaled up again 2x in all dimensions. An example with arbitrary numbers: Original mass: 10 10 10 10 Exponent: 1 2 3 F(X) ScaleFactors 0.25 2.5 0.625 0.15625 0.8 0.5 5 2.5 1.25 3 1 10 10 10 10 2 20 40 80 41 4 40 160 640 260 With a part of mass 10, you can pick any exponent you want, and TweakScale will change the mass of the scaled part as shown (ScaleFactors at left, part mass in the other columns). Fine. But look at the fourth column: what if you want to produce this result? Here, scaling something smaller and smaller doesn't reduce mass fraction *as much* when going from 0.5 to 0.25 as it does when scaling down from 1.0 to 0.5. Or what if you want to make the ratio of mass to part size increase faster as it gets bigger and bigger? My understanding is that you can't produce this mathematical relationship as things stand, but maybe you could if you made this possible: TWEAKSCALEEXPONENTS{ name = Part mass = (1 - ScaleFactor) * (ScaleFactor/7 + 3) <-- The actual results of this function would be completely illogical. But the exponent is defined by a function , and so you can relate the exponent used to other things, like the ScaleFactor (the value the part's size is multiplied by), or whatever else could be interesting here.} The resulting equation used to set parts' mass (assuming it's not overridden by a SCALETYPE or an individual part's TweakScale module) would thus look like: NewValue = OriginalValue * ScaleFactor ^ ((1 - ScaleFactor) * (ScaleFactor/7 + 3)) Or, another way of doing it could be just to allow a config file to pass the entire function used to scale a value (like a part's mass) to TweakScale, rather than just the numerical value of the exponent inserted into TweakScale's built-in scaling function, like this: TWEAKSCALEEXPONENTS{ name = Part mass = mass * (ScaleFactor^2.8) / 4.7 - (mass^950)} That way of scaling mass for parts would also produce insane results, but the point is that TweakScale interprets this to mean: "When scaling a part's mass, use this mathematical function right here". Then you can put in whatever function seems most appropriate for mass, you could write a logarithmic function for Thrust, you could write any *kind* of mathematical operation - or, if you just leave a number ("mass = 3" or "mass = 2.75824" or whatever), it would work like it does now (so that patches don't break). Does that make sense? It's just an idea about changing how TweakScale is instructed to scale the different values it scales along with part size. It isn't specifically related to mass, I'm just using mass as an example.

EDIT: I should note that I don't actually know if this kind of change would be useful/necessary to deal with strange scaling values; it just came to mind when thinking about scaling stuff like wheels. Just throwing it out there. The current exponents system provides inherently limited control over how TweakScale modifies different values with the size of the part. This seems to be the cause of some absurdly light but strong parts when scaling down (like with wheels, or with engines that end up with TINY masses but HUGE TWR) - or, if associated exponents are changed so that scaling *down* works well, it results in funky values when things are scaled *up*. Just to confirm that I am actually understanding how things are working right now, an example - please correct me if I'm wrong (and here, I'm leaving out a bunch of stuff out and focusing only on mass for simplicity). Right now, the exponent system operates based on definitions like this: TWEAKSCALEEXPONENTS { name = Part mass = 3 } My understanding is: when a part is scaled by a value of X, mass becomes OriginalValue * ScaleFactor ^ ExponentDefinedInConfig (which is 3, here, for mass). Therefore: if you set mass = 3, doubling the size of a part means 8x the mass (OriginalMass * 2^3). But because of the equation governing scaling, this means that halving size reduces mass to 1/8, too (OriginalMass * (1/2)^3). You can change the exponent to mass=2, so that doubling in size means 4x mass, halving in size means 1/4 mass, etc. etc. - but you can only control how the part is scaled through this exponent (unless you write a specific config defining specific mass values at specific scales for specific parts, which you can do right now, but ... that's not going to happen for hundreds of parts). So: hopefully I have understood how things work now. But OriginalValue * ScaleFactor ^ ExponentDefinedInConfig doesn't have to be the only equation TweakScale can uses, in theory, does it? In order to create more useful equations for scaling different values, like mass, would it be possible to make TweakScale read and interpret *an equation* from the TWEAKSCALEEXPONENTS configuration data, then use that equation to scale a value (instead of an exponent inserted into an existing equation)? This equation could be defined in the .cfg file after "mass = ", if appropriate, OR a number could be provided, just like it is now -- if TweakScale sees only a number after "mass = " rather than an equation, it would simply use the existing formula (and no one's TweakScale patches would break). A few standard terms might have to be created so that a user could control how things scaled - things like "ScaleValue" (the value by which the size of the part is being multiplied), maybe "OriginalValue" (whatever the original number was for the resource/property/variable in question), and so forth. An illustration as an example - not saying *THIS* equation is useful, just how a config might look: TWEAKSCALEEXPONENTS { name = Part mass = mass * ScaleValue ^ 3 } That config would produce the same results as the current system - but maybe someone better than me at math could come up with an equation where scaling something up produces a bigger and bigger exponent, while scaling things down results in a smaller and smaller exponent, so that scaling things down doesn't produce insanely small masses, and scaling things up produces bigger and bigger masses (in proportion to size)... I just don't know what that equation would look like, unfortunately. The point is that appropriate equations could be developed (by people who understand how values probably ought to scale with size *in real applications, rather than according to things like the square/cube law*, while keeping them reasonable for the game) for different numbers that get modified by TweakScale. Or, things that currently scale appropriately (like volume-based things, e.g. resources) can simply be left alone, and will use the existing system of exponent definitions. Maybe an idea, anyway.

Question about the skybox - in AstronomersVisualPack/AVP_Skybox/Astronomers_Skybox.cfg, there's a reference that looks like this: SkyBox = AstronomersVisualPack/AVP_Skybox/skybox/AVP However, there's no folder skybox/ under AVP_Skybox - did I install something wrong? Don't see that folder in either AVPTextures or the main AVP download...