pellinor

I need to officially retreat my complaint because there already are config options to remove the need for screwdrivers. Pretty sure that I already tried this and did not get it to work, must have been an error on my side. @KISConfig[KISConfig]:FINAL{ @EvaPickup { %allowPartAttach = true %allowStaticAttach = true %allowSnapAttach = true } } However while digging through configs I found something else to discuss (from settings.cfg bundled with KIS): StackableModule { moduleName = TweakScale // mod } My understanding of this whitelist was always that it is supposed to protect KIS from messing up persistent data (like the fuel amounts in tanks). TweakScale is a prime example of persistent data: stacking parts of different scale makes them the same, which messes up size, mass, cost and whatever else. @IgorZ could you clarify the sense behind this?

Pretty unlikely because TweakScale does not touch that direction. Are you aware how KSP chooses this direction? It depends on where the part is with respect to the CoM of the vessel (and both of these things can change by scaling). Can you show a picture of a behavior that is clearly wrong?

My favorite would be a way to say "glue a screwdriver to every kerbal skilled to use it". Like I do a one-time payment for all of them and then never get to see an engineer without his tool again. Especially with screwdrivers, my peeves are that * they are easy to forget (saved vessels tend to forget their passengers, and they might end up on different seats next time) * Kerbals tend to lose them inside inflatable parts * spares take lots of space because they are not stackable * once they are unlocked, I see no reason to ever send an engineer without one. This is the most important one because it makes the concept feel like artificial difficulty.

Usually you can override exponents in the part patch, but it does not seem to work with resources (probably caused by some special handling in the code). So I don't see a simple way right now.

I have added a first implementation to the dev version: https://github.com/pellinor0/TweakScale/commit/04c7b256c7d52448802c2fb967e82236ecfc04f2 So far I add the rescale factor when(if) the part scale is changed, and TF seems to accept the call (it returns true if called on a fuel tank). Could you have a look if this works as intended? If I understand things right then the "value" should be coarse grained (not done yet). Currently I do not call the interface if the part is unscaled, so some parts will get that value while others won't. Added a catch block, could you try if you see something more useful now? It would also be useful if you could narrow down which of your mods is triggering the problem.

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

I'd add one more thing * a large balance pass over all his parts using a giant spreadsheet to make part size, mass and abilities more consistent. So he would be a good person to do the same with the stock parts.

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.