pellinor

Nope, this is procedural parts territory.

Is there a way to lock the right click menu in place while dragging the slider of a KSPApiExtensions Float-edit field? When TweakScale changes the part size, the menu wanders off with the center of the part, making it difficult to stay on the slider. Edit: I have taken over the maintenance of TweakScale from Biotronic, so I am also a user of KSPApiExtensions now.

currentScale/defaultScale is what you are looking for. This is the scaling factor compared to the untouched part, and is independent of the scaletype. Both values are members of the TweakScale module. @DMagic, do you want to do that yourself, or is this a workaround for a missing config on my side? The usual way would be to have a drillLength variable in your module, and a SCALEEXPONENTS config which tells TweakScale how to change it. @FreeThinker: in the OP of the old TweakScale Thread under 'advanced features', there is an interface description for getting notified on rescale. Maybe this is what you are looking for.

The next iteration is up [.ZIP from Github], uploaded a few minutes ago. * Slider increments are now configurable (see examples in DefaultScales.cfg). * If min/maxScale are not set we try the min and max of the scaleFactors list. * If a free scaletype has no increments set, it gets a simple slider from min to max. * Removed the inner buttons for the %-based scaletypes, it seems more convenient like this. Edit: I still haven't understood the above problem, just avoided to change that line.

I have a problem with this line from ScaleType.cs: MaxValue = Tools.ConfigValue(config, "maxScale", source.MaxValue); This is supposed to return the last parameter in case of a problem. It works like this, however when I change the last param to something explicit like 3f, I seem to always get this 3f back (as a result, it overrides the maxScale of all scaletypes). Anyone with C# has an idea on this? The method is from Tools.cs: public static T ConfigValue<T>(ConfigNode config, string name, T defaultValue) { if (!config.HasValue(name)) { return defaultValue; } string cfgValue = config.GetValue(name); try { var result = ConvertEx.ChangeType<T>(cfgValue); return result; } catch (Exception ex) { if (ex is InvalidCastException || ex is FormatException || ex is OverflowException || ex is ArgumentNullException) { LogWf("Failed to convert string value \"{0}\" to type {1}", cfgValue, typeof(T).Name); return defaultValue; } throw; } } - - - Updated - - - If it worked with the old free scaletype then it should still work. My guess is it uses the most straightforward method of just getting currentScale and defaultScale from the TweakScale module, these work the same regardless of scaletype.

I haven't searched when that happened, but it also catched me by surprise.

For me it still happens, but requires a scaled root part now. My guess is that this comes from some difference between KSP 0.25 and 0.90. See the OP of the dev thread, I keep the info there up to date. Can you tell reproduction steps for the first one? The second one doesn't surprise me as there is an automatic camera change happening. Obviously the trigger is the camera change, and not the user requesting it.

Good to have more people here who know how this stuff is used in other mods. @"free" scaling: There seems some confusion about what freescaling means, because we have a scaletype "free" and a properts "isfreescale" which are different things. isFreeScale is what I am changing, this just means that intermediate values are allowed. The free/surface scaletypes on the other hand are meant for parts for which percent seems a more natural scaling unit than meter. I do not plan to merge these categories. @scale-sliders: right now I go with the same interface as procedural parts. The limitation is the slider tweakable from KSPApiExtensions, which needs fixed increments. For stack parts, the main increment is 1.25m, so with the outer arrows you jump between the larger stock scales. The small arrow gives the intermediate sizes (0.625, 1.875 etc). So the buttons give you basically the same selection as before. The main difference is that there exists a slider to access intermediate values. @Nodes: I changed some stuff about node sizes because the code only worked for discrete scaling, or between parts with identical scaling units. Now they scale proportionally with the visual model. What would work in the current version is to make the original models big with small nodes, so you scale them down most of the time. Then you would end up with size0 nodes most of the time (probably not optimal). Do you know why they need small nodes? Probably they move their servos in a non-smooth way and the connected parts need some wiggle room so they can follow a bit smoother. Sounds like a reasonable request, though if my intuition is right it seems a bit like working around a problem that is better solved in other ways. I'd be interested if they would be more stable with a smooth interpolation (might have a look at that if I ever get TweakScale stable). Anyway, I'll look for a good way to configure node scaling. And if something is worse than in TS 1.50 please tell me. @mass scaling: are you sure? I thought the same, until I recently found that the default exponents in ScaleExponents.cfg are 2.5 for mass and 2.6 for thrust. That looks quite reasonable. Or is anything overriding this?

