Jump to content

[0.90] TweakScale - Rescale Everything! (v1.50 - 2014-12-24 10:40 UTC)

Biotronic

By Biotronic
in KSP1 Mod Releases

 Share

Recommended Posts

Symbol

Symbol

Posted
Posted

Hello,

I've found kind of bug while using the following mods: TweakScale (1.47), ModuleManager (2.5.1), KSP-Interstellar (0.13). KSP ver.: 0.25, 32-bit.

Whenever I'm trying to attach some kind of air intake part (say Circular Intake) in SPH, I'm getting "[Exception]: NullReferenceException: Object reference not set to an instance of an object".

It seems this bug occurs only when all of these 3 mods are installed simultaneously, therefore I'm reporting this issue to all related threads.

If this is not a mod issue, do you have any idea how to fix it?

If this bug is already known / not related to mod / not your problem, then I apologize for disturbing you:)

Best regards:)

Link to comment
Share on other sites
Brightideagaming

Brightideagaming

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

http://i.imgur.com/uzqeB84.gif

This plugin was initially made by Gaius Goodspeed, and I heartily recommend you also take a look at his parts.

TweakScale is already used by Gaius' parts above, and ZodiusInfuser's Infernal Robotics model rework, which I also recommend to anyone who likes having fun.

TweakScale uses Swamp-Ig's KSPAPIExtensions.

TweakScale is made available under the terms of the Do What the .... You Want to Public License.

DOWNLOAD

Alternative Download from Dropbox

KerbalStuff

Curse Page

Source on GitHub

Current Version: v1.47 (2014-11-17 20:36 UTC)

HALP! It no worky! / FAQ

Alright, calm down. We will get to the bottom of this. What symptoms are you experiencing?

The scale slider is missing, and/or there's a gaping hole in the right-click menu!

This is usually caused by an outdated KSPAPIExtensions.dll. If you have any of these mods installed, please update them. Also make sure you have the latest TweakScale installed.

Sometimes when updating, you need to completely remove the old mod first.

There may be other mods that use KSPAPIExtensions.dll than those listed there, so if that doesn't solve your problem, try a search for that file name.

Lastly, this may be caused by Goodspeed Aerospace Parts. If you have it installed, find and remove its Scale.dll file.

Part X of mod Y isn't rescalable!

Great! That means I either have not updated the mod, or it's not on the list of supported mods, as seen below. I'm very happy to get updated cfgs, or just a note that some parts are not working. I don't use all the mods listed, so it's hard to keep them all updated.

Part Z becomes too heavy when scaled up!

Yeah, I'm a bit lazy, so all parts' mass scale with the cube of the size. That's the equivalent of saying every part is solid, or filled with heavy cream. Some parts are probably not filled, and may consist of but a thin skin over an empty inner. Maybe some day I'll get around to updating that kind of stuff. Otherwise, if someone else were to do it, I'd be more than happy to include their work!

TweakScale and some other mod are having problems cooperating!

First make sure both mods are up to date. Occasionally, a mod may change the names of files, so just overwriting with an updated version might not be enough. If necessary, take a backup. Then delete the folder in which the mod is installed, and install the updated version.

If this does not solve your problem, or you're scared of breaking you game, please post here. As below, please post your output_log.txt.

I'm having a problem and it's not listed here!

Great! That means I can make TweakScale even better! Please post here and describe your problem. Make sure you have the newest version of TweakScale, and please post your output_log.txt. It's going to be too big to place in a single post, so upload it to Dropbox, Pastebin or some other service that lets you upload large text files.

Please add TweakScale to your mod!

If you are a mod author and you want to bundle TweakScale 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 on the list of supported mods, please post here or PM me, and I will remove support, giving you full control over the .cfgs.

Anyways, features:

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

First add a part that's the wrong size:

http://i.imgur.com/NxMyyTK.png

Right click:

http://i.imgur.com/BBw1x4M.png

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.

http://i.imgur.com/LCEiPHP.png

See how well it fits?

http://i.imgur.com/fAF2xsT.png

Example Configurations

For a part that should be available in 62.5cm, 1.25m, 2.5m, 3.75m and 5m configurations, and by default is 1.25m, use the following definition:


{
name = TweakScale
defaultScale = 1.25
type = stack
}
MODULE

If the part should instead be freely rescalable, use this:


{
name = TweakScale
type = free
}
MODULE

And for a part that should be available in 25%, 50%, 100% and 200% scales, use:


{
name = TweakScale
type = surface
}
MODULE

But I said you had full control of scales, didn't I? If you want your parts to be available only in 2.5m and 3.75m versions, use this definition:


{
name = TweakScale
type = stack
scaleFactors = 2.5, 3.75
scaleNames = 2.5m, 3.75m
}
MODULE

If your mod has a collection of parts that will all be available in the same set of sizes, you might want to make your own scale type:


{
name = MyMod
freeScale = false
scaleFactors = 0.5, 1.0, 2.0
scaleNames = Small, Medium, Large
defaultScale = 1.0
}
SCALETYPE

After defining this once, you can then start using it for your parts:


