That's the problem: TweakScale code is still somewhat messy.

The last big refactoring, handled on #198 and published on 2.4.6.0, was a huge necessary step into the right direction, but not sufficient: it solved my problem internally, but I was still screwed on 3rd party support.

With the lessons learnt implementing the [TweakScale Companions](https://github.com/net-lisias-ksp/TweakScaleCompanion], and with an unexpected continuous time window available, I decided it is time to take the next Step: proper 3rd party support in code.

The IRescalable (for Part) and IRescalable<> for PartModules are still the easies method of supporting TweakScale when you don't mind a hard dependency on Scale_Redist, but these methods are semantically insufficient.

What happens when I need to Rescale something only after some other thing was already scaled? Or be absolutely sure no one would be Rescaled before another one?

I had coped with these problems for years on the Companion Program, with the most variable degrees of success - now and then something changes, and break the FSM I had to pull from my hat in order to make things work.

A real, proper solution for this mess must be from TweakScale.

This task does that trick.

Additionally, and this came as a bonus, there were hard coded support for 3rd parties on TweakScale, and this was buggering me also for years. It not only break my Non Funcional Requirement of only suporting Stock + DLC on the TweakScale standard distribution, it exposes me to bugs related to these 3rd parties - something breaks there, I need to solve it on TweakScale. Unacceptable.

Removing such support into a TweakScale Companion was a old dream of mine, finally to come true. :)

User's Manual:

IRescalable and IRescalable<>

They still works as they are. Some things are handled before calling them, and some things will be handler after calling them.

No currently clients will be impacted by this change.

IPriorityRescalable and IPriorityRescalable<>

For things that need to be handled at absolute first.

Right now, only the Part scaling code really needs theIPriorityRescalable, but the ``IPriorityRescalable<>` one (for PartModules) I expect to be useful.

Keep in mind that you can't assume that anything was already scaled when using these interfaces - not even the Part itself.

You can't have dependencies when using these two, and you must take steps to prevent your code changes something that will be worked by someone else also using them - in special, the Generic Rescalable used by TweakScale itself.

ISecondaryRescalable and ISecondaryRescalable<>

These ones I expect to be very useful in the field.

A lot of things can only be done after the target modules were scaled, and before this change I would had to rely on weird shenanigans to accomplish such synchronisation.

Now things will be immensely easier: just shove that code into these Secondary things and call it a day!

IUpdateable

Some KSP features resist scaling, resetting some values now and then. TweakScale solved the problem by monitoring them on the Unity's OnUpdate, but doing that on TS is cumbersome: we end up having to call everybody all the time indiscriminately, wasting CPU and memory each frame.

Even TweakScale itself coded a specially internal Rescalable to be called on OnUpdate, but the interface wasn't made public when created for V1.38.

Well, now it's public. :)

Scale_Redist users don't need to rely on shenanigans pulled out from a hat in order to keep things tigh when KSP decides to overrun us.

Implemented on commit e94acd9