[0.90] Tweakable Parameters ( V4.1 Released 25 Dec 2014 )

[HoneyFox]

I'm happy to share this newly-written plugin with you.

This plugin will allow you to tweak parameters you want of parts in Editor mode and these tweaks will be saved into the .craft file, which means you can have different settings in different crafts and no need to copy&paste part folders just because you want to tweak some parameters of them.

Tips for V4.1:

1. You should download Sarbian's Module Manager plugin. This plugin provides the capability to add certain part module into all parts. Once you installed that plugin correctly, all parts in your game will have tweakable parameter capability.

2. You can now pick parts in Gizmo/ActionGroup mode and press "P" key, too.

3. FloatCurveEditor allows you to adjust engine Isp curves, solar panel power output curves, etc. in editor mode.

Download Links:

V4.1:

https://github.com/HoneyFox/TweakableParam/raw/master/TweakableParam%20v4.1.zip

V4:

https://www.dropbox.com/s/v8jdz1hann04uew/TweakableParam%20v4.zip

Spaceport link(out-dated):

http://kerbalspaceprogram.com/0-19-x-tweakable-parameters-v2/

V3:

Dropbox mirror:

https://www.dropbox.com/s/6jdd1stp32eypq6/TweakableParam%20v3.zip

V2:

Dropbox mirror:

https://www.dropbox.com/s/awwxepq3ramqzpc/TweakableParam%20v2.zip

V1:

Dropbox mirror:

https://www.dropbox.com/s/ct1wwgu4o2p8efn/TweakableParam.zip

Source code is on Git: https://github.com/HoneyFox/TweakableParam/

New Version (v4) released!

screenshot:

Usage:

See README.txt in package for details.

Normally you don't need to read the following guide.

Brief process of manually adding tweakable parameters:

1. Edit part.cfg of parts you want to add tweakable-parameter capability.

2. Add ModuleTweakableParam modules into the part.cfg. For each parameter you want to tweak, one module is needed.

2. Now we have two ways to add tweakable capability:

1) Old fashion, still compatible.

Examples:

1> This will allow you to adjust RCS thrust power in Editor mode, so you can easily drive heavy ships without the need to install more RCS pods.

MODULE

{

name = ModuleTweakableParam

targetField = Module(ModuleRCS).thrusterPower

setOnlyOnLaunchPad = false

minValue = 0.1

maxValue = 5.0

stepValue = 0.1

}

2> This will allow you to adjust fuel amount of a fuel tank. You can then set up whether you need an empty tank or a full tank or even a half-fueled tank.

Note that the setOnlyOnLaunchPad = true, this avoid refuel cheat when you resume the flight.

Actually for resources it's better to force setting the switch on, but finally I leave that to you to decide

(The following data are for a Rockomax Jumbo-64 Fuel Tank)

MODULE

{

name = ModuleTweakableParam

targetField = Resource(LiquidFuel).amount

minValue = 0

maxValue = 2880

stepValue = 90

setOnlyOnLaunchPad = true

}

MODULE

{

name = ModuleTweakableParam

targetField = Resource(Oxidizer).amount

minValue = 0

maxValue = 3520

stepValue = 110

setOnlyOnLaunchPad = true

}

2) New multi-set support.

This feature allow you to pick parameters in runtime instead of in part.cfg editing.

What you only need to add is:

MODULE
{
	name = ModuleTweakableParam
	useMultipleParameterLogic = true
}

You can still assign parameters manually.

Example:

tweakableParamModulesData = <Module(ModuleRCS).thrusterPower,,0.0,5.0,0.1,0>,<Resource(MonoPropellant).amount,,0.0,100.0,10.0,1>,<mass,,2.0,4.0,0.1,0>,

The format is: for each parameter, you need a <...>, separated by commas. Inside <...>, the values are in this order: targetField, tweakedValue, minValue, maxValue, stepValue, setOnlyOnLaunchPad. Note that the tweakedValue field is blanked, this means you will leave it to the game, and the game will fill it with the part's original value for it.

3. Launch the game and get into the VAB/SPH, and pick up the parts you have added the module.

For the part that has enabled the new multiple parameter logic:

