[1.4.x] TweakScale v2.3.12(Apr-16)

[pellinor]

TweakScale lets you change the size of a part. Not just that, but it will figure out how much fuel is in the resized part. And if it's an engine, it will become more powerful by scaling it bigger, or weaker by scaling it smaller.

Download: SpaceDock / Curse
Source: Github

A bit of Documentation

Latest dev version (WIP stuff, might contain bees)

See also the development thread for the latest unreleased tinkering.

TweakScale was originally developed by Goodspeed and Biotronic. [original release thread]
Source: Github
License: WTFPL

Known issues
* stock upgrade mechanic not supported yet
* CrewCapacity: removed seats in the editor sometimes reappear
* CrewCapacity: launch dialog of the pad/runway shows unscaled seats [stock limitation]
* particle effects are not scaled [stock limitation]
* unloaded relay antennas use their unscaled range [stock limitation]
* (see also https://github.com/pellinor0/TweakScale/issues)

Changelog

v2.3.12
* configs for new parts
* fix for exceptions
* fix for solar panels
* recompile for KSP 1.4.2

Spoiler

v2.3.9
* recompile for KSP 1.4
* support for new stock ModulePartVariants
* a few patches for new parts

v2.3.7
* recompile for KSP 1.3.1
* only complain about negative dry mass if the number is significant

v2.3.6
* recompile for KSP 1.3
* lots of player-submitted patches (thanks eberkain, mikeloeven, OliverPA77)
* set SRB thrust exponent to 3 (so both TWR and burntime are preserved now)
* added a few null checks
* scaling support for resource lists (for drills and converters)
* Fix: don't scale mass if the part has a MFT module
* TWEAKSCALEEXPONENTS should now affect not only the mentioned module but also derived modules
  (e.g. the exponent for ModuleRCS also applies for ModuleRCSFX)

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)

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

v2.3.2
* recompile for KSP1.2.1
* update patches for RLA-Stockalike, OPT
* exponents for ModuleRCSFX
* remove an obsolete exponent
* remove patches for relay antennas since scaling of their main function does not work
  (which is relaying signals when the antenna is part of an unloaded vessel)

v2.3.1
* exponent for groundHeightOffset (fixes landing gears clipping the runway at launch)
* fix for node positions reverting when cloning a part
* antennas: refresh range display
* antennas: tweak exponent (so that downscaled antennas are a bit less overpowered)

v2.3
* fix for wheel colliders
* fix wheelMotor torque and ec consumption
* CrewCapacity: has a configurable exponent now
* CrewCapacity: additional seats are not shown in the editor (stock limitation)
* scaling support for FloatCurve (for wheel torque)
* scaling support for and int values (for CrewCapacity)
* fix scaling of input/outputResources (new stock "resHandler", e.g. consumption of reaction wheels)
* move workaround for stock UI_ScaleEdit bug into the plugin

v2.2.13
* recompile for KSP 1.1.3
* fix for solar panels
* rewrite of chainScaling: propagate relative scaling factor to child parts

v2.2.12
* scaling of crew capacity (hardcoded to use the mass exponent for now)
* Fix patches scale crewed parts with an exponent of 2 for crew and mass
   (not realistic but fits better to stock balance than 3). In any case mass/kerbal is hardcoded to be preserved.
* scaling of the IVA overlay
* support for new firespitter biplane
* support for HLAirships module (thanks SpannerMonkey)
* some missing patches for B9 (thanks BlowFish)
  (did some reordering but still need to sort through the content)
* fixed a few patches
* reorganize some patches into their own folder
  (B9, Squad including nasa and spacePlanePlus)
* small optimisation: disable partModule in flight if not scaled

v2.2.11
* remove obsolete IFS exponents
* fix bug in partMessage for MFT
* expose API via the part message system
* fix for mirrored parts
* workaround for tweakable bug: extra scaleFactor 500% for the free scaletypes
  (so the range from 200-400% is usable again)
* don't interfere if other mods illegaly write part.mass. Print a warning in this case
* fix thrust for moduleRCS (new maxFuelFlow exponent like for moduleEngines)