So for now it looks like the two bugs are one (camera bug and reverting root part), since both are triggered at quicksave/quickload or on revert to launch, and both require a rescaled root part. Biotronic's analyzed this already and wrote a KSP bug report. In his findings from KSP 0.25, he claims that defaultTransformScale is set to (1.3, 1.3, 1.3), which is saved to the craft file, and gets reverted to (1,1,1) at load. (defaultTransformScale is a persistent member of the TweakScale module). It looks like in 0.90 this symptom has vanished (it already starts as 1,1,1 in the initial craft file), probably because this variable no longer needs to change. In my tests, the reverted part keeps its values scaled, only the scale of the visual model is reverted. When quicksaving afterwards, the part also looks correctly scaled in the save file. So I could try some hack to scale the visual model of the root part by an extra currentScale/defaultScale. So, how can I tell that the current vessel came into life by a quickload or revert, and not by launching directly from the VAB/SPH (or by decoupling)?

You are talking about this config? I'm not a moduleManager expert, but there are a handful of suspicious things about that config: * it is referring to a custom scaleType "TweakScaler" that is not included * part[*]: do you know what you're doing there? Is is safe to give e.g. struts, fuel lines and asteroids a TweakScale module? * wasn't there some "HAS:" expression when you test the existence of a module? * you don't specify when the patch should be applied. If the patch gets applied early, the TweakScale module you test for might not yet exist.

The stack scaletype defines the default behavior for stock parts, this is exactly what I want to change. In my opinion, the possibilities should be limited just by the UI. From there, you get tools to introduce restrictions if you want. I do not see the old stack behavior as god-given and the best thinkable way to do it, but as something historically grown out of interface limitations (In the old freescale interface the standard stack sizes would be somewhere randomly in the middle of the slider, so it was not even an option to use it for stack parts). The problem in your config is just that freescale does not use the min and max of the scaleFactors list. For whatever reasons, it has its own config values minScale and maxScale. I just tested that you can override them in the same way as the scaleFactors: @PART[engineLargeSkipper] // Rockomax "Skipper" Liquid Engine { MODULE { name = TweakScale type = stack defaultScale = 2.5 minScale = 1 maxScale = 5 } } For free scaling, the tweakable is hardcoded to main increments of maxScale/8 at the moment, so the subdivision gets wonky again. Due to rounding issues I even end up with a wrong max setting for the above config. I will fix this with config options for the slider settings. If you want the old discrete behavior, the best way is to define a custom scaletype with freescale=false. Thanks for your post, it shows that I should not be hasty with bringing the scaletype changes into an official TweakScale release.

This is clearly beyond my current knowledge about the internal mechanics of KSP, so I'll focus on workarounds for the moment. For me, switching to map view and back after each camera change seemed to resolve the situation. And for parts reverting to original scale, is it possible that this bug requires a scaled root part? This would also be a good workaround.

Ah, there it is, thank you. Now I also see parts reverting size so that there are spaces in between. Maybe I forgot to actualy scale something last time? I found a total of 6 NullReferenceExceptions from TweakScale, from within the editor scene. Will look into those. Other than that there seems a lot going on mainly attached to 'KerbQuake' and 'clouds'.

Is the camera bug on revert still present? I don't see it right now. Tested linux_x86 if that makes any difference. And does anyone have reproduction steps for that "parts are reverting their scale" bug(s)? What about misplaced attachment nodes on duplicating parts? I also can't reproduce this. This might be related to the fact that all my test parts are feescaling now, so there is some discrete scaling code that is not used for anything that Tweakscale supports by default. Still there surely are mods out there that define their own discrete scaletypes.

Latest dev version [.ZIP] (Warning: Save-breaking!, WIP, might contain bees) You also find it in the opening post of the thread. For now I consider it as a good way to hand out intermediate versions without spreading many outdated download links.