{
name = TweakScale
type = MyMod
}
MODULE

As you can see the scale type uses the same names as the module definition, and they can even inherit from other scale types (if you want to change just a small detail):


{
name = spaceplane
type = stack
scaleFactors = 1.25, 2.5, 3.75, 5.0
scaleNames = 1.25m, 2.5m, 3.75m, 5m
}
SCALETYPE

This will use all the defined properties of the 'stack' scaletype, but will not be available in 62.5cm size (because some poor kerbal is going to sit inside there).

Adding module support

You can now add support for your own modules! For a simple module that's happy with having its values changed when OnLoad is called, this is how:


{
name = MyPartModule

flooberRate = 2
}
TWEAKSCALEEXPONENTS

When a user rescales a part with a MyPartModule module, TweakScale will automatically update the flooberRate of the part with the square of the scale (so if it's a 2.5m part and it's scaled to 3.75m, the flooberRate will be 2.25 times its usual value [3.75/2.5 = 1.5; 1.5^2 = 2.25]).

New in 1.10 is the ability to change fields of fields - that is, myPartModule.someStruct.value or myPartModule.someList[x]:


{
name = ModuleGenerator
outputList
{
rate = 3
}
}
TWEAKSCALEEXPONENTS

The above config will scale all members of the list outputList on ModuleGenerator, to the cube of the current scale.

Note that this system works for any depth:


{
name = ModuleMyModule
foo
{
bar
{
quxRate = 3
}
}
}
TWEAKSCALEEXPONENTS

The above would scale ModuleMyModule.foo[x].bar.quxRate.

New in 1.19 is tech requirements:


{
name = TweakScale
type = stack
techRequired = basicRocketry, start, generalRocketry, advRocketry, heavyRocketry
}
MODULE

Here, each option in the stack SCALETYPE will be unlocked by a corresponding tech. If there are fewer techRequired than scaleNames/scaleFactors, the unmatched scales will be unlocked by default.

It might be that your module would benefit more from using a list of values than an exponent. In that case, you may specify the list in the tweakscale module statement in the .cfg:


{
name = TweakScale
type = stack
defaultScale = 3.75

MODULE
{
name = ModuleEngines
maxThrust = 1, 2, 3, 4, 5
}
}
MODULE

Here, a 62.5cm version would have a maxThrust of 1, 1.25m would be 2, and so on until the 5m version has a maxThrust of 5.

New in 1.23: Forced relative scaling!

This is invaluable for persistent values. If they were to use absolute scaling, the default value would be loaded from the prefab part, scaled up, and used without a second thought. With relative scaling, the current value is loaded, the multiplied by the scale factor difference since last we looked. And it's super easy to use:


{
name = MyModule
!MyValue = 2
}
TWEAKSCALEEXPONENTS

New in 1.30: Cost scaling!

As 0.24.1 introduced the beautiful IPartCostModifier, TweakScale now supports changing the cost of a part:


{
name = TweakScale
dryCost = 2
}
TWEAKSCALEEXPONENTS

The above configuration will make the cost of a part scale with its surface area. Useful for fuel tanks, solar sails, balloons and rugs.

Thanks to NathanKell, 1.44 added support for not doing scaling when a specific module is added to a part. This is useful when TweakScale can do some updates on its own, but should keep its hands off when another module can do better.


{
name = MyModule
socksPerMinute = 2
ignore = SockManager
}
TWEAKSCALEEXPONENTS

This code will scale socksPerMinute by the square of the scale, or if there's a SockManager partmodule on the part, leave it all alone and let the SockManager do its thang.

Advanced features

If more advanced logic is required, TweakScale offers an IRescalable interface. It is defined in Scale_Redist.dll, and its definition is as follows:


{
void OnRescale(ScalingFactor factor);
}
public interface IRescalable<T>

ScalingFactor has the properties 'absolute' and 'relative'. Most likely, you want to use absolute. relative is the change in scale since last time OnRescale was called, while absolute is the change in scale in relation to defaultScale. absolute and relative have properties linear, quadratic and cubic, which are shorthands for different scaling factors. If you want something different, you'll have to figure out the math yourself.

IRescalable can be used in conjunction with .cfg exponents. In that case, TweakScale will first call IRescalable's OnRescale, followed by updates from .cfgs. (this may be changed in the future, as I'm not sure it's the best solution)

An example implementation of an IRescalable may be:


class MyModuleUpdater : TweakScale.IRescalable<MyPartModule>
{
MyPartModule _module;

public MyModuleUpdater(MyPartModule module)
{
_module = module;
}

public void OnRescale(TweakScale.ScalingFactor factor)
{
_module.flooberRate = _module.flooberRate * factor.relative.quadratic;
_module.ReactToFlooberRate(13);
}
}
For an example implementation, check out how Modular Fuel Tanks/Real Fuels support is implemented.
Version History:
1.46 - 2014-11-16 20:03 UTC)
  •  Removed RealChute support.
  •  Fixed a bug where TweakScale would try to set erroneous values for some fields and properties, which notably affected Infernal Robotics.
  •  Fixed a bug where cloned fuel tanks would have erroneous volumes.