v2.2.10
* basic wheel scaling: scaled wheels work but still behave strange. They roll, are pretty close to touching the ground, and are able to bounce.
* make sure the exponents are applied before notifying other mods through the API (needed for interaction with FAR)
* MFT support changed to TweakScale using their API (instead of the other way round)
* tweaked downscaled science parts to be a little more expensive

v2.2.9
* fix for drag cube scaling
* update right click menu after rescale
* recompile for 1.1.2
* cleanup for mass scaling

v2.2.7.2
* fix scaling of the root part

v2.2.7.1
* update for 1.1
* Workaround for the camera breaking (root part scaling is still broken)
* support for new stock parts
* shrinking science and probe cores makes them more expensive
  (only changed for stock so far)
* update for the OPT v1.8 test release

v2.2.6
* Support for NF-Construction
* update for NFT Octo-Girders
* fix for infinite loop between TweakScale and MFT
* fix for engineer's report mass display

v2.2.5

* recompile for KSP 1.0.5 (still using the old KspApiExtensions)

* update MM

* patches for the new parts

v2.2.4

* Fix for scaling of lists. This should fix the trouble with cost of FSFuelSwitch parts.

* Partial fix for editor mass display not updating

* new file Examples.cfg with frequently used custom patches

* Removed MM switch for scaleable crew pods

* update of NFT patches

* Fix scaling of resource lists

* support for a few missing stock parts

* partial support for a few other mods

* stock radiator support

* Scale ImpactRange for stock drill modules (this is what determines if the drill has ground contact or not)

* scale captureRange for claw (this should fix 3.75m claws not grappling)

* removed brakingTorque exponent (not needed and breaks stock tweakable)

v2.2.1

* update for KSP 1.0.4

* KSP 1.0 support: scaling of dragCubes

* exponent -0.5 for heatProduction

* support for HX parts from B9-Aerospace

* support for firespitter modules: FSEngine, FSPropellerTweak, FSAlternator

* remove support for KAS connector port so it stays stackable in KIS

* a few missing part patches

* update NF-Solar patches (some parts were renamed)

* catch exceptions on rescale

* survive duplicate part config

v2.1

• 
  * recompile
  * new stock part

 

v2.0.1

• restored maxThrust exponent to fix the editor CoT display
• added patch for new KIS container
• survive mistyped scaleTypes

 

v2.0

• recompile for KSP 1.0
• new TWEAKSCALEBEHAVIOR nodes (engines, decouplers, boosters)
• scale DryCost with the mass exponent if there is no DryCost exponent defined
• seitch for scaling of crewed parts (defaults to OFF)
• fuel fraction of tanks is now preserved [breaking]
• move part patches into their own directory
• KIS support
• proper MM switches for mod exponents
• removed KSPI support (will be distributed with KSPI)
• scaleExponents for NF-electrical capacitors
• cleanup of stock scaleExponents
• support for the new stock modules
• support for the changed engine modules

 

Full version history on *

 

 

Please add TweakScale to your mod!

Spoiler

If you are a mod author and you want to bundle TweakScale configs with your mod, please do! A few notes:

• Please place your TweakScale .cfgs in your mod's folder, not in the TweakScale folder. This way users can delete TweakScale and install a new version without breaking your mod.
• If your mod is already supported, please post here or PM me, and I will remove support, giving you full control over the .cfgs.

Features

Spoiler

Scaling Control

You as the author of a part or addon get complete control over which parts you want to offer in which sizes. Should that fuel tank only be available in size 2.5m and 3.75m? Make it so! That RCS thruster on the other hand, could be scalable freely between half regular scale and double regular scale.

Mass Control

For heavy, solid parts, mass increases with the cube of the scale - you scale it in three dimensions, after all. For parts that are a thin layer of aluminium plates over a rigid skeleton - like fairings, crew compartments, empty fuel tanks - mass probably scales closer to the square of the scale.

Control Over Every Feature of a Part

This is not all! Engines can be made more powerful as they increase in size, generators more efficient, and wings more lifty. All by writing a simple config file, and then automatically for all rescalable parts of that type.

How to use

