HoneyFox

Well.. unfortunately, though it can change the rescaleFactor value of the part, the part's actual size won't change. Perhaps it's read in loading phase and after that, any change on that won't affect anything.

New version released. And I really wonder if the space port works... Last time i uploaded the V1 package, and till now it's not shown on that site...

OK. Now all functions are done and looks like they are all running normally... Hmm... I guess I should post a screenshot on my OP.

Well, that's a plugin i wrote several months ago to be able to adjust maxThrust of engines both in Editor mode and in flight (there's an option to disable in-flight adjustment). And that seems gone with the forum/spaceport collapse... Anyway, spaceport seems to hold that plugin still. It's just that the page is not displayed correctly, only with a link to the file.

Yeah, a bit. I'll add two repeatButton so by holding down the buttons these value will change quickly. And by clicking the current two buttons you can adjust accurately.

I was just modifying its properties... but then get some weird errors so its initialization might get halted... well... probably a different problem.

Oh, I remember that I've encountered a similar situation before. When I was developing the Engine Thrust Controller plugin, I've seem that the engine keeps flaming in a incorrect direction. I guess it's because the thrust & thrust vector transform matrice are not initialized. Because my part module is "hijacking" the ModuleEngines... Maybe you can wait for a while and then replace the ModuleRCS later...

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

Adding to context menu & action group is good. But if you have lots of options, it's really not a good idea to list them all in the context menu. A menu item to show/hide a window should be good.

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

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.

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

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.

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)

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

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.

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

Huh? I don't have any trouble using Dropbox. Mediafire is blocked that's same for me...

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

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.

Well i'd like to give a seems-to-be-a-bug report: When an engine is deactivated and then reactivated, sometimes it just doesn't burn again. Maybe it's because the engine is not connected to a fuel tank directly? In my case, it is connected to a part which is fuel cross-feedable. I wonder if we forget to check that in the codes. Also, if you'll check this problem, don't forget the fuel pipes which may also cause similar problems. And, yes the mod is awesome. No longer need to disable fuel flow of multiple fuel tanks. Only need to deactivate the engine itself will save a lot of work & time.

Trying to use this with the dock mod... hmm... you can guess what i want to do. But the arms wobbles a lot, which makes controlling the craft quite hard.

Well, good tips but there are lots of places which need struts but cannot be attached to.

Hi, that panel is actually brought by the RendezMe plugin instead of Mech-Jeb. RendezMe was based on RinComp plugin IIRC. You should be able to find this plugin in the plugin section of the forum. For that "Kill Rel Vel" option, in original RendezMe plugin, it utilizes RCS translations to get zero relative velocity. BTW i have changed that behavior a bit in my own version to only kill relative velocity perpendicular to the line of sight so i can have achieve high speed interception easily with both "Kill Rel Vel" and "TGT+" options on.

Well.. how about using the orbital construction mod's way to replace both crafts with one which looks like the same? but yeah, then there will be problem for crew-transfering unless the mod provides a dialog for players to adjust crew allocation before dispatched. Also, i don't know if the game engine can handle a craft with multiple command pods.