1.46 - 2014-11-16 20:03 UTC)
  •  Fixed an issue where features were incorrectly scaled upon loading a ship,
  •  Scaling a part now scales its children if they have the same size.
  •  Parts now automatically guess which size they should be.
1.44 (2014-10-10 19:20 UTC)
1.44 (2014-10-10 19:20 UTC)
  • Updated for KSP 0.25
  • Added ability to not update certain properties when a specific partmodule is on the part.
Many thanks to NathanKell, who has all the credit for this release!
1.43 (2014-08-24 23:52 UTC)
  •  Added licence file (sorry, mods!)
  •  No longer chokes on null particle emitters.
1.41 (2014-08-15 11:43 UTC)
  •  Fixed scaling of Part values in unnamed TWEAKSCALEEXPONENTS blocks.
1.40 (2014-08-13 12:55 UTC)
  •  Removed Karbonite cfg, since that project does its own TweakScale config.
1.39 (2014-08-12 23:03 UTC)
  •  Fixed cost calculation for non-full tanks.
1.38 (2014-08-12 20:45 UTC)
  •  Added scaling of FX.
  •  Added support for Banana for Scale.
  •  Updated Karbonite support.
  •  Fixed a bug where no scalingfactors available due to tech requirements would lead to unintended consequences.
1.37 (2014-08-05 13:35 UTC)
  •  Updated cost calculation.
1.36 (2014-08-04 21:58 UTC)
1.35 (2014-08-03 16:24 UTC)
1.34 (2014-08-02 00:49 UTC)
  •  Fixed a bug where repeated scaling led to inaccurate placing of child parts.
  •  Added Karbonite support.
1.33 (2014-07-28 20:00 UTC)
  •  Updated for RealFuels 7.1
1.32 (2014-07-25 22:29 UTC)
  •  Updated with KSPAPIExtensions 1.6.3 for 0.24.2
1.31 (2014-07-25 15:58 UTC)
  •  Fixed a bug where parts with defaultScale inaccessible due to tech requirements were incorrectly scaled.
1.30 (2014-07-25 11:23 UTC)
  • Updated KSPAPIExtensions with 24.1 support.
  • Re-enabled Real Fuels support.
  • Added support for IPartCostModifier
1.29 (2014-07-24 11:50 UTC)
1.28 (2014-07-24 10:32 UTC))
  • Fixed the rest of the bug that was partly fixed in 1.27.
  • Added support for Tantares Space Technologies.
1.27 (2014-07-23 21:44 UTC)
  • Fixed a bug on non-Windows platforms.
1.26 (2014-07-23 16:60 UTC)
  •  Fixed typo in DefaultScales.cfg. type = free, type = surface and so on should now work.
  •  Updated support for KW Rocketry and NFT.
1.25 (2014-07-23 12:31 UTC)
  •  Modular Fuel Tanks yet again supported! (Still waiting for Real Fuels)
  •  Refactored IRescalable system to be easier for mod authors.
  •  Fixed a bug where one field could have multiple exponents, and thus be rescaled multiple times.
1.24 (2014-07-21 20:51 UTC)
  •  Nodes are now correctly scaled when parts are duplicated.
  •  Per-scaletype exponents are now used correctly.
1.23 (2014-07-21 12:44 UTC)
  •  Multiple TweakScale .dlls no longer interfer with each other.
1.22 (2014-07-20 22:21 UTC)
  •  Fixed tanks that refill when you change between ships.
  •  Fixed tech lookup time, which was way too slow.
1.21 (2014-07-18 18:47 UTC)
  •  Updated for 0.24!
  •  More flexibility of configuration. Mod authors can now have feature scale definitions per part, per scaletype or global.
1.20 (2014-06-12 22:15 UTC)
1.19 (2014-06-06 10:56 UTC)
  •  Added support for tech requirements for non-freeScale parts.
1.18 (2014-06-04 00:58 UTC)
  •  Factored out Real Fuels and Modular Fuel Tanks support to separate dlls.
1.17 (2014-06-03 22:21 UTC)
  •  Fixed bug where attachment nodes were incorrectly scaled after reloading. This time with more fix!
  •  Added support for Near Future Technologies.
1.16 (2014-06-03 21:31 UTC)
  •  Fixed bug where attachment nodes were incorrectly scaled after reloading.
1.15 (2014-06-03 20:50 UTC)
  •  Finally squished the bug where crafts wouldn't load correctly. This bug is present in 1.13 and 1.14, and affects certain parts from Spaceplane+, MechJeb, and KAX.
1.14 (2014-06-03 19:50 UTC)
  •  Fixed a bug where nodes with the same name were moved to the same location regardless of correct location. (Only observed with KW fairing bases, but there could be others)
1.13 (2014-06-02 18:25 UTC)
1.12 (2014-06-02 11:10 UTC)
1.11 (2014-06-01 20:24 UTC)
  •  Removed silly requirement of 'name = *' for updating all elements of a list.
  •  Added .cfg controlled scaling of Part fields.