It always links to the last commit. Right now it says '23min ago' (I did that change as a reaction to your post). I promise to use version numbers when things get a bit more stable...

Reminds me of an issue in the github of the old version. This is the IntakeRadialLong part right? That one had two MM patches instead of one. Fixed in the latest github version (haven't checked yet if this resolves your issue). Excellent bug report, stuff like this makes my life a lot easier. Fixed in the latest github version.

Changes * Moved all adapters to stack scaletype (Save-breaking!) * change surface scaletype to free, and change its unit to % (Save-breaking!) * added an example discrete scaletype for documentation, because there is none left Save-breaking means it will break vessels and craft files. A save without active crafts should be fine.

So the bug is parts reverting to original size? Probably on quickload or switching to the vessel? Can anyone reliably reproduce this? I've only seen this once, and remember fighting against autoscaling in the editor when making that vessel. Later I disabled autoscale and haven't had this bug again. EDIT: reproduced, it is triggered with the camera bug on revert. (there might be other bugs separate from this one)

Latest dev version [.ZIP] (Warning: WIP, might contain bees) auto- and chain scaling are * off by default * restricted to parts of the same scaletype (that means pods/adapters do not autoscale at the moment) For the moment, I will consider auto- and chain scaling as advanced functions which are consciously turned on by people who know what they are doing. I like the idea for some sort of 'subassembly scaling' that tries to enlarge every scalable part, but that will have to wait until TweakScale is in good shape again. If you guys don't find any important new bugs, I would say we are pretty close to an official release. Before, I'd like to port the pods and adapters to the stack scaletype, and sort through any old issues that are easy to fix.

Free scaling is a property of the scaletype. My main config change was this (from DefaultScales.cfg) SCALETYPE { name = stack freeScale = true minScale = 0.3 maxScale = 10 ... } ScaleExponents can be set as a global default, per scaletype or for individual parts. In the past I have successfully used module manager patches of the form @PART[RAPIER]:Final { @MODULE[TweakScale] { TWEAKSCALEEXPONENTS { mass = 2 } } } - - - Updated - - - No need for action, as it already does per default. If you look at Defaultscales.cfg and ScaleExponents.cfg, you will see that the scaletypes do not contain any SCALEEXPONENTS entries. I think the name 'surface' comes from surface attachment (as a contrast to stack parts). I'm a bit surprised by the setting of 2.5, this means that engines scale fine and tanks do not follow the constant mass fraction that is standard in stock. In my memory it was the other way round and engines needed some work. Guess I haven't looked in there for a long time.

I was not happy with those node lists because they make assumptions about node names in arbitrary part files, and in most cases just bring in redundant information. Like the stock 4-way adapter did not autoscale properly because the scaletype was only designed for two bottom nodes. So I'll consult the prefab part as a default, and maybe bring the lists back as a way to address special cases. There will probably be an extra scaletype for non-stack parts which like to be measured in m instead of %. Good point about intermediate sizes. In the current system an 1.5m mod would need its own scaletype, and you would scale connections between 1.5m and stock parts manually. For chain scaling I tend to keep the 'propagate autoscaling across compatible nodes' approach for now, until freescaling has some stability. Then I'll test a 'propagate change of scale across the whole subassembly approach'.

Actually the latest version works perfectly for stack parts. Even adapters with multiple node sizes. Only prerequisite is that in the original part every node corresponds to a circular area of the corresponding diameter. If a part does not satisfy this condition, it should not have the stack scaletype. I'm also not the biggest fan of those functions, it just would be bad to throw them away even before understanding how they are supposed to behave and what people use them for. A restriction to stack-like scaletypes actually looks like a simple solution to only use them in cases where they already work well.

I agree to turn them off by default, mainly because the default behavior should not be surprising. And users of advanced features usually know what they do, they can just turn it on with a hotkey, or change the config.

Now the same for chain scaling. Reading the code, chain scaling propagates an autoscale-command from a part to its children. Probably whenever the parent part is rescaled, but I am not sompletely sure. This also means that chain scaling is only applicable along a chain of auto-scalable parts. So if I chain scale a stack of random parts, I will end up with a smooth rocket. Is this the intended use case?