pellinor

Hmm, then it looks like the issue fixed itself. If you see no warning or exception, TweakScale should have done its things without running into problems. I just don't see how my code change should have fixed it (if the warning lines never get called). Never mind I didn't pay attention when reading. Will add a proper try..catch this time.

I read the issue as "it is ok that the timer counts down". Which implies that only the timer is wrong and the catch-up mechanic is supposed to clean things up when the vessel is focused again. So yours might be a separate issue.

I'll have a look. TweakScale only knows one degree of freedom, the scale. So I would consider two parts with the same size as identical (excxept for any persistent data other modules may carry of course).

Dev update: * set SRB thrust exponent to 3 (TWR and burntime are preserved now) * added a few null checks

I'don't see this in my game. Added a few null checks to the dev version: https://github.com/pellinor0/TweakScale/commit/d4dfd22f09b2047cb7f53cfeb99e5ac6140fcb88 You should now see a warning message. Could you tell me which one? And to the SRB topic: I have set their thrust exponent to 3 (in the dev version). So a scaled SRB should now be equivalent to several unscaled ones (burntime and TWR are preserved).

this is the fullest we have so far https://github.com/pellinor0/TweakScale/blob/master/GameData/TweakScale/documentation.txt this sounds like it needs more knowledge about testfight than about TweakScale

Doesn't happen for me, sounds like an installation problem or mod conflict. Something like realEngines maybe? Allista has written a module for anisotropic scaling for his hangar mod. This could also work for you.

They are not meant to be, the current default is a compromise between several things. Let's first note that the TWR of an engine (without any tanks) should be preserved for balance reasons, so mass and thrust should use the same exponent. The straightforward way of scaling engines would be to make the thrust proportional to the area of the nozzle (an exponent of 2). That would mean that the height of the fuel stack an engine can lift is preserved, which makes upscaled engines useless (light but too weak) and downscaled ones too strong (a tiny engine that is heavier and stronger than it looks). Also the density would scale too much which could result in unintuitive physics behavior. So the current exponent is 2.5. This means that you can not simply scale up a whole vessel an expect it to behave the same behavior. On the other hand the height of tanks you can stack on an engine increases with size ( sqrt(scale) to be precise ). I do think this is a good compromise for engines. But I'm also not really happy with SRBs, and don't find much use for scaled ones. Their weight is dominated by the solidfuel tank, so the mass exponent needs to stay at 3. We have a tweakable thrust limiter so increasing the thrust should not be much of an incompatibility. Finally I don't see much physical sense in the thrust values of the stock SRBs (other than to make them useful in different stages of the career progression), so there is no stock behavior to be consistent with. Yes, I think a thrust exponent of 3 makes sense for SRBs. Of course that also means that downscaled SRBs will get weaker. So anyone using them as sepratrons might like the old setting better. No, it would mean a lot of additional complexity and there are just to few models that look decent with non-isotropic scaling.

Release v2.3.4: * fix exponent for stock ModuleGenerator * found a way to write dryCost of the prefab early enough (fixes a cost issue with KIS) * functions to ask the prefab about stats of scaled parts (meant for KIS)

Thanks, fixed for the next release

I do find it: the name is "adapterSize2-Size1Slant". Yes a log would help since I don't see this with stock+TweakScale. Maybe a conflict with some fuelswitch mod?

Look into GameData/TweakScale/DefaultScales.cfg. ScaleFactors defines the available sizes, you can change or add numbers if you want. Just keep in mind that TweakScale might not work well together with part upgrades (if both change the same value they will probably overwrite each other).

This syntax works for me: @Kopernicus:FINAL { @Body[Sun] { @ScaledVersion{ @Light{ @sunlightIntensity = 1.5 @scaledSunlightIntensity = 0.70 }}} } The first seems to affect vessels and the second is for planets in map view.

Must have overlooked that. Thanks!

Is there a way to check if a vessel name is valid? I'm trying to write 'set Target to Vessel("name")' in a way that does not crash the program if the vessel name does not exist (because it is docked to something larger).