1.10 (2014-06-01 14:53 UTC)
  •  Added support for nested fields.
1.9 (2014-05-31 00:57 UTC)
  •  Fixed a bug where rescaleFactor caused erroneous scaling.
  •  Added (some) support for Kethane parts.
1.8.1 (2014-05-30 22:41 UTC)
Don't use 1.8.1, either. :P
1.8
Don't use 1.8
1.7 (2014-05-22 21:09 UTC)
  •  Removed spurious debug log printing.
  •  You can now use a list of value instead of an exponent!
  •  Exponents and value lists can be specified per part, not just per module type. (And per-part values take precedence)
  •  Fixed erroneous scale for Rockomax 48-7S, and added missing scale for KW Rocketry 2.5m Nose Cone.
1.6 (2014-05-22 14:04 UTC)
  •  Fixed a problem where parts were scaled back to their default scale after loading, duplicating and changing scenes.
  •  Fixed defaultScale for Rockomax 48-7S (was 625, should be .625. Who'd guess someone'd notice that, eh?)
1.5.0.1 (2014-05-21 00:36 UTC)
  •  Fixed a bug in 1.5 where scale was not correctly preserved.
  •  Updated KSPAPIExtensions.dll - please delete the version in GameData/.
  •  Added support for KSO.
1.5 (2014-05-20 22:23 UTC)
  •  Changed from hardcoded updaters to a system using .cfgs.
  •  Made registration of custom IRescalables possible.
1.4 (2014-05-20 17:53 UTC)
  •  Fixes compatibility with GoodspeedTweakScale (but not old versions of TweakScale, but that should be a much, much smaller problem anyway).
  •  Added scaling support for KW Rocketry, NovaPunch and KSP Interstellar.
1.3 (2014-05-19 22:49 UTC)
  •  Fixed a bug where parts would get rescaled to stupid sizes after loading.
  •  Breaks compatibility with old version of the plugin (pre-1.0) and GoodspeedTweakScale. :(
1.2 (2014-05-18 22:00 UTC)
  •  Fixed default scale for freeScale parts.
  •  Fixed node sizes, which could get absolutely redonkulous. Probably not perfect now either.
  •  B9 Aerospace, Talisar's Cargo Transportation Solutions, and NASA Module Manager configs.
  •  Now does scaling at onload, removing the problem where the rockets gets embedded in the ground and forcibly eject at launch.
  •  Fixed a silly bug in surface scale type.
1.1 (2014-05-17 23:30 UTC):
1.0 (2014-05-16 18:00 UTC):
  •  Initial Release!
Supported Mods
Known Issues/TODO:
  •  More mods should be supported. I'm open to suggestions.
  •  Enlarged engines burn too hot.
  •  Exhaust trails are the wrong size. I think.
  •  Support for more modules (addons)?
  •  Suboptimal interactions with Procedural Parts and Procedural Fairings - parts may intersect after loading.
  •  I have no idea how FAR  feels about the updating of drag and lift.
  •  Weird TWR in MechJeb. (ref post 22)
  •  Camera can end up in weird positions. (ref post 22)
  •  Add ModuleEngineConfig support.
  •  Do what Taverius says about engines and possibly other stuff.
i made a real peice by peice module of the space shuttle but i need a arm so i added romafer but the arm was too big can you please please add romafer i tried to do it on my own but i just couldnt do it. or can some one please do it for me so i can have my space shuttle. when i can tweak the scale of the arm then i will post the shuttle. it can lift a lot and is really realistic.








Link to comment



Share on other sites























Mecripp









Mecripp




Posted 


















    









Posted 

(edited)










i made a real peice by peice module of the space shuttle but i need a arm so i added romafer but the arm was too big can you please please add romafer i tried to do it on my own but i just couldnt do it. or can some one please do it for me so i can have my space shuttle. when i can tweak the scale of the arm then i will post the shuttle. it can lift a lot and is really realistic.
Just a couple of post back, I did it for someone 
EDIT- Here if you need a file https://dl.dropboxusercontent.com/u/72893034/TweakScale_Romfarer_Arm.cfg.zip


Edited  by Mecripp2








Link to comment



Share on other sites























MartGonzo









MartGonzo




Posted 


















    









Posted 











Does anyone know if tweakscale allows you to rescale engines with realism overhaul?
The tanks scale fine but there is no option to scale engines.
All mods like real fuels should be up to date, installed with CKAN 1.1.3








Link to comment



Share on other sites

























Nullpint









Nullpint




Posted 


















    









Posted 











I've found kind of bug while using the following mods: TweakScale (1.47), ModuleManager (2.5.1), KSP-Interstellar (0.13). KSP ver.: 0.25, 32-bit.
I can confirm this bug on OSX too, the log file indicated a null reference exception in TweakScale (sorry I don't have the log, but can be reproduced easily). I've isolated it to ModuleManager (2.1.5). Reverting to 2.1.4 resolves the issue. As there was only a one line change for version 2.1.5 (if (nodes.Length == 0) return null;) I suspect this is what is causing the null reference :) . I believe this is still a bug which needs to be resolved in TweakScale.
You can download the previous ModuleManager at https://github.com/sarbian/ModuleManager/releases








Link to comment



Share on other sites























Nullpint









Nullpint




Posted 


















    









Posted 

(edited)










On second thought, disregard my last post. This is why you don't post late at night...
Reverting to 2.1.4 (or 2.1.5) fixed the issue because ModuleManager stops working (versions are not compatible with KSP 0.25). I tried 2.5.0 (oldest compatible with KSP 0.25) and still had the issue. 
My short term fix is to simply disable TweakScale on intake parts by commenting out the entries in the TweakScale Squad configuration file.


Edited  by Nullpint

Double post...








Link to comment



Share on other sites























DaniDE









DaniDE




Posted 


















    









Posted 











Broken remove tweakscale .47, Install tweakscale .44 and it works with interstellar.
TweakScale 1.44 can be found here:
https://github.com/Biotronic/TweakScale/releases/download/v1.44/TweakScale_1.44.zip
FYI, I was having trouble with DMagic Orbital Science (the solar particle collector) that was causing error log spam and crashes, as well as right click bug. It is only that single part. I fixed it by using Tweakscale 1.44 as well. I was about to rant on the DMagic OS thread when I realized that after reloading that particular part had changed scaled (very enlarged). Dunno if this is of any help to you finding this bug, I sure hope so though, just because I love this mod so much :D
 Keep up the great work Biotronic :D








Link to comment



Share on other sites























almagnus1









almagnus1




Posted 


















    









Posted 











Sorry, I missed this. The mods they target are bolded. Others.. well, rather unsurprisingly, BetterRoverMates.cfg targets the BetterRoveMates mod. If I said Agencia de Investigaciones Espaciales Suprema, you wouldn't be any wiser as to what mod that is because it's usually just called AIES. Most, if not all, the ones you're unsure about or ones I haven't spelled out can be found by Googling "ksp BananaForScale" or whatever. I'd link the mods, but again, googling them is sufficient.
Sweet, thanks for the info =)








