pellinor

Dev update: * scaling of crew capacity (hardcoded to use the mass exponent for now) For upscaled parts, excess crew will log errors because they get no IVA seat, and will not get a crew portrait (same behavior as raising crewCapacity with a MM patch). Other than that everything should work.

You need kOS plus another module which applies mass through the new interface. That totally explains why a simple pod +kOS does not show the issue. If you have patches active to add kOS to more parts this would also explain why you see the bug for more parts.

I had a look in the log and found kOS. You don't happen to have kOS functionality on those parts? This is known to cause this symptom when combined with other modules that use the new interface (the same thing happens with kOS & TweakScale). https://github.com/KSP-KOS/KOS/issues/1643 (solved but not released yet)

The KIS inventory might be the culprit: https://github.com/KospY/KIS/issues/141 For reproducing the issue it might be necessary that two modules try to add a non-zero mass (one via the new interface and the other via part.mass). Also @Denko666 could try removing modules from the part to see which ones are needed to get the error.

Dev update: * IVA scaling * small optimisation: disable partModule in flight if not scaled

It packages TweakScale and MFT, which makes it prone to bring back old versions (and therefore bugs that are already fixed). Just something to keep in mind, I can't relate your issue to anything I fixed recently.

You are bundling an outdated version of TweakScale. And actually I do not see why this is part of the download at all since it seems not to be a dependency.

Could you at least put this into a spoiler? It makes the whole page pretty much unreadable. There is a nice collection of exceptions in that log, none of which points to TweakScale. Always look for exceptions first. You have other problems than an empty config file. For example moduleManager refuses to load, which means that TweakScale's code will not even be called.

Actually this warning might be normal because Examples.cfg consists only of comments (unless you have manually activated anything there). You can safely remove it, however I do not see how an empty config file should interfere with anything.

Release v2.2.11: * remove obsolete IFS exponents * fix bug in partMessage for MFT * expose API via the part message system * fix for mirrored parts * workaround for tweakable bug: extra scaleFactor 500% for the free scaletypes (so the range from 200-400% is usable again) * don't interfere if other mods illegaly write part.mass. Print a warning in this case * fix thrust for moduleRCS (new maxFuelFlow exponent like for moduleEngines) Example code for using the new partMessage: [KSPEvent(guiActive = false, active = true)] void OnPartScaleChanged(BaseEventData data) { float factorAbsolute = data.Get<float>("factorAbsolute"); float factorRelative = data.Get<float>("factorRelative"); Debug.Log("PartMessage: OnPartScaleChanged:" + "\npart=" + part.name + "\nfactorRelative=" + factorRelative.ToString() + "\nfactorAbsolute=" + factorAbsolute.ToString()); } Edit: poking @NathanKell since he needs this for RF engines.

Fixed, looks like moduleRCS needs an extra maxFuelFlow exponent (like moduleEngines needed in one of the previous KSP versions) Also the exhaust looks better now. It is just unscaled, which is a known issue that I probably won't solve any time soon.

Confirmed (fuel consumption does not change). So they probably changed something about the variables where this thrust is either configured or stored... And no idea yet about the visible exhaust. Edit: what I do is put thrusters of different size on a pod and compare their fuel consumption. And KER shown thrust in the editor. More or less known issue in the presence of mods which still write to part.mass directly (like kOS and KIS). The mass handling interface has changed and mods are still catching up. This issue seems to be caused by multiple modules that modify mass coming together on the same part, and some of them containing assumptions that are no longer true.

Looks like a new bug in the tweakable, thanks for finding it. This is the downside of making mod stuff stock: no fixes between KSP versions (and only a handful of people are allowed to do fixes at all). As a workaround I added a new factor 500% to the free scaletypes, so the range from 200-400% becomes usable again.

Dev update: * workaround for tweakable bug: extra factor 500% for the free scaletypes (so the range from 200-400% is usable) * don't interfere if other mods illegaly write part.mass. Print a warning in this case Edit: * maxFuelFlow exponent for moduleRCS

Dev update: * fix for mirrored parts

Dev update: * expose API via the part message system

And to my knowledge it should already be fixed in the current TweakScale version and the dev version of FAR. You're most welcome. That window of opportunity was a call for trouble, so I really had to get rid of it. There is already more mass trouble appearing in the vincinity of KIS and kOS, likely also because of conflicts with part.mass (both write it).

Dev update: * fix part message for MFT There already is a config interface for defining all of TweakScale's behavior. ScaleExponents.cfg contains the default scaling behavior, ScaleTypes.cfg (mainly) defines configs for the scaling slider. The cfgs in the patches folder define what parts are scaleable and can override the default exponents. You can change all of those things wiht MM patches.

Ah, so this is what the extra comma in your quote was coming from! Thanks a lot.

I had a look at the KIS code and it also writes part.mass directly in its inventory module. It seems like this change has not spread among modders yet. And let me quote another dev for the interface change (we really should collect this stuff in one place where you can easily link it):

Since 1.1, mods should not write part.mass directly, and the game will frequently set it back to prefab.mass. You should implement the getModuleMass function instead. For the disk space this is even a simplification because you only need to report the added mass. The change is mentioned here:

Thanks, that one still pointed to kerbalStuff. No further reproduction needed, I'm seeing the same thing. And realFuels / MFT actually use the same code. This also explains your engine issue because the realEngines - TweakScale interaction is not ready yet.

I'm just saying that I used to set part.mass, and the devs clearly stated that this is against the new design of mass handling. In earlier versions the writing access was still in because I didn't clean it up yet. And the value would survive for some undefined amount of time before the game overwrites it with prefab.mass. In flight, onRescale should be called OnLoad, and with the latest changes massScale is available when that call is done. With massScale and the prefab mass you should have all the mass-related info. This is how FAR does it: https://github.com/ferram4/Ferram-Aerospace-Research/commit/5f8893b6e5d8e8444ce5679c8a284ca36481fe96 If you explicitly need the scaling factor at some other time, it is equal to (currentScale/defaultScale) (both are kspFields from the TweakScale module). I don't know what 'at startup' means, the hooks I know are OnLoad and OnStart. In flight I need to use the earlier OnLoad trigger because otherwise it would be too late to scale the colliders.

How did you receive that mass? part.mass should no longer be changed by mods, and TweakScale respects this with the current update. Since mass changes are supposed to happen only via getModuleMass, I now hold a field massScale, and make sure that this field is written before I notifying other modules. My getModuleMass then reports prefab.mass*(massScale-1). The main difference I am aware of is that parts in the editor come to life OnStart, while scaling in flight needs to happen OnLoad. And that the editor already ignored part.mass and listened to getModuleMass before, while the flight scane changed to that behavior in 1.1. Not sure if that is what you are referring to. In both cases TweakScale is supposed to report the correct mass as soon as it knows that value.

I see this too, needs TweakScale+MFT. Thanks for reporting!