4. Select the part by left clicking it, then press P key to bring up the Select Parameter window.

5. Select the parameter you want to add tweakable capability, remember to enter the values before you click the Add button. The toggle on the left side of the Add button is for "setOnlyOnLaunchPad" option.

6. You can now tweak the values in the GUI popped up.

7. Save the craft and all these tweaks will be saved also.

Edited December 25, 2014 by HoneyFox
Fix for KSP v0.90.0

[Pursuedtank]

One thing for this, you may want to supply any parts that need to be edited in the download as it may be confusing for people and/or put them off of the mod, however the initial idea looks promising

[Mihara]

Ooh, finally a clean solution to the launch-empty-fuel-tank problem. Much thanks.

[White Owl]

What a fantastic, clean, elegant idea. Just what I've been wanting, and I kept making unnecessary duplicate parts.

[Blinkin]

Great and smooth implementation. Thanks!

[Mihara]

A suggestion. It has been noted above that you might want to include parts that are likely to be tweaked. While your plugin obviously has much wider applications, adjustable fuel tanks are what most people will want it for first, but with the wide variety of stock and non-stock tanks people use or generate with Part Generator, this might not be feasible. I have a better idea:

A companion application, 'tweak installer', that will parse config files, search for cases where a tweak may reasonably be applied -- i.e. resource amounts, or the thrust value on RCS, whichever else you or anyone else can think of, and patch the config files if not patched already, letting the user select which parts to patch and which tweaks to apply to each.

I'd make one, but mine would be a console Python script, not very suitable for wide distribution.

[HoneyFox]

A suggestion. It has been noted above that you might want to include parts that are likely to be tweaked. While your plugin obviously has much wider applications, adjustable fuel tanks are what most people will want it for first, but with the wide variety of stock and non-stock tanks people use or generate with Part Generator, this might not be feasible. I have a better idea:

A companion application, 'tweak installer', that will parse config files, search for cases where a tweak may reasonably be applied -- i.e. resource amounts, or the thrust value on RCS, whichever else you or anyone else can think of, and patch the config files if not patched already, letting the user select which parts to patch and which tweaks to apply to each.

I'd make one, but mine would be a console Python script, not very suitable for wide distribution.

Yeah, I had similar thought these days because it's quite tiring to add lots of tweak modules into all these stock/non-stock parts.

The application should be like this:

[DREAM]

The user needs to choose the part.cfg first.

Use .NET Reflection again to obtain all public numeric properties of the part & its part modules. so that users can choose which property they want to tweak. (I'm not responsible for any result of trying to tweak something that should only be changed in game logic)

A small disadvantage of this is that, for part / part modules written by other modders, it's not easy to acquire their plugin dll files to obtain their classes and properties of them. (Maybe a scan inside KSP/Plugins folder and dynamically load these assemblies? I'm not familiar with that :-| )

For resources, the program will first parse all resources available in the part.cfg file and list them out on the GUI, then a single click to insert a tweak module for the selected resource into the part.cfg. For convenience, an additional button can be provided to add modules for all resources found in the part.

All tweak modules that will be applied onto the part.cfg will be listed and users can delete some of them.

And finally a button "Apply tweak modules" so that all these tweak modules will be finally written into the part.cfg.

[/DREAM]

Well, it's just a primitive thought on the tool. I don't know when will I start writing this tool though.

Edit:

I got another thought, an in-game version will be good. it could acquire all other plugins' class members...

If I can acquire the part that the user has selected in the editor mode, and with a small GUI for user to pick the properties of that part (& of its part modules), then save the tweaks into a file inside KSP/PluginData/ folder, I can then write another small tool to read that file in KSP/PluginData/ folder and apply all the changes onto actual part.cfg files...

Hmm... that also sounds complex... anyway...

Edited May 7, 2013 by HoneyFox

[Mihara]

That sounds like way overkill.

1. Ask user for the install folder of KSP.
   
2. Present a database of of applicable tweaks with checkboxes whether to apply each. Each database entry provides it's own regular expressions for figuring out whether a tweak is applicable to a part, and what regular expression to apply to the file to change it.
   