Link to comment



Share on other sites























Gaalidas









Gaalidas




Posted 


















    









Posted 











I apologize if this has been covered, but I was reading in the help stuff in the OP that you can do something like this:
MODULE
{
    name = TweakScale
    type = stack
    defaultScale = 3.75

    MODULE
    {
        name = ModuleEngines
        maxThrust = 1, 2, 3, 4, 5
    }
}
Now, I'm having a little trouble with implementing modularity into the KerbalFoundries tweak scale implementation. I first exported the defined scales from the part config into a "SCALETYPE" config, but I am unsure if the "MODULE" definitions in the above example can be exported into a more modular location. As it is now, the set of values for the specific modules must be restated in the Tweakscale module. So, my question is... If I were to take the above example, and remove the engine module definition from it and instead stuck it into a "Scaletype" definition, would it work? If not, is there any way to define those values without the use of exponents in something similar to the exponent definitions?
It seems to me that there should be a way to define those specific values for the various scales in one place and then simply call that set in the part config like we do with "type" and save having to redefine them in every single part.








Link to comment



Share on other sites























k1tty









k1tty




Posted 


















    









Posted 











So i have a bug and read the forums for known bugs. I'm using Tweakscale 1.47 which i believed is the latest version and it is still doing the same issue from, what i believe was 2 versions ago of when you reload a ship some parts are scaled incorrectly. Everything on this ship is scaled correctly as in i didn't tweakscale the parts on here. (i mainly use tweakscale for inferno robotics) let me no on any info that you need for this.
153mhc9.jpg








Link to comment



Share on other sites























AccidentalDisassembly









AccidentalDisassembly




Posted 


















    









Posted 

(edited)