Dev update: * Found a way to write the dryCost of the prefab at an early time. This should fix a cost bug when dragging parts directly from the parts list into a KIS inventory. Sorry for overlooking your question. Short answer: in principle it should work like any other config value, but this is likely not what you want. From my (very limited) understanding of the thermal system, resized parts should withstand the same temperatures but have a changing thermal mass so they are easier/harder to heat. I have no experience with how BDArmoury works however.

I'm not aware of any such physics problems. Could you be more precise? And for "make TweakScale stock" I already wrote my thoughts:

This is correct behavior, and a known limitation of KIS. KIS refuses to stack a part if copies of that part can be different (because a stack only holds one part config). So stackability gets lost lost if you add stuff like resource nodes or a TweakScale module.

That file is about configs, those only determine the scaleability of parts. In this context "scale everything" means giving every part a TweakScale module.

It seems like I can't set a target when KSP is out of focus (on windows non-fullscreen with option -popupwindow, if that makes any difference). When called from a boot file while KSP is not the active window, the following code gets stuck until I bring the KSP window to the top. local count is 0. until HasTarget { set Target to tgt. wait 0. set count to count+1. } if (count>1) print "WARNING: setTarget: count="+count. It looks like only the "set target" is ignored while everything else runs normally. Is this a known limitation? I remember a discussion about input locks in the past, maybe this is related?

Not sure what examples you are referring to. You are looking for chain-scaling (LeftCtrl-K), this means if you rescale a part it will (try to) propagate that change to its children. This works recursively on whole subassemblies provided all parts in between are able to follow the rescale (I never use this so I do not have much experience with it).

Look into defaultScales.cfg, and add extra values to scaleFactors

Release TweakScale-v2.3.3: * recompile for KSP 1.2.2 * fix cost bug with fsfuelswitch (ignore resource cost because FSfuelSwitch takes it into account) * added a bit of documentation Known issues: there is are still cost issues in the interactions with fuelswitch mods (other than FSFuelSwitch).

I just had a look at IFS in the game and noticed a "dry tank cost" display that changed with the tank type. And wanted to mention that writing DryCost is a legitimate way to manipulate TweakScale from the outside (if the interaction problem is there). Dev update: * a bit of documentation (thanks to linuxgurugamer)

The basic design for cost scaling seems to be the following: (1) TweakScale calculates the dryCost of the prefab and uses its moduleCost to scale that (TweakScale::DryCost is the scaled value). Other partModules generally calculate their cost from their data fields, which are already scaled where apropriate. Therefore TweakScale does not try to scale their moduleCost. (2) TweakScale assumes that it is responsible for any change in resource nodes and compensates for that with its moduleCost. If another mod touches resource nodes on the same part we need to understand the interactions, and code exceptions for those rules where needed (I'll put this into the upcoming documentation for TweakScale): FSFuelSwitch: all interaction is done from the TweakScale side. The prefab part has no resource nodes, and the part cost is configured accordingly. So the dryCost is the cost from the part config and does not change when the tank type is switched. The resource cost is part of the tankCostList in FSFuelSwitch. This list is scaled by TweakScale, and the cost is applied by FSFuelSwitch. TweakScale does not do (2) if a FSFuelSwitch module is present on the part. MFT/RealFuels: unknown (Volume is changed via part message from TS to MFT, but I do not know how cost works). Currently MFT seems to apply resource cost twice (even when on its own), which makes it hard to tell if there is an additional interaction problem or not. InterstellarFuelSwitch: unknown (handled from IFS). @FreeThinker would it help if you overwrite TweakScale::DryCost with the one shown in IFS? ConfigurableContainers: unknown (handled from CC). Currently it looks like the dryCost is wrong because the prefab has its resources removed but its cost still includes them. @allista could you have a look at this? (and ping me if I should do anything differently on my side) B9PartSwitch: unknown (handled from B9PartSwitch).