3. Go grab them part files. Go through each part file in order, going through the list of enabled tweaks in order.
   
4. If the tweak is enabled, and applicable and the file is not marked (by a comment line in the beginning) that it has been patched, patch it.
   

The moment anyone releases a sufficiently popular mod that makes a certain tweak desirable, add it's respective regular expressions into the database and release a new version. There's no call to really be universal, and certainly no need to go deep into .NET.

[HoneyFox]

That sounds like way overkill.

1. Ask user for the install folder of KSP.
   
2. Present a database of of applicable tweaks with checkboxes whether to apply each. Each database entry provides it's own regular expressions for figuring out whether a tweak is applicable to a part, and what regular expression to apply to the file to change it.
   
3. Go grab them part files. Go through each part file in order, going through the list of enabled tweaks in order.
   
4. If the tweak is enabled, and applicable and the file is not marked (by a comment line in the beginning) that it has been patched, patch it.
   

The moment anyone releases a sufficiently popular mod that makes a certain tweak desirable, add it's respective regular expressions into the database and release a new version. There's no call to really be universal, and certainly no need to go deep into .NET.

XD Yeah, my ideas are kind of over kill.

Using a database to save useful properties of parts and all kinds of part modules (including popular 3rd-party ones) seems good, but... how to sync that when something changes.

Only thing I'm wondering is how to populate the database? By releasing new version seems quite... weird.

Your idea really sounds like a community project instead of a personal one...

[Mihara]