I apologize if this has been covered, but I was reading in the help stuff in the OP that you can do something like this:
MODULE
{
    name = TweakScale
    type = stack
    defaultScale = 3.75

    MODULE
    {
        name = ModuleEngines
        maxThrust = 1, 2, 3, 4, 5
    }
}
Now, I'm having a little trouble with implementing modularity into the KerbalFoundries tweak scale implementation. I first exported the defined scales from the part config into a "SCALETYPE" config, but I am unsure if the "MODULE" definitions in the above example can be exported into a more modular location. As it is now, the set of values for the specific modules must be restated in the Tweakscale module. So, my question is... If I were to take the above example, and remove the engine module definition from it and instead stuck it into a "Scaletype" definition, would it work? If not, is there any way to define those values without the use of exponents in something similar to the exponent definitions?
It seems to me that there should be a way to define those specific values for the various scales in one place and then simply call that set in the part config like we do with "type" and save having to redefine them in every single part.
I'll attempt to answer that, though I'm obviously not the person who really knows:
I don't think you can do a MODULE within MODULE thing like that and get the results you want. You want a TWEAKSCALEEXPONENTS {} thingamajig within a SCALETYPE {}. In TWEAKSCALEEXPONENTS, you define the exponent (or the specific values for given scales) that will apply to a particular variable.
SCALETYPE 
{
name = whatever
othervalues = whatever
TWEAKSCALEEXPONENTS
{
name = ModuleEngines
maxThrust = 1
}
}
This one will make the thrust scale in proportion to the size within ModuleEngines modules, so the maxThrust value will be 2x the original when the part is 2x the size.
SCALETYPE 
{
name = whatever
scaleFactors = 1.0, 2.0, 3.0, 4.0, 5.0
othervalues = whatever
TWEAKSCALEEXPONENTS
{
name = ModuleEngines
maxThrust = 1, 2, 3, 4, 1000
}
}
This one will make the maxThrust of whatever part that gets scaletype "whatever" have those values rather than those exponents - but if you do it this way, you cannot have more than 5 scaleFactors without modifying the scaletype (but maybe that's what you want; you can have much more control over the numbers like that) - in the example, apparently everything scales linearly until you hit 5.0x scale, at which point the thrust goes crazy.
I would recommend NOT defining a TWEAKSCALEEXPONENTS{} outside of a particular scaletype for the sake of being able to tweak things on a per-part basis (different scaletypes for different kinds of parts, maybe). I guess you could even define customized, individual sets of ways to scale variables for particular parts by putting the TWEAKSCALEEXPONENTS{} inside one particular tweakscale MODULE{} for one particular part, if the parts responded to the variables used so differently.
As far as I understand it, you can apply either exponents (for modularity, applies to any scaleFactors anyone else thinks are useful and add) or specific values to any variable in the code of the wheels - so long as you use the name used in the code of the DLL, I think. So if one of the variables that lo-fi uses is called "MyWheelsAreAwesomeAndHeresTheirTorqueValue", you'd do:
SCALETYPE
{
name = awesomeWheelScale
scaleFactors = 0.5, 1.0, 1.5 (or whatever)
TWEAKSCALEEXPONENTS 
{
name = TheNameOfTheModule (ModuleWheels? I dunno)
variableNAme = exponenttoaplytothatvariable
secondVariableName = anotherexponent
MyWheelsAreAwesomeAndHeresTheirTorqueValue = 1 (scales linearly, do either this OR the below)
MyWheelsAreAwesomeAndHeresTheirTorqueValue = 0.5, 1.0, 1.5 (the number of definitions here MUST equal the number of scaleFactors or things get real broke) - particular, absolute numbers to apply to those scaleFactors above
}
}
Sorry if I am telling you stuff you already know, I may not have understood the question you're asking. The example above would apply those particular MyWheelsAreAwesomeAndHeresTheirTorqueValue values to those particular scales for every part with a TweakScale module of the type "awesomeWheelScale". TL;DR: you can do what you're asking like so.


Edited  by AccidentalDisassembly








Link to comment



Share on other sites

























Gaalidas









Gaalidas




Posted 


















    









Posted 

(edited)










I'll attempt to answer that, though I'm obviously not the person who really knows:
I don't think you can do a MODULE within MODULE thing like that and get the results you want. You want a TWEAKSCALEEXPONENTS {} thingamajig within a SCALETYPE {}. In TWEAKSCALEEXPONENTS, you define the exponent (or the specific values for given scales) that will apply to a particular variable.
This one will make the thrust scale in proportion to the size within ModuleEngines modules, so the maxThrust value will be 2x the original when the part is 2x the size.
This one will make the maxThrust of whatever part that gets scaletype "whatever" have those values rather than those exponents - but if you do it this way, you cannot have more than 5 scaleFactors without modifying the scaletype (but maybe that's what you want; you can have much more control over the numbers like that) - in the example, apparently everything scales linearly until you hit 5.0x scale, at which point the thrust goes crazy.
I would recommend NOT defining a TWEAKSCALEEXPONENTS{} outside of a particular scaletype for the sake of being able to tweak things on a per-part basis (different scaletypes for different kinds of parts, maybe). I guess you could even define customized, individual sets of ways to scale variables for particular parts by putting the TWEAKSCALEEXPONENTS{} inside one particular tweakscale MODULE{} for one particular part, if the parts responded to the variables used so differently.
As far as I understand it, you can apply either exponents (for modularity, applies to any scaleFactors anyone else thinks are useful and add) or specific values to any variable in the code of the wheels - so long as you use the name used in the code of the DLL, I think. So if one of the variables that lo-fi uses is called "MyWheelsAreAwesomeAndHeresTheirTorqueValue", you'd do:
Sorry if I am telling you stuff you already know, I may not have understood the question you're asking. The example above would apply those particular MyWheelsAreAwesomeAndHeresTheirTorqueValue values to those particular scales for every part with a TweakScale module of the type "awesomeWheelScale". TL;DR: you can do what you're asking like so.
I suppose I should point out that the example I gave is from the first post in this thread, and that same method is used with IR parts. So, the method I put in my other message is already a workable method. I just wanted to find a way to further reduce the amount of work for applying the same module-specific variables for each scale level when all the parts are using the same numbers for those variables.
Also, if you look at the official distribution, most of their exponents are defined outside of a scaletype, so your recommendation to not define them outside of a scale type is... how do I put it... nuts? It was an excellent effort however.
I suppose, if your examples do work, that you may have answered some of my questions. I was confused a bit by the explanations on the first page as to what I could define under what in the different definitions that I can um... well... define. For instance, it shows how exponents are defined, but then shows the other way to define variables with fixed values for a fixed number of scales. I got the impression that you couldn't define those specific variable values udner exponents because it was not using an exponential curve with those variables.


Edited  by Gaalidas








Link to comment



Share on other sites























AccidentalDisassembly









AccidentalDisassembly




Posted 


















    









Posted 

(edited)










I suppose I should point out that the example I gave is from the first post in this thread, and that same method is used with IR parts. So, the method I put in my other message is already a workable method. I just wanted to find a way to further reduce the amount of work for applying the same module-specific variables for each scale level when all the parts are using the same numbers for those variables.
Also, if you look at the official distribution, most of their exponents are defined outside of a scaletype, so your recommendation to not define them outside of a scale type is... how do I put it... nuts? It was an excellent effort however.
I suppose, if your examples do work, that you may have answered some of my questions. I was confused a bit by the explanations on the first page as to what I could define under what in the different definitions that I can um... well... define. For instance, it shows how exponents are defined, but then shows the other way to define variables with fixed values for a fixed number of scales. I got the impression that you couldn't define those specific variable values udner exponents because it was not using an exponential curve with those variables.
The method in your first post might work, but like I said, I don't think it will give you what you want, meaning it will not reduce your work. The way to reduce your work is to define a TWEAKSCALEEXPONENTS{} thing for the particular variables you want to scale with the size of the part - that's my point. 
Yes, most of the TWEAKSCALEEXPONENTS stuff is defined outside of a scaletype - which is fine for most cases, and you can do it, it won't harm anything and *might* be just as easy (or easier). But if (if!) you are going to define different values or different exponents for the same variable based on the type of part you're using, you can just define them in the scaletypes you apply to those parts and save yourself the step of also defining a generic set of values - and/or stop parts that don't have particular scaletypes applied from also scaling a given variable with size. This is assuming that's actually what you want to do, like I explained - sounds like it isn't, but even if it isn't, I can tell you what I said is not nuts. It is slightly more break-proof and easier than going back and doing stuff over in the event that a new part doesn't work well with those same values/exponents. Note that I did not say that you can't or really really shouldn't, as if it wouldn't work. A couple dozen TweakScale configs for a couple hundred parts and associated scaletypes suggest it's a decent way to do things - YMMV.
I don't know anything about whether the examples given by Biotronic are up to date or not - all I know is that TWEAKSCALEEXPONENTS {} definitions do what you want to do, whence my attempted explanation of them, and you can define them either by exponent or by absolute value, and either globally (not in SCALETYPE or MODULE), for a given scaletype, and also for an individual part (once and only once, can't be called for other parts) by putting it inside a TweakScale MODULE. 
The way TWEAKSCALEEXPONENTS actually controls how variables scale is indeed not the clearest - if you put only one number after a variable's name (mass = 2 or maxThrust = 19485), it treats it as an exponent. If you put more than one, it treats them as individual values it tries to pair with individual scaleFactors, and the number of each has to be the same.
Also, this:
MODULE
{
 name = TweakScale
 type = stack
 defaultScale = 3.75
 MODULE
 {
 name = ModuleEngines
 maxThrust = 1, 2, 3, 4, 5
 }
}
... is not the way IR handles scales - not MODULE within MODULE: it's TWEAKSCALEEXPONENTS. Here's a copy & pasted snippet from an IR config:
MODULE
{
 name = TweakScale
 type = IR_RoboticRotatron
 TWEAKSCALEEXPONENTS
 {
 mass = 0.025, 0.05, 0.1
 }
 TWEAKSCALEEXPONENTS
 {
 name = MuMechToggle
 ElectricChargeRequired = 0.5,1.0,2.0
 }
}
And the way IR handles scales is REALLY not what you want, it requires going into every single part config if you ever want to change how stuff scales.


Edited  by AccidentalDisassembly








Link to comment



Share on other sites























Ziecore









Ziecore




Posted 


















    









Posted 











Sorry if this has been posted before.
I have a problem with TweakScale, I have a fresh install of KSP, running 32bit and TweakScale installed, Whenever I try to place a part in VAB/SPH the game 'breaks'. I cannot move the camera, or escape the VAB/SPH, I cannot add new parts or delete the part that was placed.
Appreciate any help.








Link to comment



Share on other sites























Gaalidas









Gaalidas




Posted 


















    









Posted 











The method in your first post might work, but like I said, I don't think it will give you what you want, meaning it will not reduce your work. The way to reduce your work is to define a TWEAKSCALEEXPONENTS{} thing for the particular variables you want to scale with the size of the part - that's my point. 
Yes, most of the TWEAKSCALEEXPONENTS stuff is defined outside of a scaletype - which is fine for most cases, and you can do it, it won't harm anything and *might* be just as easy (or easier). But if (if!) you are going to define different values or different exponents for the same variable based on the type of part you're using, you can just define them in the scaletypes you apply to those parts and save yourself the step of also defining a generic set of values - and/or stop parts that don't have particular scaletypes applied from also scaling a given variable with size. This is assuming that's actually what you want to do, like I explained - sounds like it isn't, but even if it isn't, I can tell you what I said is not nuts. It is slightly more break-proof and easier than going back and doing stuff over in the event that a new part doesn't work well with those same values/exponents. Note that I did not say that you can't or really really shouldn't, as if it wouldn't work. A couple dozen TweakScale configs for a couple hundred parts and associated scaletypes suggest it's a decent way to do things - YMMV.
I don't know anything about whether the examples given by Biotronic are up to date or not - all I know is that TWEAKSCALEEXPONENTS {} definitions do what you want to do, whence my attempted explanation of them, and you can define them either by exponent or by absolute value, and either globally (not in SCALETYPE or MODULE), for a given scaletype, and also for an individual part (once and only once, can't be called for other parts) by putting it inside a TweakScale MODULE. 
The way TWEAKSCALEEXPONENTS actually controls how variables scale is indeed not the clearest - if you put only one number after a variable's name (mass = 2 or maxThrust = 19485), it treats it as an exponent. If you put more than one, it treats them as individual values it tries to pair with individual scaleFactors, and the number of each has to be the same.
Also, this:
... is not the way IR handles scales - not MODULE within MODULE: it's TWEAKSCALEEXPONENTS. Here's a copy & pasted snippet from an IR config:
And the way IR handles scales is REALLY not what you want, it requires going into every single part config if you ever want to change how stuff scales.
Yeah, I just spent some time fiddling and discovered my error with the IR example. I think I get it now though. Calling them exponents does confuse it a bit. Alright, I should be able to upgrade lo-fi's implementation of Tweakscale in the next day or so then. Thanks.








