pellinor

The main function of TweakScale is to manipulate KSPFields (i.e. data members of partModules with the attribute [KSPField]). If a module can live with such a value changing on rescale (editor) and on vessel loading (editor & flight) then writing a small config is all it needs. The current config tries to do this for your slider values, but as far as I understand it occasionally works by chance and mostly messes up your internal state. There is also an API that allows to run arbitrary code on the rescale events. The TweakScale repo even contains some code that might do the trick for tweakableEverything. As far as I see it was never part of a release, so I have no idea if it ever worked. Probably my predecessor started but never finished it. From a first view it looks reasonable, so I'll see if I can get it to work.

TweakScale is as powerful as it is because it is generic. Someone codes a new engine module, and scaling support is as simple as writing a config. I'm fully convinced that hardcoding knowledge and assumptions about other part modules into the plugin would be bad design. Keeping TWR and fuel fraction constant can already be done with configs (see the ideas above), so the plugin does not need to know what "liquidFuel", "mass" or "thrust" means.

Some thoughts on this: * Telescopic pistons are not special in any way, the only difference I am aware of is that zodius made them for use with powers of (third root of 2), which is why they have their own scaletype. What does "they don't cooperate" mean? You could try adding ":FINAL" to the patches so they run last, and see if that changes anything. Just in case they tried to change something that was not there yet, or were overwritten by later patches. * I'd consider part patches like "@rescaleFactor *= 4" as problematic because adding or removing your config will likely break every affected part, scaled or not, both in the save file and in craft files.

I'd like to discuss the scaling exponents, particularly the scaling of mass. Please join me in the dev thread if you'd like to help cleaning up this part of TweakScale (more details there).

I postponed any discussion about scaleExponents until TweakScale is stable and KSP 1.0 is nearing. So now seems a good time to start it. The most obvious conflict is fuel tanks and engines: * Thrust should go with the square. * Tank volume should go with the cube. * Mass should scale such that a large part is roughly equivalent to several small ones (i.e. TWR and fuel fraction should be preserved). The current default is that mass scales with an exponent of 2.5, thrust scales with 2(ModuleRCS), 2.2(ModuleEnginesFX) and 2.6(ModuleEngines). DryCost scales with 3. So the conflict is solved by some sort of compromise, and nothing really scales neutrally. (for example tanks break the stock balance when scaled up) Ideas 0) Leave everything as it is. 1) Consider the mass exponent as something very individual and manually add TWEAKSCALEEXPONENT { mass = x } where needed (with default=3) 2) Define the scaleTypes in a 'sqare' and 'cube' flavour (i.e. stackSquare, stackCube, freeSquare, freeCube) 3) MM config to make everything with an engine module 'square' (might conflict with other MM patches, not suit some parts and miss out other modules with 'square' or other scaling) So far, I don't really like any of the ideas. Still the problem should be sorted out, and KSP 1.0 would be the best time for such a change. In my opinion 1) sounds like the most viable, even if it would be a ton of manual changes. Maybe I could hardcode to scale dryCost like mass per default (while still allowing cfg overrides) so we don't have a second exponent scattered everywhere. What do you think about the current situation and the proposed ideas? Are there better ways to sort the mass scaling? Also feel free to question other exponents (the complete collection is found in ScaleExponents.cfg).

new release! The pre-release is now official: v1.53

new release! v1.53 download address for version file added missing RLA configs only touch part cost of the part is rescaled fix for repairing incomplete scaletypes support for stock decoupling modules OPT support

To my knowledge it still works, but it needs a discrete scaletype. The idea of this config is to directly specify a value for each scale, which is not possible for a continuous range. What are you trying to do that does not follow an exponential scaling? - - - Updated - - - This tip is more than seven months old and does not explain what problem it is supposed to fix, so I have no idea what to make of it. Did you have any recent problems with tweakScale and B9?

This sounds like the "repairing scaleTypes that are not broken" bug. Please try the latest dev version, it should be fixed there.

You only need the GameData folder. The rest is Source code. I use this because Github already provides it, and it always points to my latest commit. Anyway, I don't expect that v1.53 fixes any bug like this from v1.52.1. If the part is the root part, the issue is known, and we can only hope for a fix in KSP 1.0. For non-root parts, I am still looking for a simple and reliable reproduction. The problem with 'realism' installs is that they usually contain a ton of mods and config overrides, and I'm not familiar with them. You also could look for exceptions in your logs. These can lead to code being skipped (even if they do not come from tweakScale). - - - Updated - - - I only know of parts reverting to their original size. If you see any size-jumping to a different value, I'd be even more interested in reproduction steps. For the puffed up rcs tank, can it be that it became the new root part when it was decoupled from the rest of the vessel? (you could check this by looking into the persistence file, search for the vessel name and check the first part following the vessel header)

Are you on v1.53 (see the TweakScale.version file)? There was a bug where TweakScale would ignore downsizing. It affected dev versions until April 9th.

Pre-Release v1.53: * added download link to version file * added missing RLA configs * support for regolith harvesting modules * don't modify part cost for unscaled parts * fix for repairing incomplete scaletypes * scale exponents for stock decoupler modules * basic OPT support As usual, the pre-release is a zip from gitHub, you only need the GameData folder. Please give it a try, I'll soon publish the update on kerbalStuff and curse if there are no complaints.

Pre-Release v1.53: * added download link to version file * added missing RLA configs * support for regolith harvesting modules * don't modify part cost for unscaled parts * fix for repairing incomplete scaletypes * scale exponents for stock decoupler modules * basic OPT support As usual, the pre-release is a zip from gitHub, you only need the GameData folder. Please give it a try, I'll soon publish the update on kerbalStuff and curse if there are no complaints.