Spoiler

 

 

First add a part that's the wrong size:

Right click:

See how it says 3.75m? Well, the command capsule is 2.5m, so let's change it. You do this by pressing the << >> buttons or dragging the slider.

See how well it fits?

 

 

 

Edited April 16, 2018 by pellinor

[Space Scumbag]

Yes, finally a new thread. Good luck!

[Superfluous J]

Thanks for continuing work on this mod, and for the new thread!

[Eleven]

So far so good. No weird anomalies when replacing the old version...and that's ALWAYS a good thing

[Dazpoet]

It feels like anywhere I look I get different answers and they all have different ages so... Does this or does it not work with infernal robotics so I can make the *trons bigger and thereby more stable when adding large loads to them?

[AccidentalDisassembly]

It feels like anywhere I look I get different answers and they all have different ages so... Does this or does it not work with infernal robotics so I can make the *trons bigger and thereby more stable when adding large loads to them?

Unfortunately the answer is not all yes or all no.

Yes, it works with IR. No, you cannot scale parts very much bigger. 1.something times original size is the maximum. Why? Apparently because IR parts only work if the node sizes on the parts are size 1 or smaller after being scaled in-game (or something vaguely like that, my explanation is most likely incomplete and wrong). Why? I don't know, because you can (I think, anyway, have to check that) make node sizes larger in the configs and the parts maybe still work.

But that means you can scale IR parts smaller (in-game) and it doesn't break. So far, anyway. IR includes tweakscale values to do so.

If you want larger IR parts, you'll need to either:

A) Copy the configs for the parts, make new ones scaled up, scale up all values appropriately, or

Use a module manager patch to do the same thing.

This works, I've done it, but not always with all parts for mysterious reasons.

[pellinor]

It feels like anywhere I look I get different answers and they all have different ages so... Does this or does it not work with infernal robotics so I can make the *trons bigger and thereby more stable when adding large loads to them?

Sure, and there is no need to create new parts. The simplest way is to add larger scaleFactors to IR's scaleTypes with a MM config (so you replace the 'scaleFactors' list with a new list that contains the old ones plus the ones you want to add). This will make both the parts and their nodes bigger, so all is fine from TweakScale's side.

This is a config I used in one of my old saves for adding a smaller stack size:

@SCALETYPE[stack]:Final
{
    @scaleFactors = 0.3125, 0.625, 1.25, 2.5, 3.75, 5.0
    @scaleNames = 31cm, 62.5cm, 1.25m, 2.5m, 3.75m, 5m
}

However, I heard that IR tends to have problems with very large nodes, and I suspect that this has to do with the instant acceleration that IR does. Just like in real life, heavy things do not like to have their speed changed instantly (simple example: driving a car against a brick wall). It happens that this is also an area where I am tinkering at the moment.

Edited March 8, 2015 by pellinor

[AccidentalDisassembly]

Hey Pellinor,

Question about tweakscale + the tech tree. I was wondering if it would be possible to implement something like this. Hopefully my description will make some sense-ish. But I'm working under some assumptions that might not be true, so please correct me if they're not.

I'm using "Tech node 2.5m" and "Tech Node 3.75m" and whatnot to refer to whatever tech node would unlock those sizes, just for the sake of generic argument.

Assumptions: are these true?

1) Right now, the way tech tree + scaling works is that particular scaleFactors in a SCALETYPE{} are connected to particular nodes in the tree, right? Assuming that scaletype has factors 0.625, 1.25m, 2.5, 3.75, and 5 only:

2) So, for example, if you have a 1.25m part, you wouldn't be able to unlock scaling it to 2.5m until you research Tech Node 2.5m. Then, you can scale it to 5m when you unlock Tech Node 5m, etc.

3) But, if you have a 3.75m part from the outset, it cannot be scaled down to 2.5m until you unlock Tech Node 2.5m, and then, later, it too can scale to 5m when you unlock Tech Node 5m.

So, if that's actually how it works:

Would it be possible instead to implement a relationship to tech nodes like this:

1) Let's assume you start with a 2.5m part, and that its SCALETYPE has major increments at 0.625m, 1.25, 2.5, 3.75, 5.0.