Link to comment



Share on other sites























pascalfritz









pascalfritz




Posted 


















    









Posted 











So i have a bug and read the forums for known bugs. I'm using Tweakscale 1.47 which i believed is the latest version and it is still doing the same issue from, what i believe was 2 versions ago of when you reload a ship some parts are scaled incorrectly. Everything on this ship is scaled correctly as in i didn't tweakscale the parts on here. (i mainly use tweakscale for inferno robotics) let me no on any info that you need for this.
http://i57.tinypic.com/153mhc9.jpg
Had the same one here and lost a station to it, 6-way-node resized to its normal size upon entering the physics zone.
Images here: http://imgur.com/a/xwuLZ
Tweekscale has issues in v1.47, we hope all it will be fixed soon, but till then, the safer is to go back to v1.44. But save games with 1.47 might not be working.
Biotronic is working on it, but in his last message, he wrote he needed time to test (this thread #1252)








Link to comment



Share on other sites

























Tracker









Tracker




Posted 


















    









Posted 











So, I downloaded and used Version 1.47 and my cockpits are now shrinking.
The load fine when loaded from the SPH or VAB:
11GDyTw.jpg
Qigmuvb.jpg
But whenever you quick load, or revert back to launch, this happens:
lLDSy9Y.jpg
W5boEzK.jpg
They seem to be reverting back to their original size. However, the stats (charge, food, etc.) remains the scaled numbers. So it isn't a change in the stats, or even the center of mass, just the scale of the mesh.
It still works fine, but it looks silly.
Nothing else seems effected. I have a 70 part aircraft, and only the cockpit shrinks upon reload.








Link to comment



Share on other sites























Stone Blue









Stone Blue




Posted 


















    









Posted 

(edited)










I have this same issue. Everything was working fine with a fresh install of KSP, and about 40 or 50 plugin-only mods installed, with ONLY the Squad and NASA parts. Then yesterday, I installed several parts packs, and then I had a ship in orbit that this happened to. Everything still works, except visially the parts shrank, and there is empty space between the parts.
And this is non-cockpit parts.


Edited  by Stone Blue








Link to comment



Share on other sites

























johnnyhandsome









johnnyhandsome




Posted 


















    









Posted 











HALP! It no worky, even after reading the FAQ.
The TweakScale menu doesn't show up at all when I right click on a part. I don't have any of the warned about mods from the FAQ. I believe I have the latest version of the KSPAPIExtensions.dll installed, the one from Oct 14th, 2014. 
*********************
Here are the mods I have installed: 
000_USITools
AnimatedDecouplers
ASET
AviationLights
BahaSP
BobCatind
CustomBiomes
Diazo
DMagic Orbital Science
EditorExtensions
HGR
JSI
KAS
Kerbaltek
Klockheed_Martian
Lionhead_Aerospace_Inc
MagicSmokeIndustries
MechJeb2
MunarWheel
NASAmission
RealChute
SCANsat
ScienceAlert
SDHI
ShipManifest
Squad
StockBugFixModules
TextureReplacer
TriggerTech
TweakScale
*********************
Any ideas why it no worky?








Link to comment



Share on other sites































Guest







 This topic is now closed to further replies. 













  Share





















Go to topic listing



















×


















×



    

  • Create New...
    •