pellinor

The problem is large thermometers. If size and weight are negligible, a larger thermometer should not become cheaper. So preserving the price sounds like a good solution to me. I'm not sure yet what to do wiht probecores, probably some sort of inverse pricing. Which is why there is a config switch for scaleable crew parts. Configuring your game is not cheating :-) TweakScale serves many different playstyles, and career mode is only one of them. Another would be aesthetic building, where often people do not care for the function of a part at all. And I can't tell how big the different groups are since I get almost no feedback about the user base of this mod. I mainly build it for my own playstyle (occasional scaling in career mode, where it seems reasonable and looks good). Personally, I tend to overlook the more unreasonable sliders because I never search for them. It's like having Hyperedit installed but still using rockets to get my payloads into orbit. If someone wants to put in the work to publish and maintain a proper restrictions config for career mode, feel free. There clearly is a demand for it. It just hasn't happened yet because nobody wanted it badly enough.

Maybe double-use of attachment nodes? With partClipping/non strict attachment checks from the debug menu you can use the (outward-facing) end nodes of the bays to put stuff on the inside, effectively using the node twice. This can confuse the fuel flow logic, which tends to ignore one of the connections.

Now for something on topic: I've updated the TweakScale dev version for the OPT v1.8 test release. I haven't deleted anything so it should still work for the parts which vanished since v1.7.

small dev update: * patches for the OPT v1.8 test release * cleaned up some unused/outdated stuff * update MM

This is not a general problem with downscaling, but with the behaviour of specific parts. You are right, science parts currently get too strong when shrinked and useless when enlarged. Maybe I should just keep mass and cost constant. Inverse proportional cost would make sense for the material bay but not for the tiny science parts. There is always the possibility to remove TweakScale from certain parts with a simple MM patch. For crew pods (or parts with a certain module) this patch is even shipped with TweakScale (see examples.cfg), you just have to activate it. The same applies to multiplayer: if you want to compare yourself to others you need to agree on a common set of rules. This includes the choice of mods, but also their settings. To allow everything by default was a conscious design decision because reverting to default should not break crafts. Also, if you add a restriction patch, a user with default settings will be able to use all your crafts.

Actually scaling things down can be just as cheaty. For example the tiny stock engines are less efficient and often don't come in the ecact size you need them. If you only want to use TweakScale for a certain mod, you can safely remove some (or all) of the config files in the 'patches' folder. This is the typical solution for people who want to scale something specific but otherwise keep the 'lego blocks' feel of restricted puzzle pieces. There is a config interface for size restrictions, where you can unlock scaleFactors with techs. However it uses absolute scales, so you can write "this scaleType(or part) needs techX to scale to 2.5m" but not "you can now scale everything to half size". I currently don't include restriction configs because I consider them a pain to do and maintain, and it would break easily as soon as someone moves parts in the tech tree.