Make it download that "database" (for lack of a better word, with me it would just be a text file, no need for anything more complex than that, since it's to store pairs of regular expressions) off a public location (even Dropbox will do, but Github is all the vogue these days and your project is on Github already) with each start if you don't want to release updates.

[HoneyFox]

That sounds like way overkill.

1. Ask user for the install folder of KSP.
   
2. Present a database of of applicable tweaks with checkboxes whether to apply each. Each database entry provides it's own regular expressions for figuring out whether a tweak is applicable to a part, and what regular expression to apply to the file to change it.
   
3. Go grab them part files. Go through each part file in order, going through the list of enabled tweaks in order.
   
4. If the tweak is enabled, and applicable and the file is not marked (by a comment line in the beginning) that it has been patched, patch it.
   

The moment anyone releases a sufficiently popular mod that makes a certain tweak desirable, add it's respective regular expressions into the database and release a new version. There's no call to really be universal, and certainly no need to go deep into .NET.

Well, finally I decided to try implement the "Add module in Editor mode" feature.

Right now all codes are written and debugging is under-way.

You can pick lots of parameters reflected from the part/part module's assembly information. Only numeric ones are supported though.

And, it's up to you to decide which one you want to tweak. And it's your responsibility if you try to modify some critical values which may crash the game or the save file.

Once this is done, I may add blacklist or whitelist feature later to forbid accessing to these critical parameters. But that's way further.

[Galacticruler]

You know...this just might get Cpt.'s seal of approval.

[HoneyFox]

One issue comes into my mind and i don't know if there's any way to handle it gracefully:

There may be multiple instances of a same type of part module in a part. Like say we have multiple ModuleRCS modules in a part. Then the expression: Module(ModuleRCS).thrusterPower cannot judge which one (or all of them?) of these ModuleRCS modules should be the target. I can add an additional value as the index, but that seems quite ugly...

[Mihara]

There may be multiple instances of a same type of part module in a part. Like say we have multiple ModuleRCS modules in a part. Then the expression: Module(ModuleRCS).thrusterPower cannot judge which one (or all of them?) of these ModuleRCS modules should be the target. I can add an additional value as the index, but that seems quite ugly...

Can you possibly highlight a part in editor when the user selects it in the tweak menu? That would solve it, and I know there's a general mechanism that lets you do that in the game proper, (Crew Transfer and Fuel Balancer plugins use it) perchance it works in the editor as well.

[HoneyFox]

Can you possibly highlight a part in editor when the user selects it in the tweak menu? That would solve it, and I know there's a general mechanism that lets you do that in the game proper, (Crew Transfer and Fuel Balancer plugins use it) perchance it works in the editor as well.

Actually what you said is not the problem i described. and FYI, the highlighting feature is already there... but with many module GUI expanded, their parts are all high-lighted... So it's a bit hard to find the exact one. I may change logic to only highlight the latest one that got expanded/folded.

The problem I described is: if one part has two or more ModuleRCSs inside. How can i identify each of them by the targetField? Right now targetField will be like Module(moduleName).attributeName, but since there are two ModuleRCSs, which one should it tweak?

===============================

For the new AddModuleToPart feature that may come soon, the usage will be a bit complex (but once you get used to it, it should be OK) :

You first pick the part by left click on it (this will also rip off the part from the craft).

Then press a certain hot key (currently i set that as 'P').

A new window will pop-up to show all available parameters of that part.

Now you can place that part (with all its children-parts) aside.

And then pick the parameters you want from the GUI.

Once done, place that part back to the craft and the GUI will close itself.

This is just a rough planning of the system, it may differ when it gets published (if this feature gets working)

Edited May 17, 2013 by HoneyFox

[Mihara]

The problem I described is: if one part has two or more ModuleRCSs inside. How can i identify each of them by the targetField? Right now targetField will be like Module(moduleName).attributeName, but since there are two ModuleRCSs, which one should it tweak?

Ah, a multi-directional RCS block... How does the block itself know which is which, anyway?

[HoneyFox]

Ah, a multi-directional RCS block... How does the block itself know which is which, anyway?

They don't need to know which is which I guess... The game engine just iterate all part modules the part has and call their Update()/FixedUpdate() functions one by one.

Maybe the targetField should be changed to Module(moduleName)[indexOfThisTypeOfPartModule].attributeName.

Or I'd rather add an additional KSPField into the ModuleTweakableParam class, named as "indexOfSameTypeModules" with default value 0 so it won't break the compatibility of the old version.

[ZRM]

Thanks for a very useful mod. I have just added support for it to my new mod, Coordinated RCS. My mod allows tweaking of parameters during flight, which are persistant between sessions. Unfortunately, Tweakable Parameters overwrites these values at every load when enabled. It would be nice to have an option to make it only set parameters when a flight starts to fix this.

[colmo]

I'm looking forward to using this for tweaking ASAS settings, because one size does not fit all.

[HoneyFox]

Thanks for a very useful mod. I have just added support for it to my new mod, Coordinated RCS. My mod allows tweaking of parameters during flight, which are persistant between sessions. Unfortunately, Tweakable Parameters overwrites these values at every load when enabled. It would be nice to have an option to make it only set parameters when a flight starts to fix this.

There is already a parameter "setOnlyOnLaunchPad" which i guess should fit your need.

[HoneyFox]

I'm looking forward to using this for tweaking ASAS settings, because one size does not fit all.

Yes, by adding three modules (for Kp, Ki, Kd) you can tweak different values for different sizes of ships.

Actually there seems to be some other parameters like "damping", etc. which i'm not quite sure how to tweak. But still a test fly is good.

[ZRM]

Oh, is that what that means? Thank you very much.

[HoneyFox]

So bad that I cannot achieve the "AddModuleToPart" feature right now...

The problem seems to be: I can add the module to the part in Editor mode, and I can activate that module manually to get access to the tweak menu.

But if i save the craft, leave the Editor mode and then reload the craft either by opening it in Editor again or by Launching it on launch pad, there will be an error saying:

Part ...... cannot load module #... . It only has ... modules defined

So it looks like the part's prototype has recorded what modules it has by analyzing part.cfg file instead of from the saved .craft file. Inside the .craft file it has the modules I added, but it cannot be accepted by the game engine when loading the ship.

I may need to find a workaround. Right now I've got no idea though...

[HoneyFox]

Alrighty... after several minutes of brain-storm... I came to another solution, which will be compatible with the current design while being able to support multiple sets of parameters.

Also, I'm trying hard to support AddModuleToPart in Editor stage. And it's likely to be successful this time

[ZRM]

Do you reckon you could make it so that holding down the adjustment buttons makes the parameter decrease/increase at a particular rate? Right now it is tedious to change parameters by a large number of increments. Or perhaps a text box would work.