pellinor

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.

This one should (further down in ScaleExponents.cfg): TWEAKSCALEEXPONENTS { name = ModuleResourceConverter EfficiencyBonus = 3 }

We'll have to test, and compare to the FSFuelSwitch-TweakScale interaction. I think I scale a 'baseMass' value in FSFuelSwitch and then it overwrites what I do to part.mass, which ends up with the right mass when both modules are present. Or something remotely like that.

factor.*.linear is the length, there is also factor.*.cubic as a shortcut to the volume scale. I consider cost even messier than mass because of this unfortunate design decision to include the resource cost. As far as I know you only have the onRescale call from the API. And I am never sure about the order of operations (change of kspFields and API notification) because that is determined implicitely by the order of some list of rescale events (that is the part of the code I am least familiar with). Edit: looking at the IR code it should be first scale kspFields then do API notification.

Ok so first you need a part patch to define the sizes, just copy from something similar in the TweakScale/patches folder. This one means "use the default behavior for stack parts, and the size of the unscaled part should be labeled as '2.5m'." (adjust the part name and defaultScale to your parts). @PART[batteryBankLarge] // Z-4K Rechargeable Battery Bank { %MODULE[TweakScale] { type = stack defaultScale = 2.5 } } Then you need to ask if any values or partModules need special treatment. Mass already scales with size^3 per default, as does the output of the stock generator and converter modules. All the details are in TweakScale/ScaleExponents.cfg. So unless you have some exotic module there is probably nothing more to do.

Yes, you need the TweakScale API definition Scale_Redist.dll from here: https://github.com/pellinor0/TweakScale/tree/master/GameData/TweakScale/plugins This does not depend on KSP/Unity so it does not need any updates. Source: https://github.com/pellinor0/TweakScale/tree/master/Scale_Redist Here is an example how to use it: https://github.com/MagicSmokeIndustries/InfernalRobotics/blob/develop/InfernalRobotics/InfernalRobotics/Module/Rescale.cs You can work with the absolute scaling factor (100% = the prefab) or the relative one (100% = the state before this rescale event). For tanks TweakScale already scales the amount and maxAmount on an existing resource node. What you need to do is to insert a scaled tank when switching part subtypes. So you can either scale your tank templates (this is how it works in FSFuelSwitch) or keep the scale as an internal variable. Do you also touch attachment nodes? They work pretty much the same, TweakScale will move them correctly but you need to account for the current scale when creating new nodes on an already scaled part. For mass and cost, TweakScale scales the (dry) mass/cost of the prefab. You need to take care of the modifiers that apply when changing subtypes. Again, FSFuelSwitch does this by scaling its tank templates. If all variables that need scaling are exposed as kspFields (float/double or lists of float/double), then we can do the scaling purely with MM patches. In this way FSFuelSwitch works without including any TweakScale-related code. InfernalRobotics is an example where this was not possible because it needs to move meshes on each rescale event.

From a first glance at the new PartSwitch code, TweakScale support will probably take more than MM patches. I'll have a closer look later this week. The MM patches for scaling of B9 parts are bundled with TweakScale, please come to that thread if you'd like to contribute or complain.

Currently not, I haven't cleaned things up yet after the forum update. Can I help on anything specific?

Most people here make things just because they want them in their own game. Also there usually are far mode ideas looking for a modder than modders looking for ideas. If someone 'steals' my idea it basically means that I will get the result without having to work for it.

Any chance for an offset gizmo? That would be useful to work around all sorts of issues.

Oh I overlooked the mention of 1.0.4. On an old KSP version the best advice I can give is to freeze your install to some working configuration and be very careful with updating anything. For TweakScale and MFT, a workaround can be to make sure not to have MFT and TweakScale modules on the same part. Or just don't scale that booster.

The infinite loop is the biggest problem. As for pretty much any exception on vessel load, the only really safe thing to do is to terminate the program (i.e. crash to desptop), or at least leave the editor. Otherwise you accept that all sorts of completely unrelated things might be broken. As long as this is present it really makes no sense to debug other things.

Are you using the latest version? The infinite loop should be fixed in TweakScale v2.2.6. And yes, the patches look fine, those are basically different ways to get the same thing.