2) When you unlock the first tech node that allows scaling up or down, it allows you to go one "notch" (one scaleFactor) in either direction of the part's defaultScale. So the 2.5m part could, at first, only be scaled to 1.25 or 3.75m. Likewise, a part that starts at 3.75m could only be scaled to 2.5m or 5m after this first tech node.

3) The second node in the research tree that has to do with scaling allows you to scale things two scaleFactors in either direction of the default scale - so now, the 2.5m part can be scaled anywhere from 0.625m to 5m. But a part that starts at 1.25m could only be scaled up to 3.75m.

4) The third related tech node allows moving three increments in either direction of original scale, the fourth four, and so forth. Or, it could allow plus or minus a particular percent of the part's original scale, since everything is FreeScale - that might make it more flexible... Or some other system to figure out how much larger/smaller any given part can be made after a particular technology.

Then, of course, the real question is whether that kind of system would even make sense. My thinking is that progression in the tech tree should allow greater and greater manipulation of part size, no matter what size a part starts at. But maybe that's not a good way to do it... thoughts?

Edited March 8, 2015 by AccidentalDisassembly

[Dazpoet]

Sure, and there is no need to create new parts. The simplest way is to add larger scaleFactors to IR's scaleTypes with a MM config (so you replace the 'scaleFactors' list with a new list that contains the old ones plus the ones you want to add). This will make both the parts and their nodes bigger, so all is fine from TweakScale's side.

This is a config I used in one of my old saves for adding a smaller stack size:

@SCALETYPE[stack]:Final
{
    @scaleFactors = 0.3125, 0.625, 1.25, 2.5, 3.75, 5.0
    @scaleNames = 31cm, 62.5cm, 1.25m, 2.5m, 3.75m, 5m
}

However, I heard that IR tends to have problems with very large nodes, and I suspect that this has to do with the instant acceleration that IR does. Just like in real life, heavy things do not like to have their speed changed instantly (simple example: driving a car against a brick wall). It happens that this is also an area where I am tinkering at the moment.

Thank you! I'm preparing a new save to play around with and Tweakscale + IR is one of the things I really want. I don't plan on using humongous IR parts, just want them 1 size larger than they are now, so I'm hoping I won't have problems with very large nodes

Saving the MM patch for future use

[AccidentalDisassembly]

Thank you! I'm preparing a new save to play around with and Tweakscale + IR is one of the things I really want. I don't plan on using humongous IR parts, just want them 1 size larger than they are now, so I'm hoping I won't have problems with very large nodes

Saving the MM patch for future use

Please report back on what happens if you scale an IR part more than 1.999x (in most cases, I think) its original size! I'd be curious to know if it really does somehow work now...

[Joshwoo70]

Yay new thread!

good luck!

(Needs to update)

[pellinor]

Honestly, I've never used the tech limitations myself, so I do not have much feeling for how it should be. My career game usually develops from stock at the beginning to more and more mods towards the end. TweakScale comes into play when docking is available and I'd like stuff like very weak RCS thrusters.

I like the old system for its simplicity. scaleFactors may have a tech requirement attached. In the editor, the scaleFactors list is simply filtered by removing the ones which are not researched. Your system has the advantage that you can not end up with a part that is forbidden to have its defaultScale.

For the moment I'd like to avoid changing things until there is a need for change and the new version is clearly better (just be aware that such a change would break existing configs). Actually I have no idea how many people or mods use this system at all. (For the old free scaling feature my impression was that it was hardly used at all because of the bad usability)

[futrtrubl]

Then, of course, the real question is whether that kind of system would even make sense. My thinking is that progression in the tech tree should allow greater and greater manipulation of part size, no matter what size a part starts at. But maybe that's not a good way to do it... thoughts?

This can already be done. In the tweakscale section of the part cfg you can specify tech nodes that certain scaling options become available.

[AccidentalDisassembly]

This can already be done. In the tweakscale section of the part cfg you can specify tech nodes that certain scaling options become available.

I see you didn't actually read anything I wrote except for that one line.

[futrtrubl]