Doesn't happen for me (clean install with the latest TweakScale and few other mods). My guess is that either something in your install is messed up, or some mod I'm not familiar with does not like TweakScale. Any exceptions in your log?

New in the latest dev version: basic OPT support.

The next TweakScale version will bring basic support for OPT (basic meaning no scaling of i/j/k parts yet). The only new partModule I found is the intake, the plugin code looks like the size should scale as an area. So I'll include it with an exponent of 2: TWEAKSCALEEXPONENTS { name = OPTRamIntake intakeSize = 2 } There is also a "compressor" dll, but I can't find any source code or part modules for it, so I suppose there is nothing more to scale. Please correct me if I'm wrong.

@toadicus: You use -1 to mark fields as not initialized (for example rollTorque in tweakableReactionWheels). TweakScale currently messes up your internal states by trying to scale this -1. Since all negative values are invalid states, it would be more robust to ask for "localField<0" instead of "localfield==-1". For making TweakScale and TweakableEverything work together, is there a kspField that I can scale to affect the tweaking range?

I'm quite convinced that TweakScale did no part moving when I reproduced the bug on loading (in the editor). So my guess is either procedural parts does the faulty moving or the position is already wrong in the craft file. I had a quick look at the procedural parts code and found some keeping of offsets that might conceivably get messed up if another mod unexpectedly moves nodes or parts. But that's just a vague idea at the moment. The strangest thing is that it also affects other nodes, but the error is always the top node offset. So if I put the quad coupler upside down and attach it with a bottom node, I get the same gap between the parts. It looks as if the top (or the first) node is somehow special, which is not apparent from the code. Update: the bug seems only to happen when loading a craft in the editor. When I reattach the part, save and launch, the position in flight stays correct. So my guess is that there is a translation done if (!flight), that should only be done when modifying some part but not on craft loading. TweakScale already works this way. In procedural parts, the call writeMeshes->Moveattachments->forceUpdate->doTranslation->target.Translate on craft loadigng seems to do the faulty translation. If I comment out "target.Translate", the quadCoupler stays in the right place on craft loading. Update: Created an issue for procedural parts.

The default for this has been OFF for at least the last two versions. You probably have remains of an older TweakScale version in your GameData. My guess is the xml file somewhere under pluginData. You can edit the autoScale/chainScale setting there (just deleting the file will probably also solve your issue).

I had a look at how KIS and TweakScale can work together. Here are the problems I found, and some ideas for solving them. Inventory Volume The available volume in the inventory can be scaled in the usual way. I tested the following config, and can include it in the next TweakScale version if you are fine with it. The slot size is a guess so far, I did not test that yet. @PART[KIS_Container1]:FOR[TweakScale] { MODULE { name = TweakScale type = free } } TWEAKSCALEEXPONENTS { name = ModuleKISInventory maxVolume = 3 slotSize = 3 } Part volumeOverride Can not be scaled like above because it is read from the part prefab. It might work if it is read from the part, and KIS expects it to change in the editor (so it would be read when the part is put into a container). Part Volume Scaling the volume of a part does not work out of the box. I see several possible ways to make it work: A) Provide the volume as a kspField in a part module, and TweakScale scales it with a config like the above. The field is scaled onLoad, or whenever parts are rescaled in the editor. I'm not sure how practical this is for values that do not come from the part config. When putting a part in a container, look for a TweakScale module and read the kspFields currentScale and defaultScale. Then the volume becomes (volume of the prefab)* (currentScale/defaultScale)^3. C) Use the TweakScale API to be notified on rescale, then update the volume accordingly. D) As far as I understand the TweakScale code, it scales the visual model by scaling part.transform.GetChild(0).localScale Maybe KIS can get the boundary box from the part instead of the prefab, in a way that is based on the 3d-model as it appears in the scene. Hologram Sizes The holograms are always the original size.

The numbers are in DefaultScales.cfg, feel free to change them. However, most textures already look horrible at 400%, so personally I have more fun scaling things down. - - - Updated - - - Good find. In the SCALEEXPONENTS I only find a moduleTweakableDecouple, but the stock parts have "ModuleDecouple" and "ModuleAnchoredDecoupler". I'll add those.

This sounds like a workaround to something that we haven't even tried to fix in the first place. So if you have a part that would need an unreasonable mass to allow good connections I'll find some time to look at how these connections can be tweaked.

Fixed the bug where TweakScale tried to repair scaletypes that are not broken: latest dev version. This should fix the issues with IR and LLL, not sure about RO (haven't checked it yet, and I'm not familiar with it).

Hi everyone, during the last weeks I was busy turning the IR codebase upside down, and with a vacation. Now I'll have a bit more time to give TweakScale the attention it deserves. Many thanks for the reports and reproductions, now those bugs look a lot more tangible. I'll work through the issues as I find time for it. - - - Updated - - - This is configured in ScaleExponents.cfg: TWEAKSCALEEXPONENTS { name = ModuleReactionWheel PitchTorque = 2.5 YawTorque = 2.5 RollTorque = 2.5 } So the torque currently scales with scale^2.5, just like part mass. TweakScale scales kspFields in partModules (if it finds a corresponding TWEAKSCALEEXPONENTS config), without any knowledge what those values mean. - - - Updated - - - Hmm, there is no scale exponent config for moduleLiftingSurface. Is anyone familiar with this module? The entry "deflectionLiftCoeff" sounds like it is responsible for lift, but 'coeff' sounds like it should be scale-invariant.

I also have TweakScale support for OPT on my todo list. Just won't find time for it until after the easter holidays.