This is strange because as of today the dev version should still be identical to the latest release. In any case, scale_editor.dll is not needed and yoiu can safely remove it (I'll also remove it for 1.1).

The OPT config is probably incomplete because I expected that the current 'test release' would be followed by another release. I'll update it in time for 1.1. Sounds likely, some of the realism mods heavily manipulate the TweakScale configs. I think there was also a conflict between the RealEngines and TweakScale modules.

Actually this is not an edge case but the end condition, i.e. the regular way of a servo to stop. If maxDeltaVel was high, this means that the servo jumped to its commandPos in the old version. If the new version behaves differently, it does not consider the movement finished, and will be interrupted later by the next command. I guess this invalidates some of my considerations, in this case bypassing the interpolator will behave like the old version before your change.

In my understanding the underlying problem is that you are doing the interpolation yourself, and then the result is streamed to the IR interpolator which is told to come to a stop at each position. I think a cleaner way to handle this would be to offer a mode that tries to keep its target speed until reaching the target position, assuming he will get new commands on the fly. It would only brake after overshooting, or when approaching a hard limit. This could actually work without the realtime requirement of getting new positions every physics tick. Another way is to disable/bypass the interpolation entirely (i.e. write positions directly). This is more or less what happens when you set huge acceleration values. There might still be a bit of weirdness here and there because it was not an intended use case when I wrote the interpolation code. Of course the silver bullet would be true synchronous interpolation, i.e. only one interpolator for a set of servos. You would give it a list of positions, then it would calculate its dynamics (maxSpeed/maxAcc) based on the distance and dynamics of the involved servos, and move them all in sync. This is pretty straightforward for basic linear motion, but can become a huge can of worms once you get nonlinear (e.g. change 'direction' without stopping). Edit: one more remark to the braking code: when determining maxSpeed from the distance to the limit, we are working on a SQRT curve, close to zero where it has a vertical tangent. So the problem is badly conditioned and the code for the last tick was done more or less by trial and error.

Not sure if this is confirmed yet. I remember a dev statement from several weeks ago (either devnotes or squadcast) that in principle unity can split physics into several threads but nothing is done (so far) from the KSP side. So it all depends on how the engine decides to handle things, and they did not want to promise that it actually happens with multiple vessels in physics range. The possibility is a unity feature, so this is public knowledge. It actually happening is a definite observation/promise about game behavior/performance, and they have been quite secretive about that kind of information. I have the impression that those two tings are often confounded in the discussions.

That's the best news I have heard for a long time. My hopes are up that this includes the root part bug that cost this mod so much of its reputation.

Sounds like a broken install. Maybe this helps (I really need to find some time for documentation):

You can use the part in a save and then search for it in the save file (or a craft file), unexpected modules should show up there. If you don't want to dig into the issue, the suggestion with ModuleKisItem should work just as well.

A part is 'stackable' if different copies are guaranteed to be identical (i.e. no persistent data). This is decided via a list of stackable partModules that you find in the KIS config. Examples of non stackable modules would be RESOURCE nodes or a TweakScale module.

I haven't given much attention to KSP and TweakScale for a long time, planning to clean things up when 1.1 drops (or is near). Done, looks like I forgot that when putting it in Spacedock.

Fuel lines do not need to go directly to the engine. It is enough if they go to a tank or other (fuel crossfeed enabled?) part that the engine already 'sees'. I would try other parts in the stack, or one tank that it correctly draining. The second might lead to asymmetric draining of the tanks but at least you can reach the fuel.

Quite the opposite actually, the KAS pipes already have this function: there is a "pump here" / "stop pumping" action available on each end of a connected KAS pipe, which turns it into a fuel line of the corresponding direction. Fuel lines only affect the flow logic when engines search for fuel. So if you connect two half-full tanks with a fuel line, nothing is actively transferred.

The KAS winches allow vessels to be physically connected but not docked. Maybe that code helps.

I just stumbled on the remark that TweakScale is detected too often. You can compare the values currentScale and defaultScale in the TweakScale module. If they are equal then the part is unscaled and the module can be ignored.

TWEAKSCALEEXPONENTS { name = ModuleResourceConverter EfficiencyBonus = 3 } So we are talking about this one? This probably dates back to the time when the module was part of USI. TweakScale does not calculate any load figures, this happens inside the converter. I remember that there was no kspField to scale the input/output directly. Then I found that scaling the EfficiencyBonus would influence the converter throughput in the right way. So a scaled converter is currently modelled as the original converter running at a scaled efficiency. I'm always open for a better solution, the constraint is that TweakScale operates on kspFields inside PartModules.

A simple common ground would be that mass is only added incrementally. So everyone who touches it multiple times should remember how much he added before and only apply the difference. I have already gone a part of this way when implementing getModuleMass for the editor display. This special treatment would break many existing cfgs so I'm a bit hesitant. I could also force relative scaling for mass, that means it always scales the current mass instead of the prefab one. This probably does not break any other mods using TweakScale. You can test this by setting the line "mass = 3" to "!mass = 3" in ScaleExponents.cfg (and I would force it in the code so it also applies to overrides of this value). This is probably the simplest solution because you don't need to touch part.mass on rescale. Generally this is the better behavior for values that other actors might touch, unfortunately it is not the default and clashes with MM syntax (so it can be used in configNodes but not in patches).

TweakScale does not touch config nodes but kspFields inside partModules. So the names refer to variables of a certain type in the C# source code. The names of those two things are usually identical if the config value simply fills an internal variable that is used at runtime. However there are modules which do fancy things with their config data and stores the results in a different form. Then I need to look for some kspField that I can manipulate in editor/flight to get the desired behavior. Furthermore, if a value does not appear in a specific cfg then the internal variable can still exist. The line in the cfg file basically means "if a variable of that name exists, initialize it with this value instead of the default".

I am not sure because scaling the part.mass is implemented as an OnRescale() call of the same kind. https://github.com/pellinor0/TweakScale/blob/master/Updater.cs If I read the method CreateUpdaters(Part part) right then the partModules end up first in the updating list, and the part fields come at the end. But this is really a part of inherited code that I never understood properly. Probably the best solution is to just code a prototype and see what happens. Sorry for being so vague about this ;-)

Small correction on the mass question: TweakScale treats part.mass like any other kspField, so it scales the original (prefab) value and overwrites the part field. The mechanic of incrementally adding the scaling contribution is only done in getModuleMass which drives the engineer's report. So yes, messy stuff that easily breaks if multiple actors change part.mass.