I see you didn't actually read anything I wrote except for that one line.

Actually I did. Maybe I misunderstood what you were saying but thanks for the sarcasm.

Looking more I think I have a better idea of what you want, but the problem is how does the system know what scale a part is? What scale is a certain solar panel? You would still have to add information to the cfg for each part telling it what size it is and what to base it's size options on. Pretty much how the current system works.

If I am still misunderstanding then please tell me, non-confrontationally.

[AccidentalDisassembly]

Actually I did. Maybe I misunderstood what you were saying but thanks for the sarcasm.

Looking more I think I have a better idea of what you want, but the problem is how does the system know what scale a part is? What scale is a certain solar panel? You would still have to add information to the cfg for each part telling it what size it is and what to base it's size options on. Pretty much how the current system works.

If I am still misunderstanding then please tell me, non-confrontationally.

Sorry, I have just had a string of people not actually read the contents of my posts, lately, then respond to what they insisted I must have been saying without taking the time to read all of the plain language of what I wrote. It has made attempting to contribute to anything on these forums rather frustrating.

Anyway, the code for knowing what scale a part is and the limits on its scaling must already exist, since tech limits are already in. TS knows that a part starts (for its purposes, doesn't really matter what size the part really is in game) at defaultScale X, and, knowing this, won't let it scale up to Y (or whatever) until you've researched a tech node.

My proposal is simply a relative limit on scaling (to the original size of the part, as determined by defaultScale in its TS module, I assume) rather than an absolute one like it (apparently) is now.

[Mecripp]

Has anyone using Linux got this tweakscale to work ? keep having to go back to the old one this work just locks the game up when, I pick a part.

And @AccidentalDisassembly I hope they don't add that to this plugin it would just be a file, I have to hunt and zip up or delete.

EDIT- Thanks for the feedback Eleven maybe, I have a bad cfg somewhere didn't think to look at the log tell, I put the old one back in and started the game then to later over-ride the file ouch will try again.

Edited March 9, 2015 by Mecripp2

[Eleven]

Has anyone using Linux got this tweakscale to work ? keep having to go back to the old one this work just locks the game up when, I pick a part.

And @AccidentalDisassembly I hope they don't add that to this plugin it would just be a file, I have to hunt and zip up or delete.

I'm using Mint 17.1 with the 64bit client. I haven't had any issues with TweakScale so far.

[pellinor]

Has anyone using Linux got this tweakscale to work?

Yes, I am developing on linux. Haven't started the windows version for weeks (i prefer it for playing though, because of antialiasing).

[Northstar1989]

OK, so does TweakScale 1.52 adjust node-sizes in accordance to re-scaling?

I.e. if I increase the size of a 2.5 meter diameter part to 3.75 meters diameter, the node size should increase from size 2 to size 3. Or if I decrease it to 1.25 or 0.625 meters, it should decrease to size 1 or 0, respectively...

Node sizes have serious consequences for rocket construction in KSP because they affect the strength of attachment between two parts, and how wobbly/strong a connection between those parts is...

Regards,

Northstar

[pellinor]

OK, so does TweakScale 1.52 adjust node-sizes in accordance to re-scaling?

Of course, node size scales linearly, so the default stack sizes should behave just as you would expect.

[OmegaCenti]

I think there might be a problem Pellinor in TweakScale. In career mode, part costs are being zero'd out (example parts include the 3 man capsule and the skipper engine) but does not exclude many others. I noticed after installing your mod that many of my crafts became impossibly cheap. uninstalled TweakScale and the prices came back. I am on windows 7 (updated) KSP 0.90 . I hope this helps!

Also the TweakScale version affected by this is Major 1 minor 52

Edited March 10, 2015 by OmegaCenti

[NihilRex]

Same issues as OmegaCenti for part costs on Linux x64.

[AccidentalDisassembly]

Huh, now that you mention it, I'm also getting some funny part costs in career since the 1.52 update. I had assumed it was something else I did, but now that I think about it, it may have been just TS that had been updated when prices in the VAB/SPH started going a little wonky.

[pellinor]

Fix is up! Please grab the new version v1.52.1 !